Enterprise Modelling using Algebraic Graph Transformation

Forschungsberichte

der Fakultät IV – Elektrotechnik und Informatik

Enterprise Modelling

using Algebraic Graph Transformation -

Extended Version

Christoph Brandt, Frank Hermann, Hartmut Ehrig,

Thomas Engel

Bericht-Nr. 2010-06

ISSN 1436-9915

Enterprise Modelling using Algebraic Graph Transformation -

Extended Version

Construction, Integration, Transformation and

Evaluation of Organizational Models at Credit Suisse

Christoph Brandt1,?, Frank Hermann2, Hartmut Ehrig2, Thomas Engel1

1Universit´e du Luxembourg, SECAN-Lab, Campus Kirchberg,

6, rue Richard Coudenhove-Kalergi, 1359 Luxembourg-Kirchberg, EU

e-mail: {christoph.brandt,thomas.engel}@uni.lu,

WWW home page: http://wiki.uni.lu/secan-lab

2Technische Universit¨at Berlin, Fakult¨at IV, Theoretische Informatik/Formale Spezifikation,

Sekr. FR 6-1, Franklinstr. 28/29, 10587 Berlin, EU

e-mail: {frank,ehrig}@cs.tu-berlin.de

WWW home page: http://www.tfs.tu-berlin.de

Abstract An analysis of today’s situation at Credit

Suisse has shown severe problems, because it is based

on current best practices and ad-hoc modelling tech-

niques to handle important aspects of security, risk and

compliance. Based on this analysis we propose in this

paper a new enterprise model which allows the con-

struction, integration, transformation and evaluation of

different organizational models in a big decentralized

organization like Credit Suisse. The main idea of the

new model framework is to provide small decentralized

models and intra-model evaluation techniques to han-

dle services, processes and rules separately for the busi-

ness and IT universe on one hand and for human-centric

and machine-centric concepts on the other hand. Fur-

thermore, the new framework provides inter-modelling

techniques based on algebraic graph transformation to

establish the connection between different kinds of mod-

els and to allow integration of the decentralized models.

In order to check for security, risk and compliance in

a suitable way, our models and techniques are based on

different kinds of formal methods. In this paper, we show

that algebraic graph transformation techniques are use-

ful not only for intra-modelling – using graph grammars

for visual languages and graph constraints for require-

ments – but also for inter-modelling – using triple graph

grammars for model transformation and integration.

Altogether, we present the overall idea of our new

model framework and show how to solve specific prob-

lems concerning intra- and inter-modelling as first steps.

This should give evidence that our framework can also

?This work is partially supported by Credit Suisse (Lux-

embourg) S.A., 56, Grand Rue BP 40, L-1660 Luxembourg,

Telephone: +352 46 00 11-1, Fax: +352 46 32 70

handle important other requirements for enterprise mod-

elling in a big decentralized organization like Credit Su-

isse.

1 Introduction

The problem addressed in this paper is about how to

construct, integrate, transform and evaluate new orga-

nizational models in order to improve today’s enterprise

models at Credit Suisse and similar organizations based

on a research project supported by Credit Suisse. The

new models are going to be constructed to represent

relevant aspects of the real-world organization that are

needed to check for security, risk and compliance issues

the bank has to handle because of national and interna-

tional laws, financial regulations and internal rules.

After an analysis of today’s situation at Credit Suisse

and a detailed requirement analysis, this paper presents

a potential solution for enterprise modelling using alge-

braic graph transformation. This new modelling frame-

work includes services, processes and rules , business and

an IT views and a distinction between human-centric

and machine-centric models. The idea is to have not one

single bulky enterprise model but multiple lean models

that can be integrated leading to a holistic organiza-

tional view of the enterprise. The integrated enterprise

model can be used for evaluation, simulation and au-

tomation of business processes and can be managed inde-

pendently in order to match the requirements of a decen-

tralized organization. Algebraic graph transformation is

used as a formalism to construct, integrate, transform

2 Christoph Brandt et al.

and evaluate the various models. The foundations of al-

gebraic graph transformation date back to the 1970s [1]

and the framework is continuously extended and adapted

for an increasing area of applications, especially in com-

puter science. A wide range of results for the analysis of

rule based systems is available concerning correctness,

confluence, concurrency and distributed computing [2,

3,4]. The formal basis of algebraic graph transformation

[5] enables formal proofs about the qualities of opera-

tions and model transformations that may impact secu-

rity, risk and compliance issues. This has the potential to

be of enormous practical relevance in the Credit Suisse

scenario.

Therefore the scope of this study is to show how

lean organizational models can be constructed and main-

tained in a controlled way, and how the interplay of mod-

els can be organized by exploiting techniques based on

algebraic graph transformation respecting real-world re-

quirements. This result is assumed to create the precon-

dition for going much deeper into the analysis of security,

risk and compliance issues later on. In a first step, a se-

curity example is exemplarily discussed by applying the

introduced formalisms.

Cost reduction and quality assurance as well as au-

tomation have been defined by Credit Suisse as driving

business interests. Hence, the solution is not only re-

quired to lead to scientifically sound results but is also

required to realize these business interests. Because of

the generality of these requirements, our proposed new

enterprise model can also be applied to other organiza-

tions having similar requirements.

The novelty presented in this paper lies in the com-

bination of human-centric and machine-centric models

and in using algebraic graph transformation as the for-

mal modelling technique to construct, integrate, trans-

form and evaluate these models. At the same time, the

proposed solution has the potential to meet organiza-

tional side-constraints at Credit Suisse like decentraliza-

tion and other business interests. In contrast to today’s

practice at Credit Suisse which is about integrating tools

to address very specific issues, the proposed solution sug-

gests to start with the question of how a holistic organi-

zational model should be build, managed and evaluated

that can answer security, risk and compliance questions.

This enables the automation, monitoring and analysis

of the organizational workflows and helps to facilitate

a corresponding IT implementation. The proposed ap-

proach frees the enterprise model from IT implementa-

tion aspects and helps to keep the organizational model

consistent and focussed to answer questions about secu-

rity, risk and compliance.

Today’s Credit Suisse’s product-driven approach to

model organizational structures and to check for secu-

rity, risk and compliance requirements does not result

in a holistic organizational model that can be used to

answer such questions.

In contrast to any product-driven solution the pro-

posed approach promises a better scalability and exten-

sibility as well as lower long-term costs of ownership be-

cause it considers organizational scheme and instance

models to be objects of their own and independent of im-

plementation issues and tools. This is very different from

today’s practice where tools own certain data about the

organization that cannot easily be used without them.

Since people at Credit Suisse cannot be expected to be

technical experts in formal methods it is important to

point out that algebraic graph transformation is not only

a formal but also a visual specification technique, which

allows intuitive understanding. In detail, the construc-

tion, transformation, integration and evaluation of orga-

nizational scheme and instance models can be realized

by algebraic graph transformation techniques that can

directly work on the abstract syntax of these models.

This promises to enable the full control of organiza-

tional predicates that are of high practical relevance. The

product-driven approach that focuses on the technical

integration of tools and discards the formal integration

of methods is not able to do that.

The paper is organized as follows: In Sec. 2, enter-

prise modelling in the sense of our new modelling frame-

work is introduced based on the real-world requirements

coming out of the Credit Suisse scenario. In detail, di-

agrams representing IT and business services and pro-

cesses as well as samples of a domain language for orga-

nizational security requirements are shown as human-

centric models. In accordance with these models ab-

stract behaviour types and reo-connectors as well as suit-

able other formal techniques are proposed as machine-

centric models. In sections 3 and 4 intra-model and

inter-model techniques are introduced based on algebraic

graph transformation techniques. They are used to con-

struct, integrate, transform and evaluate the models of

this framework. In more detail, the intra model tech-

niques encompass the construction of models, their cor-

rection according to well-formedness rules and a valida-

tion of a subset of functional and non-functional require-

ments. Regarding inter-model techniques triple-graph

grammars [6,7] are explained and then used for model

transformation as well as model integration. Triple-

graph grammars can even help to propagate require-

ments that are formalized as graph constraints. In Sec.

5, we study related work and in Sec. 6, we conclude with

a summary of main achievements and aspects of future

work.

2 Enterprise Models and Enterprise Modelling

The first part of this section presents how Credit Suisse

addresses security, risk and compliance issues today by

the help of best practices. This leads to highly focussed

and partial enterprise models that are mostly build using

ad-hoc modelling techniques. Thereafter, we propose our

Enterprise Modelling using Algebraic Graph Transformation - Extended Version 3

new methodological approach that starts with lean and

focussed enterprise models which in a later stage should

be soundly integrated towards a holistic organizational

view, so that security, risk and compliance issues can

be answered based on an integrated and well focused

organizational model of the enterprise.

2.1 Today’s Situation

Today’s situation at Credit Suisse is essentially top-

down. It is top-down because based on given security,

risk or compliance requirements specific data are col-

lected and specific organizational operations are put into

place. In the best case this results in highly specialized

and partial enterprise models and in an ad-hoc mod-

elling technique based on best-practices that are used to

build those models. Therefore, security, risk and com-

pliance departments work in a non-integrated and un-

coordinated fashion. In a lot of cases controls are es-

tablished after the organizational practice is already in

place. So, controls are mostly realized in an end-of-pipe

way. Because controls are evaluated using best-practices

like checklists this often results in partial insights only.

Security, risk and compliance requirements are treated

on a demand basis driven by certain stakeholders who

only focus on their interests. Because this results in re-

dundant tasks and conceptual mismatches of results as

well as neglected reuse potentials in the area of enter-

prise modelling, one could think of using a performance

indicator that measures blind and misdirected outputs

to characterize the maturity of the current practice at

Credit Suisse. However, specific controlling data related

to the potential solution were not available at the time

of this writing. The following table in Fig. 1 summarizes

the situation.

Today

Approach Best Practices

Focus Interest

Control End-of-pipe

Judgment Checklists

Coverage Partial

Fig. 1 Security, Risk and Compliance – Today

Today’s enterprise modelling at Credit Suisse can ei-

ther be looked at from its perspective of modelling busi-

ness processes in business departments or from the point

of view of running technical components in IT depart-

ments. In addition to that, business and IT requirements

are documented. At the bank, both perspectives exist

and both have their own history, document types and

people. These department-oriented views are not syn-

chronized, not integrated, not conflict-free and some-

times over- or under-specified. The situation can fur-

ther be characterized as document-oriented, not model-

centric. In the documents, different types of models or

fragments of models can be found – the following table

in Fig. 2 lists some of them.

Components Processes Requirements

Business

Department – UML BO

IT MS Excel

Department MS Visio – MS Word

Fig. 2 Today’s Enterprise Modelling at Credit Suisse

So, landscapes of IT components are documented us-

ing Microsoft Visio, business processes are documented

using UML [8], business requirements are documented

using business object models (BO) [9] or just natural

or standardized business languages. The fact that busi-

ness services and IT processes are not documented in the

scenario shows a mismatch in the involved departments’

understanding of the common universe.

Therefore, the situation at Credit Suisse is unsatis-

factory. Members of Credit Suisse’ staff confirmed that

best-practices do not scale well in a big organization and

they do not fully cover all possible organizational states.

So, there are quality and costs problems when imple-

menting best-practices and processing the obtained re-

sults. The interest-driven data collection leads to par-

tial models that are not synchronized and not soundly

integrated. So, for example, the modelling of business

continuity processes is not properly integrating security

requirements. The end-of-pipe control defined by best-

practices increases the cycle times for evaluations of or-

ganizational settings. So, a contemporary reaction is get-

ting difficult. Organizational attributes that are part of

best-practices’ checklists are not formally grounded in

well-defined enterprise models. So, there is no clear con-

trol about the derivation and deduction of security, risk

and compliance predicates. Often checklists are applied

to specific cases only. So, concrete statements about se-

curity, risk and compliance are exclusively valid for very

specific assumptions. Therefore, they may not even be

comparable among themselves.

The proposed new solution that is presented in the

following addresses these issues by the help of formal

methods. However, because formal methods are often

considered to be difficult to understand special accen-

tuation is put on usability and applicability as well as

visual techniques and suitable implementation aspects.

The aim is to replace the semi-formal and non-integrated

organizational models and methods used today by a

generic enterprise model build by the help of declarative

and well-defined modelling techniques. The formal basis

of such a model and corresponding methods will support

the modelling process and the evaluation of models re-

sulting in lower costs and better quality of results. This

is very likely to improve the organizational competitive-

ness by the help of a better organizational control and

decision support as well as automation.

4 Christoph Brandt et al.

At the same time organizational side constraints

remain and must be respected. Today, organizational

knowledge is available only partial, it is available in a

non-integrated and distributed way and is often incon-

sistent and incomplete.

2.2 Tomorrow’s Situation

Tomorrow’s situation is likely to be different. Business

people at Credit Suisse requested to work with models

that are build using diagram- and text-oriented domain

languages in an integrated way. They further requested

support for fuzzy, incomplete and inconsistent models

as well as for partial redundant models that have been

created and entered by different persons. Because of the

dynamic nature of their business environment they re-

quested support for evolving domain languages in terms

of their syntax and semantics and support to merge mod-

els from different people as well as an appropriate ver-

sioning. Despite the semi-formal nature of those mod-

els they asked for model-checking-like capabilities. Their

idea of a modelling process is the one of using clickable

mathematics which means constructing models by the

help of intuitive and declarative click operations on a

screen that result transparently in models that can be

evaluated by the help of formal methods.

The first shift compared with today’s situation is

to start building fragments of an envisioned enterprise

model in contrast of checking specific cases regard-

ing concrete security, risk and compliance requirements.

Therefore, our new approach starts bottom-up. Once, an

appropriate enterprise model is available security, risk

and compliance predicates can be defined that make ref-

erence to such a model. Therefore, their semantics will

be well-defined. Corresponding security, risk and com-

pliance requirements can then be build on top of such

predicates in a constructive manner.

Further, by starting with an enterprise model the fo-

cus shifts from specific interests of certain stakeholders

towards a more holistic understanding of the organiza-

tion. Once, such a holistic enterprise model is available it

can be model checked regarding security, risk and com-

pliance which causes a shift from evaluating the modelled

business reality of Credit Suisse in an ex-post fashion to

evaluating an enterprise model under development in an

ex-ante way. So, there is a switch from an end-of-pipe

control to a begin-of-pipe control. Assumed, that an en-

terprise model is available it would be possible to run

proves, simulations and tests to check for security, risk

and compliance requirements covering all states of the

model. The table in Fig. 3 summarizes some character-

istics of tomorrow’s situation.

Based on future requirements there will be a switch

from the use of UML models and informal MS Visio

diagrams at Credit Suisse towards domain specific mod-

elling languages. In addition to that, the process ori-

ented view of business departments will be enhanced by

Today Tomorrow

Approach Best Practices formal Models, Methods

Focus Interest Organization

top-down bottom-up

Control End-of-pipe Begin-of-pipe

Judgment Checklists Prove, Simulation, Test

Coverage Partial Complete

Fig. 3 Security, Risk and Compliance – Today and Tomor-

row

an understanding of business services. The same applies

to the IT departments in a symmetric way. Here, the

focus on IT services will be enlarged by looking at IT

processes as well. At the end, Business and IT depart-

ments can work with the same type of service, process

and rules models, which will facilitate any kind of au-

tomatic alignment between both worlds. Given that life

cycles of models in the Business and IT universe are

different and that there is no clear top-down or bottom-

up dependency but a mutual relationship between both

worlds, implementation driven modelling processes wont

be the driving force any longer. They will be substituted

by specification oriented modelling processes which are

going to be orthogonal to any implementation activity.

By aligning domain specific models with formal models

the semantics of domain models can be explained. In

detail, this relationship between so called human-centric

models or domain models and machine-centric models or

formal models can be realized by model integration. In

the given case of this study at Credit Suisse, abstract be-

haviour types and reo connectors are proposed to explain

the semantics of services and service landscape models,

the mCRL2 process algebra [10] can be used to define

the semantics of business processes that appear as event

driven process chains. Finally, first-order logic can be

used to explain the semantics of business rules. Such a

framework of formal methods has the potential to reduce

today’s under-specification of enterprise models’ seman-

tics that causes significant integration problems. Orga-

nizational security, risk and compliance predicates can

then be soundly anchored in this formal framework.

Service Process Rules and

Landscapes Landscapes Principles

Business

Universe ABT & Reo PA & ML FOL

IT Universe ABT & Reo PA & ML FOL

Fig. 4 Tomorrow’s Enterprise Engineering at Credit Suisse

– Machine-Centric View

The machine-oriented slice of the scenario is pre-

sented by the table in Fig. 4, where ABT & Reo means

abstract behaviour types and Reo connectors [11], PA &

ML means a process algebra encompassing a modal logic

[10] and FOL denotes first order logic. More details are

given in Sections 2.5 and 2.6.

Enterprise Modelling using Algebraic Graph Transformation - Extended Version 5

2.3 The New Model Framework in a Nutshell

The main idea of the new model framework is to reduce

the overall complexity of one big organizational model by

splitting it in three dimensions as shown in Fig. 5. The

first dimension includes services, processes and rules, the

second dimension the business and IT universe and the

third dimension human-centric and machine-centric con-

cepts as discussed in the previous sections. Altogether

this leads to 12 different types of models, which can be

specified, interrelated and integrated by different tech-

niques.

From a formal point of view the model framework

in Fig. 5 shows different coordinates (X, Y, Z) and each

of them usually contains several models for one overall

enterprise model and these models change over time. For

instance the coordinate (S, B, M) represents all service

models for the business universe using a machine centric

modelling language - in our scenario ABT-Reo diagrams.

We denote the set of the models in one coordinate by

MX,Y,Z and refer to a specific model by the notation

MX,Y,Z for a model MX,Y,Z ∈MX,Y,Z .

As pointed out already, the splitting into three di-

mensions leads to several lean and focussed models for

specific purposes, which reduces the overall complexity

of one big organizational model. But the new model

framework includes also the interrelations between cor-

responding models in each of the three dimensions. The

inter-dimensional interplay for each dimension will be

explained below.

Last but not least our new enterprise modelling

is based on algebraic graph transformation techniques,

which support construction, integration and transforma-

tion of organizational models in our new framework as

discussed in the next subsection.

Business

Universe

IT Universe Human

Centric

Concepts

Machine

Centric

Concepts

Services Processes Rules

(S,B,H)

(S,I,H) (P,I,H) (R,I,H)

(R,B,H)(P,B,H)

Fig. 5 Model Framework

The inter-dimensional interplay in the framework in

Fig. 5 between services, processes and rules can be ex-

plained by the paradigm of a street map. The service

landscape is considered to be the street map on which

processes run like bus lines. Rules will govern concrete

decisions like it is the case for road traffic regulations.

The inter-dimensional interplay between Business

and IT models is the one of a mutual supportive align-

ment. Parts of the Business model can be automated

by the help of a corresponding IT model. However, it is

still possible to assume that there are parts of the Busi-

ness model without IT support. The same is true for an

IT model. Parts of an IT model may automate a Busi-

ness model. However, the IT may have their own specific

services, processes and rules for which there is no cor-

respondence in the business model. Therefore, neither

a top-down nor a bottom-up relationship is appropriate

here. It is more a relationship between equals.

The inter-dimensional interplay in the framework

between human-centric and machine-centric models is

about to join the world of humans with the world of

machines. Humans like to have the possibility to enter

incomplete, inconsistent, redundant and evolving mod-

els. In addition to that, they even like the definition of

the used domain languages to be open. Such require-

ments are usually incompatible with implemented for-

mal methods. However, having machine-oriented mod-

els that are build on implemented formal methods like

the ones just introduced the semantics of human-centric

models can be smoothly explained by a model integra-

tion between human-centric and machine-centric mod-

els. Further, model checking techniques can be applied

in an encapsulated way using machine-centric models

to evaluate security, risk and compliance requirements

in an automated fashion. This is something people at

Credit Suisse have strongly requested. They like to use

the power of formal methods without touching them.

A detailed motivation is given in [12]. The special is-

sue here is that such an integration is open. Integration

rules can be changed, deleted and added. Therefore, the

semantics of human-centric models can evolve. In ad-

dition to that such a loose coupling between human-

and machine-centric models enables to have syntactic

elements in a domain language for which there is no se-

mantics available, but which can be added later. And

assuming that a given domain model is going to be modi-

fied an aligned machine-centric model can drive comple-

tion rules during the modelling process. Therefore, we

do have no clear top-down or bottom-up relationship

between human- and machine-centric models.

The inter-dimensional model interplay in the frame-

work in Fig. 5 opens an orthogonal problem and solution

space. It is a problem space because the current situa-

tion of an organization can be documented and evaluated

ex-post. It is a solution space because possible future or-

ganizations can be defined by it and evaluated ex-ante.

Having the current and future organization available a

transition path can be defined. So, not only versions

of service, process and rule models but also versions of

whole organizational models can be imagined. Having a

history of organizational models and performance data

available the practical impact of business reengineering

projects can be much better controlled.

6 Christoph Brandt et al.

2.4 Using Algebraic Graph Transformation

Algebraic graph transformation techniques are able to

support a wide range of the requirements discussed in

the previous Subsections 2.2 and 2.3. So, model integra-

tion can be used to realize the alignment between Busi-

ness and IT models [13,14] using triple graph grammar

techniques in Sec. 4. Because model integration works

both ways round-trip-engineering can be supported in

principle as it can be realized by intra-model integra-

tion and transformation techniques shown in later sec-

tions. This ideally supports the decentralized organiza-

tion of Credit Suisse where models are created at differ-

ent locations asynchronously. Algebraic graph transfor-

mation can be used to connect domain models or human-

centric models with formal models or machine-centric

models to explain the semantics of domain models while

keeping this relationship open for future changes. As a

consequence, machine-centric models allow, for exam-

ple, fully automated evaluations of organizational poli-

cies of business processes by keeping the business pro-

cess model human-centric and aligned with the machine-

centric counterparts using inter-model integration tech-

niques. Algebraic graph transformation can also support

consistency checks between service, process and rules

models by the help of model integration. These means

to integrate models enables to keep the models inde-

pendent, lean, focused and manageable and they fur-

ther enable aggregated views that can be model checked.

In addition to that, integrated models will facilitate the

communication between different departments. Simula-

tion models do not need to be given explicitly. They can

be created by transformation rules using service, process

and rule models as their input.

Algebraic graph transformation - as shown in Sec. 3

below - enables to specify graph transformation rules in a

declarative way which makes this formal technique very

usable. Further, the underlying algorithms can be fully

implemented. At the same time, type graphs and graph

transformation rules can change. Therefore, the imple-

mentation can be kept static while being able to cope

with changing type graphs and changing graph transfor-

mation rules. So, transformation rules can be executed

by a generic implementation of algebraic graph trans-

formation. We will show this in detail based on a small

showcase that has been implemented in Mathematica

[15,6]. Compared with alternative solutions this formal

technique is built on a body of theory that allows for-

mal proofs. Therefore, guarantees can be given which

is of high relevance when discussing security, risk and

compliance predicates.

In detail, models are considered as objects of their

own. Small models can be integrated to one holistic

model. Decentralized modelling is possible. Enforcement

of security requirements by the help of graph constraints

is available. Algebraic graph transformation has a good

potential to be compatible with the concept of plugga-

bility and the notion of ontologies. Instance- and class-

modelling is possible likewise. Models can be modified in

a controlled way. Models can be build independently and

decentralized. Transformation rules are declarative and

therefore very easy to understand by people who are not

experts in formal methods. Language artefacts of differ-

ent types like diagram-artefacts and text-artefacts can

be glued together based on their abstract syntax using

the same technique. So, domain languages can be used

equally easy as diagram languages. The separation into

human-centric models and machine-centric models helps

people to administrate incomplete or inconsistent mod-

els without being forced to comply to well-formedness of

models based on formal methods. By using catalogues

of model elements and assemblies a lego-like modelling

system could be provided. The same applies to transfor-

mation rules or sets of transformation rules. The tech-

nique of algebraic graph transformation is able to cope

with such open catalogues.

The subjectivity of entered models can be handled

by intersecting service, process or rules models created

by different people to derive at a common denominator

that is shared by all modelling parties. Linguistic am-

biguities can be addressed by integration rules that are

mapping human-centric models towards machine-centric

models and using redundant elements of a human-centric

model for this mapping to reduce or resolve ambiguity

issues. Further, the modelling process as it is supported

by algebraic graph transformation is agile. It can there-

fore support refinements and extensions at any level of

detail and abstraction in a scalable and declarative way.

Finally, rules sets of transformation rules can be mod-

ified. New rules can be added, old rules can be depre-

cated. So, adaptive modelling can easily be supported.

And because the applied technique of algebraic graph

transformation address the abstract syntax of models,

it can in principle handle any type of model visual or

textual. It is even possible to combine semi-structured

models as in the case of natural text with structured

models like the ones used for business rules.

Finally, model-based interoperability is defined in the

context of this study in Sec. 4 as the ability to execute

sound model integrations and to check for inconsisten-

cies during the integration as well as to execute model

transformations using inter-model techniques. It further

encompasses the ability to propagate model invariants

– defined by graph constraints – and the possibility to

realize constructive completion during inter-model inte-

gration. This theoretical notion of model-based interop-

erability is likely to facilitate the tool-oriented interop-

erability of different modelling products in the future.

2.5 Service Models

In the following subsection service models are introduced

based on examples. A human-centric and a machine-

centric variant are shown.

Enterprise Modelling using Algebraic Graph Transformation - Extended Version 7

Human-centric service models as they came up dur-

ing this study are diagram-like language artefacts that

sketch service instances as well as their connections. This

can be done using different pictograms. In practice, such

models are created at Credit Suisse by the help of MS

Viso or similar tools. In the following, we will always as-

sume that such diagram languages are given by a cata-

logue of icons and a corresponding graph grammar. How-

ever, the assumption is that both, the catalogue of lan-

guage icons and the graph grammar can be changed. In

detail, new elements can be added to the catalogue, old

ones can be deleted or modified, as well as new graph

transformation rules can be added to the graph gram-

mar and old ones can be deleted or modified. Therefore,

a diagram-like domain language for service landscapes

can be kept open as it was requested by people at Credit

Suisse to handle new and possibly unforeseen situations.

Because business and IT people are assumed to

model their service landscapes independently we do give

two examples for human-centric service models in the

following. Both models can be aligned to document how

business services are realized by the help of IT services,

or how IT services drive business services. This align-

ment can be realized by the help of model integration

techniques as it will be shown in Sec. 4.

Investment Banking

Private Banking

...

Fig. 6 Human-centric Model of Business Services

Example 1 (Human-centric Model for a Business Service

Structure) A fragment of a human-centric business ser-

vice model is shown in Fig. 6. The departments “In-

vestment Banking” and “Private Banking” are depart-

ments at Credit Suisse. Information exchanged between

both parties must comply to the Chinese Wall Policy

[16]. The policy defines what information is allowed to

be exchanged between both departments. To guarantee

that the policy is respected a filter will suppress illegal

messages between both service instances in the diagram.

Each service instance represents a department. There-

fore, the policy is realized as a filter in a service model.

This business view completely abstracts away IT details.

NW4

NW7

NW2

...

Fig. 7 Human-centric Model of IT Services

Example 2 (Human-centric Model for an IT Service

Structure) A fragment of a human-centric IT service

model is shown in Fig. 7. Here, we see that network

zone “NW4a”and “NW4b” are interconnected. We fur-

ther see that network “NW4a” is connected by the help

of a secured connection with network zone “NW7” and

network zone “NW4a” is connected by the help of a se-

cured connection with network zone “NW7”, too.

As a concrete alignment between the business model

fragment in Fig. 6 and the IT model fragment in Fig

7, the private banking department can be mapped to

network zone “NW4a” and “NW4b” and the investment

banking department can be mapped to the network zone

“NW7”. The connector between the investment and the

banking department in the business universe is then re-

lated with the connections between network “NW4a”

and “NW7” as well as “NW4b” and “NW7”. Therefore,

this relation is not necessarily a one-to-one mapping.

Human-centric service models as they have just been

introduced are only syntax artefacts. A corresponding

semantics can be assigned by the help of an alignment

with machine-centric models. The corresponding type of

machine-centric model that is used here are abstract be-

haviour types and Reo connectors [11,17,18,19]. This

kind of model is based on formal methods. Its set of

elementary icons and its graph grammar are fix.

The reason why we propose to use abstract behaviour

types and reo connectors to specify services and service

landscapes is because of their support for exogenous co-

ordination. In addition to that abstract behavior types

focus on incoming and outgoing messages and, therefore,

abstract away implementation details of services which

frees an ABT-Reo model from implementation aspects

and reduces the overall complexity of models.

Example 3 (ABT-Reo Instance) A fragment of machine-

centric business service model is shown in its concrete

syntax in Fig. 8. Here, two abstract behaviour types are

used to represent the investment and the private bank-

ing department. Messages running between these two

abstract behaviour types have to pass through different

8 Christoph Brandt et al.

F1:Filter

Private_Banking:Department

Investment_Banking:Department

private

public

private

public

Reo-

connectors

ABT-

components

Fig. 8 ABT-Reo Instance in the Business Universe

Reo connectors. Messages using private connectors are

not visible to the outside. Messages using public connec-

tors are visible. The filter in the middle of the diagram

listens to messages and will suppress private messages

that are trying to get on a public connector. This frag-

ment of a machine-centric business service model is able

to formally specify by the help of formal methods orga-

nizational security policies like the Chinese Wall Policy.

Using model-checking it is possible to prove that no pri-

vate message will finally pass by a public connector.

Besides the modelling of business service structures

ABT-Reo diagrams can also be used to model IT ser-

vice structures. Both types are intended to be aligned

with their corresponding conceptual service models and

in this way the human centric models shall be formally

analysed using the ABT-Reo diagrams.

2.6 Modelling of Processes and Organizational Rules

In order to specify possible workflows within a concrete

enterprise and to formalize the given policies and laws

the presented model framework shows separate dimen-

sions for these aspects. This paper has a special focus to

service models and we describe possible techniques for

the processes and rules briefly. Accordingly, the Sections

3 and 4 for intra- and inter-model techniques focus on

service models.

2.6.1 Event Driven Process Chains Event driven pro-

cess chains (EPCs) [20] are a common modelling lan-

guage for business processes. It is preferred by many

modelers, because they like the intuitive notation, which

is easy to grasp and to understand. EPCs have been ex-

tended to suit different needs and in the case of Credit

Suisse, there is a special interest to have a support for

the generation of continuity processes and the analysis

of non-functional requirements, e.g. security constraints.

For this purpose, the language of WDEPCs (data-flow

oriented EPCs from the point of view of a workflow en-

gine) was introduced in [12]. These enterprise models for

business processes build a basis for process analysis with

respect to non-functional requirements and furthermore,

for the generation of continuity processes based on the

standard process that are equipped with process frag-

ments for specific failures of the system components.

The generated processes are ensured to be executable,

produce at least the same or equivalent output as the

standard process and some of the non-functional require-

ments are checked to be fulfilled.

Contract

approved

Contract

29.07.2009

ID, Payment Plan

Contract

signed

Contract

29.07.2009

ID, Payment Plan

RM has

signed

CoID

Contract

29.07.2009

ID, Payment Plan C

(ID)

Contract

created

F11

F10

F12

Approve

Contract

(costs, time)

Customer

Signature

(costs, time)

Signature

(costs, time)

SRM(RMID)

CoID,

SRM(RMID)

SCO(COID)

DB2

(availability)

DB2

(availability)

DB2

(availability)

CoID

...

Fig. 9 Part of a Workflow Model

Example 4 (Business Process Model) Figure 9 shows a

part of a WDEPC-business process model for a loan

granting process. The figure shows three steps, which

are situated in the middle of the overall process. The

three steps describe the three signatures that are placed

on the loan contract by the involved parties. The sig-

natures are placed by the relationship manager (RM,

function F10) that serves the customer, by the customer

himself (C, function F11) and finally, by the credit officer

(CO, function F12) in order to complete the contract.

The system components that are involved in the pro-

cess can fail and the actors can be unavailable. Both

is specified by the term “availability”. For a concrete

combination of failures alternative continuations of the

process have to be processed that respect the functional

and non-functional requirements of the process. For this

purpose, the model is formalized by a graph grammar,

in which the effect of each function is specified by a rule.

The grammar is constructed automatically and supports

the analysis of dependencies between the steps using the

well founded results for graph transformation.

CO : Person

graph constraint: samePerson

RM : Person

CO,RM : Person :(samePerson)

graph constraint:

4EyePrinciple

Fig. 10 Graph Constraint 4-eye principle

Enterprise Modelling using Algebraic Graph Transformation - Extended Version 9

The validation of non-functional requirements is per-

formed by graph constraint checks, e.g. the constraint

in Fig. 10 specifies a requirement for the creation of a

contract according to the four-eye principle . It ensures

that the employee roles relationship manager (“RM”)

and credit officer (“CO”) are performed by two different

persons in a concrete execution of the workflow schema.

The constraint “4EyePrinciple” is a negation of the con-

straint “samePerson” and thus, it requires that the con-

straint “samePerson”, i.e. the two roles are not assigned

to a single person in a concrete execution. Further details

of graph constraints are subject of Sections 3.3 and 4.4,

where we apply this technique to specify requirements

for the structure of service models. The complete pro-

cess model, its analysis and the generation of continuity

processes is described in [12].

2.6.2 Process Algebra mCRL2 In the machine centric

dimension of process models we propose to use the

language mCRL2 (micro Common Representation Lan-

guage 2) [10], which extends the process algebra ACP

(Algebra of Communicating Processes) by data and time

aspects. In [21], the mCRL2 tool-set is used for an anal-

ysis of a loan granting process that is similar to the

one in Sec. 2.6.1. Figure 11 shows the specification of

the four-eye principle with respect to parallel executions

of the workflow. This time, there is no explicit distinc-

tion between the credit officer and the relationship man-

ager - both have the role of a relationship manager.

Nevertheless, the tool-set for mCRL2 allows to validate

that the computed state space for parallel executions

does not contain a path, in which the four-eye principle

is violated for the functions “F10 RM Signature” and

“F12 Approve Contract” with respect to the workflow

model in Fig. 10.

1forall e:RelationshipManager, c:Customer.

2[true*.F10_RM_Signature(e,c).true*.

3F12_Approve_Contranct(e,c)]false

Fig. 11 mCRL2 Specification of the segregation of duty (4-

eye-principle)

The tool-set allows the modeler to specify many de-

tailed requirements based on modal logic. This enables,

e.g. the specification of requirements regarding data flow.

In particular, Credit Suisse has to ensure the require-

ment that balance and address information of a customer

must not be send at the same time.

The alignment between the human- and machine-

centric process models, i.e. between WDEPCs and

mCRL2 specifications, shall be based on their abstract

syntax graphs. This will allow to reflect analysis results

from the machine-centric models to the intuitive human

centric models. The inter-model techniques that we use

in this paper are general with respect to domain lan-

guages and there is a potential that they can be used to

establish alignments not only for service models but also

for process models.

Besides the process algebra mCRL2, there are also

other machine-centric modelling techniques, especially

Petri nets [22], which have shown to be suitable for busi-

ness workflows [23] and several tool-sets have been im-

plemented.

2.6.3 Organizational Rules In order to ensure security,

risk and compliance requirements given by policy rules

there is a need for a formal analysis of the models within

the enterprise model framework in Fig. 5. There are dif-

ferent kinds of organizational rules, which are formulated

by several organizations as well as by the enterprise it-

self. A formalization can be performed in a first step

using a specified subset of a natural language for a spe-

cific business domain. This way, the semantics and struc-

ture of the rules given as sentences can be restricted and

equipped with an abstract syntax and these language

artefacts are still human-centric.

In the machine-centric dimension, there is a good po-

tential to completely formalize many of the rules by first

order logic (FOL). This way, the rules specified by for-

mulas can be evaluated and checked using rule-engines

as there are for example Prolog-based rule-processing

implementations available. Furthermore, there is a close

relationship between first order logic and graph con-

straints [24], such that the analysis of several formu-

las can be transferred to graph constraint checks on

the abstract syntax graphs. The alignment between the

human-centric policy rules and the formulas in first or-

der logic shall be based on their abstract syntax graphs.

Note that this alignment is usually not one-to-one, i.e.

there may be several sentences in a domain language that

correspond to a single formula and vice versa. A flexi-

ble alignment is a special need in the context of Credit

Suisse, because such domain languages need to be ex-

tendable while first order logic keeps fixed.

Furthermore, in order to formalize and analyze some

of the requirements that generally specify the permitted

workflows, graph transformation systems can be used.

They have shown to be a practicable and intuitive con-

cept for the specification of the operational semantics

of workflow models, including extensions for data and

control flow [25].

2.7 Scope of the Paper within the Model Framework

The enterprise model framework as shown in Fig. 5

encompasses the development of many different as-

pects. This paper presents suitable intra- and and inter-

modelling techniques focussed on machine-centric busi-

ness and IT service models given by ABT-Reo diagrams.

The techniques are general with respect to different do-

main specific languages, because they are based on the

10 Christoph Brandt et al.

underlying abstract syntax graphs of the models. Thus,

there is a good potential that they can be applied for

several other dimensions in the enterprise model frame-

work, too.

(S,B,M)

(S,I,M)

Machine centric Business Service Models

Machine centric IT Service Models

PropagationIntegrationMT

Fig. 12 Scope of the Paper

The scope of this paper for intra- and inter-model

techniques in the following Sections 3 and 4 is illustrated

in Fig. 12 and the examples are based on our previous

work in [26]. Algebraic graph transformation is applied

for both, intra- and inter-modelling. It is used to specify

the construction of the abstract syntax graphs during

the model development and the analysis of functional

and non-functional requirements. The inter-model tech-

niques are based on triple graphs, triple graph trans-

formation and triple graph grammars [27]. We present

how model transformation is used to transform a busi-

ness service model into an IT service model. This way,

model transformation supports the modelling when cer-

tain models in one domain are present, but their counter-

parts in a connected domain are missing. Furthermore,

we show how business and IT service models can be in-

tegrated, i.e. how the relations between their elements

can be automatically established and how inconsistencies

can be detected. Finally, we show how the propagation

of graph constraints can enable the transfer of especially

non-functional requirements from the IT domain to the

business domain of service models.

3 Intra-Model Techniques

The enterprise model framework presented in Sec. 2 cap-

tures various kinds of models and the development of

these models is performed on its concrete syntax, i.e. in

visual notation. Synchronously to the construction of the

concrete syntax a development environment creates the

underlying abstract syntax elements which form abstract

syntax graphs as described e.g. in [28]. Hence, the struc-

tural and formal analysis of these models can be based

on the underlying formal abstract graph structure.

This section presents suitable techniques for the for-

mal and automated construction and for the analysis of

the created abstract syntax graphs. The benefits of the

analysis are the following. First of all, there is a user sup-

port for the detection and correction of violations against

well-formedness rules with respect to models. The detec-

tion and highlighting of errors is performed automati-

cally and the modeler can chose whether he corrects the

model manually or starts an automatic correction pro-

cess. In addition to that, a substantial part of the given

functional and nonfunctional requirements for a model

can be formulated in an intuitive and visual way us-

ing graph constraints as formal technique. These graph

constraints can be checked automatically based on the

underlying formal abstract syntax and the checks can

be implemented in the development tools. The formal

framework for these techniques is algebraic graph trans-

formation [5].

Unlike the standard approach in graph transforma-

tion in which a graph language is defined by one graph

grammar we define two separate graph grammars: a con-

struction and a correction graph grammar (C & C).

The construction grammar contains compact and gen-

eral editing rules that can be attached to the editing

operations of a model development environment. The

correction grammar is used for the detection and elimi-

nation of incomplete respectively inconsistent structures.

This way the modelling process is kept flexible, i.e.

the modeler is able to freely edit the models implying

that models may violate language constraints at inter-

mediate steps. Furthermore, the visual modelling lan-

guages are not restricted in the way visual elements are

aligned. Each visualization can be based on abstract syn-

tax graphs, where each node type can be visualized by

a visual element in the concrete syntax.

Because of the need for flexibility during the editing

process, the construction grammar usually allows to gen-

erate invalid models. But the correction grammar con-

tains rules that detect inconsistent respectively incom-

plete parts of models in order to correct them. Those

incorrect parts can be highlighted in a modelling envi-

ronment, such that the modeler has two options for cor-

rection. Either he modifies the problematic model parts

himself or he starts the cleaning up process, in which

the problematic elements are deleted by an automated

application of the rules of the correction grammar. In

order to validate the soundness of the automated cor-

rection we can analyze confluence by applying central

results proven for graph transformation systems in gen-

eral. In addition to the analysis of the modes with re-

spect to well-formedness rules we present a structural

analysis of the abstract syntax graphs based on graph

constraints that are used to verify functional an non-

functional constraints, such as security requirements or

modelling guidelines. If a constraint is violated the exe-

cution of the graph constraint checks detects the prob-

lematic parts of the models.

An adequate set of models MX,Y,Z ∈ MX,Y,Z in the

coordinate (X, Y, Z) in the enterprise model framework

in Fig. 5 is obtained by the combination of the three

techniques explained above and applied in the following

way. The models are generated using the construction

Enterprise Modelling using Algebraic Graph Transformation - Extended Version 11

grammar and a correction using the correction grammar

thereafter for eliminating the models that are not well-

formed. A further restriction is obtained using the graph

constraint checks for excluding models that do not fulfill

the functional and non-functional requirements. In this

section we concentrate on the service models in the co-

ordinates (S, B, M) and (S, I, M) and we illustrate the

three techniques by representative rules and an intuitive

constraint.

The following Sec. 3.1 describes some basic no-

tions for the formal foundations of graph gram-

mars and presents parts of the construction grammar

GGCON−ABT for the language of ABT-Reo diagrams

for business and IT service models. Thereafter, Sec. 3.2

presents the grammar GGCOR−ABT for the correction

of intermediate models constructed by GGCON−ABT ,

where we use the concept of negative application con-

ditions for the detailed specification of critical patterns.

The complete grammars are given in [6]. Finally, Sec.

3.3 shows how graph constraints are used to specify and

check structural requirements that capture some of the

functional and non-functional aspects and in Sec. 3.4 we

summarize the achievements of this section.

3.1 Construction of Models by Construction Graph

Grammars

The framework of algebraic graph transformation pro-

vides a formal foundation for the specification and mod-

ification of object oriented models, in which the concrete

syntax of these models is related to their abstract syntax

graphs. In order to present representative parts of the

construction grammar GGCON−ABT for ABT-Reo dia-

grams this section reviews the general notions of typed

graph transformation. For details about attribution and

type graphs with inheritance we refer to [5].

The algebraic approach of graph transformation uses

the notion of directed graphs with explicit functions that

point to the source and target nodes of an edge. Map-

pings between graphs are given by graph morphisms that

are compatible with the internal structure of the graphs,

i.e. the source node of an edge in the domain graph is

mapped to the source node of the mapped edge in the

image graph (and similarly for the target nodes).

Definition 1 (Graphs and Graph Morphisms) A

graph G= (VG, EG, sG, tG)consists of a set VGof nodes,

a set EGof edges, and two functions sG, tG:EG→VG,

the source and the target function.

Given two graphs Gand Ha graph morphism

f:G→H,f= (fV, fE)consists of two functions

fV:VG→VHand fE:EG→EHthat preserve the

source and the target functions, i.e. fV◦sG=sH◦fE

and fV◦tG=tH◦fE. Graphs and graph morphisms

define the category Graphs. A graph morphism fis in-

jective if both functions fV,fEare injective.

E1:E/D

public

E2:E/D

public

NW4:LAN

NW7:LAN

private

Fig. 13 ABT-Reo Instance M1of the IT Universe

E1:E/D

NW4:LAN

private

NW4 : ABT

LAN : String

:name

: ExtIP :port

: Point

:glue

: ExtOP

:glue

: Reo

: ExtIP

:port

: Point

:glue

: ExtOP E1 : ABT

E/D : String

:name

:port

: ExtOP

:port

: Point :glue

: ExtIP

:glue

: Reo :port

: ExtOP

:port

: Point :glue

:glue

: ExtIP

:port

:port :name :name

Abstract Syntax

Concrete

Syntax

private : String

Fig. 14 Part of M1in Fig. 13 in Concrete and Abstract

Syntax

Example 5 (Graph) Figure 13 shows the ABT-Reo di-

agram M1in concrete syntax specifying the structure

of a part of a network composed of local area networks

(LANs). It contains four ABT elements that are con-

nected via Reo connectors. The two outer ABT elements

represent the LANs “NW4” and “NW7” while the two

inner ones denote encryption/decryption nodes, i.e. the

communication between both LANs is encrypted.

A part of the model M1is shown in 14 in both, con-

crete and abstract syntax. Bold bullets in concrete syn-

tax correspond to nodes of type “Point” in abstract syn-

tax and arrows correspond to Reo connectors, i.e. nodes

of type “Reo” in the abstract syntax graph. They are

attached to external input resp. external output ports

according to the direction of the Reo connectors. Each

point glues one input with one output port, e.g. the left

Reo connector in concrete syntax corresponds to the left

Reo node in the abstract syntax graph and the commu-

nication data enters the connector via the input port at

the bottom and exits the connector via the output port

at the top. The type graph for ABT-Reo diagrams is

shown in Fig. 15 and described in Ex. 6.

While the concrete syntax of ABT-Reo models is

more compact and intuitive, a precise and detailed spec-

ification and analysis is based on the abstract syntax,

12 Christoph Brandt et al.

which enables e.g. to explicitly specify properties of ports

that are only implicit in the concrete notion.

Similar to the definition of a meta model of a visual

language according to the OMG MOF approach [29] a

type graph specifies the general structure in the graph

grammar approach. Graphs of the language are typed

over its type graph via a graph morphism that maps

each element to its type element in the type graph, i.e.

each node to a node and each edge to an edge in the

type graph.

Definition 2 (Type Graph) A type graph is a distin-

guished graph TG. A tuple (G, typeG)of a graph Gto-

gether with a graph morphism typeG:G→TG is called

a typed graph. Given typed graphs G= (G, typeG)and

H= (H, typeH), a typed graph morphism fis a graph

morphism f:G→H, such that typeH◦f=typeG.

ElABT

CompABT

ExtP

IntP

ExtOPIntOPIntIPExtIP

ELABT CompABT

ABTReoPoint

OPIntPIPExtP

Port

glue

junction

TGABT-Reo

AR String

name

Legend

ExtIP

IntIP

IntOP

ExtOP

= ABT/Reo

= Elementary ABT

= Composite ABT

= External Port

= Internal Port

= Input Port

= Output Port

= External Input Port

= Internal Input Port

= Internal Output Port

= External Output Port

= Inheritance relation

= Edge type

port

Fig. 15 Type Graph T GABT −Reo for ABT-Reo models

Example 6 (Type Graph) The structure of ABT-Reo di-

agrams in abstract syntax is given by the type graph

T GABT −Reo in Fig. 15 containing the main types “ABT”

for abstract behaviour type nodes, “Reo” for Reo con-

nectors, “Port” for ports and “Point” for points that glue

together input and output ports of both, ABT nodes and

Reo connectors. Ports of elementary ABT nodes and

Reo connectors are external, i.e. they are used for ex-

ternal communication with other elements. ABT nodes

can also be composite, i.e. they contain a further spec-

ified internal structure involving other ABT nodes and

Reo connectors. In this case their external ports are con-

nected to complementary internal ports, such that the

communication is transferred through the borders of the

composite ABT nodes.

General editing steps of graph based models are spec-

ified by graph transformation rules. The left hand side

(LHS) of a rule defines the pattern that has to be found

in a graph before applying the rule and it is replaced by

the right hand side (RHS) of the rule during the rule

application. Both sides of a rule are related by an inter-

mediate graph K, which defines the elements that are

preserved during an application of the rule. Since the

graph Kis implicitly given by the LHS and RHS of a

rule we will usually omit this graph in the figures and

denote the mappings between the LHS and the RHS of

a rule by numbers.

A rule may further contain a negative application

condition (NAC) that specifies forbidden patterns. The

effect is that the rule is not applicable if the NAC pat-

tern is present at the matched part of the graph. This

improves the detailed specification of rules. A few rules

in the construction grammar contain NACs, in order

to prevent editing steps that are not adequate in gen-

eral. This improves the model quality before checking

the well-formedness conditions. However, the NACs can

also be ommited in the construction grammar to ensure

maximal flexibility for the modeler, but then the cor-

rection grammar becomes more complex. In any case,

NACs are very important for the correction grammar to

specify incomplete patterns, i.e. the NACs specify the

parts that are missing as described in Sec. 3.2.

Definition 3 (Typed Graph Rule) A typed graph

rule p= (L←

−K−

→R)consists of typed graphs

L, K, and R, called the left-hand side, gluing graph, and

the right-hand side respectively, and two injective typed

graph morphisms land r. A rule may furthermore be

equipped with additional NACs defining forbidden struc-

tures. A NAC of pis given by a graph Ntogether with

an injective graph morphism n:L→N.

LHS RHS

⇒

addExtInPort

1 : ELABT

: ExtIP

1 : ELABT

:port

addExtInPort

1 : ELABT

: ExtIP

1 : ELABT

:port

1 : ELABT

Complete

Notation

Compact

Notation

Fig. 16 Rule “addExtInPort” of GGCON−ABT

Some editing steps can be more complex in the way

that they combine the effect of basic editing steps. In

this case the complex editing step combines the effect

of several basic construction rules and the rules needed

for this complex step are combined leading to a new

rule. The combination of rules is performed by a form of

Enterprise Modelling using Algebraic Graph Transformation - Extended Version 13

RHS

⇒ : ELABT

addElementaryABT

LHS

Fig. 17 Rule “addElementaryABT” of GGCON−ABT

RHS

NAC1 LHS

⇒

1 : Point

2 : Port

: Port 1 : Point

: Reo 2 : Port

:glue

:port

glue

1 : Point

2 : Port

:glue

: Point

2 : Port

NAC2

Fig. 18 Rule “glue” of GGCON−ABT

gluing via a common subpart E, which is formalized by

the construction of E-concurrent rules in [5].

Example 7 (Typed Graph Rules) The rules in Fig-

ures 16 to 18 are part of the construction grammar

GGCON−ABT for the creation of ABT-Reo diagrams.

The complete grammar is given in [6] and each edit-

ing step of a development environment can be equipped

with one or more corresponding graph rules depending

on the complexity of the editing step as described before.

Rule “addExtInPort” in Fig. 16 specifies the creation of

a new external input port that is attached to an existing

elementary ABT node, i.e. an ABT element without in-

ternal structure. The rule is shown in complete notation

including the intermediate graph Kand in compact no-

tation leaving Kimplicit. In compact notation the graph

Kis given by the numbered elements, i.e. the elements

that occur in the LHS and the RHS of a rule. Since the

rule “addExtInPort” does not delete any elements the

graphs Land Kare identical. In the case of a deleting

rule the graph Lcontains the graph Kand additionally

the elements that are deleted by the rule.

The rule “addElementaryABT” in Fig. 17 has an

empty LHS and thus, it can be applied without any pre-

condition. The effect of the rule is the creation of a new

elementary ABT. Fig. 18 shows the rule “glue” which

specifies the gluing of ports. In order to glue together two

ports via a point (a bold bullet in the concrete syntax)

the rule is applied twice to the same point but to differ-

ent ports. The negative application condition “NAC1”

is equal to the RHS of the rule and thus, it forbids a re-

peated application of the rule “glue” at the same match,

i.e. if the point “1” is already connected to the port “2”

then the rule cannot be applied at these nodes. The sec-

ond NAC “NAC2” ensures that no two ports of a Reo-

connector are directly connected with each other. Note

that the rule extensively uses the inheritance structure

in the type graph in the way that the rule is applicable

for any type of ports, i.e. for external, internal, input

and for output ports.

Formally, a graph transformation step from Gto H

via a rule pand a match mis defined by two pushout

diagrams (1) and (2) as shown in Def. 4. For the formal

definition of pushouts we refer to [5]. The main ideas are

the following. Given a match of the LHS of the rule into a

graph Gthen this concrete part is replaced by the RHS of

the rule if the rule is applicable, which requires that the

gluing condition is satisfied and the match is NAC con-

sistent. A negative application condition (NAC) speci-

fies a negative pattern that must not occur at the match

when applying the rule. The gluing condition requires

that the identification and dangling points are gluing

points, i.e. that they are preserved and thus belong to the

set GP =lV(Vk)∪lE(EK). The identification points are

those nodes and edges that are matched non-injectively

in G, i.e. at least two elements are mapped to the same

element in G. The dangling points specify those nodes

which are matched to nodes in G, such that there is

an adjacent edge which is not deleted by the rule. This

means that the edge would remain dangling by removing

the node. Thus, an identification or a dangling point is

never deleted. The gluing condition ensures the existence

of the intermediate object Dand it has to be checked

only for deleting rules.

If a rule pis applicable to Gvia m:L→Gthen

the graph transformation step G=

⇒His performed

by first deleting all elements in Gthat are matched by

the rule but not preserved, i.e. they do not occur in the

intersection Kof the LHS and RHS of the rule. The

deletion leads to an intermediate graph D. The second

step is performed by adding those elements to Dthat

are in the RHS of the rule but not in Kleading to the

resulting graph H.

Definition 4 (Typed Graph Transformation Step)

Given a rule p= (L←

−K−

→R)with NACs and a match

m:L→Gthen pis applicable to Gvia mif the gluing

condition is satisfied and the match is NAC consistent.

The match is NAC consistent, if for each NAC n:L→

Nof pthere is no injective q:N→Gcompatible with

m, i.e. with q◦n=mas shown in the triangle diagram

(0). Given a rule pthat is applicable to Gvia m, then

the graph transformation step G=

p,m

==⇒His defined by

the two pushouts (1) and (2).

q$$



(1)

(0)

oor//



(2)



G D

//H

Example 8 (Typed Graph Transformation Step) The

graph transformation step in Fig. 19 shows the appli-

cation of the rule “glue” at a graph G, which contains

14 Christoph Brandt et al.

1 : Point

2 : Port r3:glue

1 : Point

2 : Port

1 : Point

2 : Port

G1 : Point

2 : ExtIP

: ExtOP

:glue

: ELABT : Reo

:port

D1 : Point

2 : ExtIP

: ExtOP

:glue

: ELABT : Reo

:port

H1 : Point

2 : ExtIP

: ExtOP

:glue

: ELABT : Reo

:port

r3:glue

(1) (2)

Fig. 19 Application of Rule “glue”

G1 : Point

2 : ExtIP

: ExtOP

:glue

: ELABT : Reo

:port

H1 : Point

2 : ExtIP

: ExtOP

:glue

: ELABT : Reo

:port

r3:glue

⇒

glue

Compact Notation

Fig. 20 Application of Rule “glue” in Compact Notation

an elementary ABT node with an external output port

and a Reo connector with an external input port. The

match mis denoted by the numbers “1” and “2”. The

rule is applicable, because no node is deleted and the

NACs are fulfilled, i.e. nodes “1” and “2” are not con-

nected already and the involved ports do not belong to

the same Reo connector. In a first step we construct D

as subgraph of G, where all elements of L\Kare deleted.

In our case we have G=D, because L=K. In a second

step we glue together graphs Dand Rvia Kresulting

in graph H. This gluing construction is formally given

by a pushout in the category of graphs [5]. In fact, both

diagrams (1) and (2) in Fig. 19 are pushouts leading to

a transformation step G=

p,m

==⇒Hvia rule p=glue and

match m. Figure 20 shows the transformation step in

compact notation leaving the DPO diagram implicit.

A graph grammar consists of a type graph together

with a typed start graph and a set of typed rules. The

language generated by this grammar consists of all typed

graphs that can be obtained by applying a sequence of

rules to the start graph.

Definition 5 (Typed Graph Grammar) A typed

graph grammar GG = (TG,SG, P )consists of a type

graph TG, a start graph SG and a set of graph rules P

also called productions, both typed over TG. The typed

graph language L(GG)of GG is defined by L(GG) =

{G| ∃ typed graph transformation SG =⇒∗Gin GG}.

Example 9 (Construction Grammar) The graph gram-

mar GGCON−ABT = (T GABT −Reo,∅, PCON ) consists of

the type graph shown in Fig. 15, the empty graph as

start graph and the set PCON of construction rules. Some

of the rules of PCON are shown in Figures 16, 17 and 18.

Similar to the shown rules for adding structure parts the

set PCON also contains the inverse rules for deleting such

elements [6]. Since the rules are very compact they can

be combined with general editing steps in a visual devel-

opment environment, where only the concrete syntax is

displayed to the modeler.

3.2 Correction of Non-Well-formed Models by

Correction Graph Grammars

During the development of ABT-Reo models in a visual

editor - based on the grammar GGCON−ABT from the

previous section - the edited models may not satisfy the

well-formedness rules of the language of ABT-Reo di-

agrams defined in [11]. Therefore, this section presents

how a second grammar GGCOR−ABT is used to detect

and highlight incomplete as well as incorrect parts, such

that they can be deleted manually or corrected automat-

ically depending on the preference of the modeler.

More precisely, the set of correction rules PCOR of

the correction grammar GGCOR−ABT is used for the de-

tection and correction of non-well-formed patterns. The

detection is performed by checking the applicability of

the rules of GGCOR−ABT . If a rule is applicable, then

the found match specifies the location of the problem-

atic pattern and the rule describes the type of the oc-

curred problem. The automated correction is performed

by applying the correction rule. An overall correction

is obtained by applying the correction rules as long as

possible. As an alternative, the modeler can choose to

correct some of the highlighted parts himself.

Using the construction and the correction grammar

we intend to be able to construct all well-formed ABT-

Reo diagrams - and similar other well-formed diagrams

- in the following way. We first use the editing rules

of the construction grammar to construct a transfor-

mation sequence ∅=⇒G1=⇒. . . =⇒Gnvia the rules

PCON of the construction grammar. In a second step

the rules PCOR of the correction grammar are applied

as long as possible to Gnleading to a transformation

sequence Gn=⇒. . . =⇒Gmvia PCOR. Assuming that for

each non-well-formed pattern in any graph Gtyped over

TGABT −Reo there is a corresponding rule in PCOR ap-

plicable to G, we can be sure that Gmis well-formed, if

Gmis terminal with respect to PCOR. Fortunately, there

are results in the algebraic theory of graph transforma-

tions assuring termination based on suitable termination

criteria for typed graph grammars. A graph grammar

GG = (TG,SG, P ) is called to be terminating, if there

is no infinite transformation sequence from SG via P.

Theorem 1 Every typed graph grammar GG =

(TG,SG, P )is terminating, if the termination criteria

1-4of Theorem 3.37 in [5] are satisfied.

Enterprise Modelling using Algebraic Graph Transformation - Extended Version 15

Another interesting question is whether the correc-

tion process leads to a unique result independently of

the order in which the correction rules are applied. The

uniqueness property is valid, if the graph grammar is

confluent. Confluence is based on critical pairs, which

specify conflicts in a minimal context. An important re-

sult is that confluence is assured by local confluence and

termination. For local confluence we have the following

result (see Thm. 3.34 in [5]).

Theorem 2 A typed graph grammar is locally confluent

if all its critical pairs are strictly confluent.

Based on this theorem there are analysis techniques

which offer sufficient conditions for local confluence. In

fact, we can statically analyse whether the order in which

the correction rules are applied is relevant or not for the

final result of any correction process. In the case of guar-

anteed confluence the automated correction is always de-

terministic. This means that the modeler can apply any

of the applicable correction rules without the risk that

the correction of another fragment becomes impossible

or will cause a backtracking.

RHS

⇒

deleteCompABT

LHS

: CompABT

Fig. 21 Rule “deleteCompABT” of GGCOR−ABT

NAC1 RHS

LHS

2 : Port

1 : Point

:glue

2 : Port

1 : Point

2 : Port

: AR

:port

deletePortAtPoint

⇒

Fig. 22 Rule “deletePortAtPoint” of GGCOR−ABT

Example 10 (Correction Grammar) The graph grammar

GGCOR−ABT = (T GABT −Reo,∅, PCOR) consists of the

type graph shown in Fig. 15, the empty graph as start

graph and the set PCOR of correction rules. Two rules of

PCOR are shown in Figures 21 and 22. The rule “delete-

CompABT” in Fig. 21 is applicable if the node of type

“CompABT” is not connected to any edge, which im-

plies that the composite ABT has no internal structure.

Since composite ABT elements are required to contain

some internal elements this part of the model is incom-

plete, which can be highlighted in the editor. Applying

the rule will delete this node. The rule “deletePortAt-

Point” in Fig. 22 is applicable if the port “2” is not

connected to a node of type “AR”, i.e. it is neither con-

nected to a Reo connector nor to an ABT node. Again

this incomplete pattern is detected and the edge to its

connected point is deleted by the application of the rule.

Another correction rule for deleting points without any

adjacent edge may become applicable thereafter and in

this case a new problematic pattern will be detected.

3.3 Checking Requirements by Graph Constraints

In addition to well-formedness discussed in the previous

section, enterprise models have to fulfil functional and

non-functional requirements, e.g. security norms, which

depend on the particular domain. In order to automati-

cally analyze and verify the compliance of models to spe-

cific requirements and norms we propose a formalization

of a practicable subset of the norms and requirements by

graph constraints, which show several advantages. They

offer a compact and intuitive visual notation and they

can be checked automatically. Since the models in the

scenario of the paper are based on the abstract syntax

graphs we can analyze the norms and requirements by

checking the corresponding graph constraints. If needed,

graph constraints can be nested leading to the full ex-

pressiveness of first order logic as shown in [24].

A graph constraint consists of a premise pattern P

together with a conclusion pattern Cand a morphism

a:P→Cthat relates the elements of the premise

with those of the conclusion. A graph Gfulfils a graph

constraint a:P→Cif for any occurrence of the premise

Pthere is also an occurrence of the conclusion Cat the

same position of the graph. Graph constraints can be

extended to boolean formulae as specified in [5].

Definition 6 (Graph Constraint) A graph constraint

PC(a)consists of a graph Pcalled premise, a graph C

called conclusion and a graph morphism a:P→Cthat

relates Pwith C. A graph Gfulfils PC(a)if for any

injective graph morphism p:P→Gthere is also an

injective graph morphism q:C→Gcompatible with p,

i.e. q◦a=p.P



a//

(=)





Example 11 (Graph Constraint) Figure 23 shows the

graph constraint “pubclicIsEncrypted” for ABT-Reo

models [11] in the IT-universe. The constraint requires

that any public Reo element is connected to two ABT

nodes, which implement encryption and decryption of

communication data. This constraint formalizes the fol-

lowing verbal norm: “Confidential communication data

cannot be intercepted in plain text by eavesdropping at

public channels”. The model M1in Fig. 13 fulfils this

constraint, because for each public Reo-connector there

are ABT-nodes of type “E/D” (encryption/decryption)

as required by conclusion Cof the constraint. Figure 24

16 Christoph Brandt et al.

E1:E/D

C : ExtIP

: Point

: ExtOP : ExtOP

: Point

name = "public"

1 : Reo

:port :port :port

:glue

:glue :glue

:glue

PC: publicIsEncrypted

abstract syntax

concrete

syntax

1:public 1:public E2:E/D

name = "E/D"

E2 : ELABT

: ExtIP

:port

name = "E/D"

E1 : ELABT

name = "public"

1 : Reo

Fig. 23 Graph Constraint for IT-models

1(*construct graphs P and C *)

2(*Nodes and Edges of premise graph P *)

3PNodes={{1,ABTReo$Reo}};

4PEdges={};

5(*Nodes and Edges of conclusion graph C *)

6...

7(*construct graphs P and C *)

8publicIsEncryptedP=

9makeTypedGraph[PNodes,PEdges,ABTReo$TypeGraph];

10 publicIsEncryptedC=

11 makeTypedGraph[CNodes,CEdges,ABTReo$TypeGraph];

12 (*construct constraint (P -> C) *)

13 publicIsEncrypted=makeGraphConstraint["atomic",

14 {publicIsEncryptedP,publicIsEncryptedC}];

Fig. 24 Mathematica Source Code of “publicIsEncrypted”

1In:= checkGraphConstraint[Model1,publicIsEncrypted]

2Out:= True

Fig. 25 Compliance Check of a Graph Constraint

shows the Mathematica source code for the graph con-

straint “publicIsEncryped” and Fig. 25 shows the oper-

ation call in Mathematica for checking the graph con-

straint on model M1of Fig. 13.

If we know already that a graph Gsatisfies a graph

constraint P C(a) we would like to know under which

conditions a graph transformation step G=

p,m

==⇒Hpre-

serves this constraint, i.e. also Hsatisfies P C(a). This

would avoid to check explicitly, if Hsatisfies P C(a). For

this purpose we only have to check whether the match

m:L→Gsatisfies a suitable application condition us-

ing the following general result for algebraic graph trans-

formation (see Thm. 7.23 in [5]). By A(p, a) we denote

the the application condition for the rule pthat is de-

rived from P C(a).

Theorem 3 For each graph constraint P C(a)and each

production pthere is an application condition A(p, a)for

psuch that for all graph transformation steps G=

p,m

==⇒H

we have: Hsatisfies P C(a), if Gsatisfies P C(a)and m

satisfies the application condition A(p, a).

3.4 Summary of Achievements for Intra-Modelling

Techniques

In this section we have obtained the following achieve-

ments concerning intra-modelling techniques using alge-

braic graph transformations:

1. We have shown how to construct well-formed mod-

els, especially well-formed ABT-Reo models, using

construction and correction graph grammars.

2. By Thm. 1 there are termination criteria, which en-

sure that after arbitrary construction steps the cor-

rection process terminates. Moreover, this process

leads to a unique result independent of the order of

correction steps - if according to Thm. 2 all critical

pairs of the correction grammar are strictly conflu-

ent.

3. We have shown how to model and check func-

tional and non-functional requirements by graph con-

straints, where Thm. 3 shows how to preserve such

requirements under graph transformation steps.

After we have presented intra-modelling techniques

for the construction and analysis of business and IT

service models the next section presents suitable inter-

modelling techniques.

4 Inter-Model Techniques

Enterprise modelling encompasses several heterogeneous

aspects of the enterprise as shown in the model frame-

work of Fig. 5. Hence, an adequate framework for enter-

prise modelling has to support the integration of dif-

ferent domain specific languages that are appropriate

for the specific aspects and satisfy the preferences of

the modelers. This section shows how inter-model tech-

niques are applied in a formal and consistent way in

order to ensure important properties, such as correct-

ness and completeness. The techniques are based on the

abstract syntax graphs of the models, which can be ob-

tained as described in Sec. 3.

The application of the inter-model techniques leads

to a substantial gain in model-based interoperability

in the following ways. During the development process

models are integrated and inconsistencies are automat-

ically detected. Furthermore, existing models of partic-

ular source domains are transformed to models that be-

long to related target domains. This way the new models

in the target domains can be used for further refine-

ment in order to derive fully developed models. In ad-

dition, the new models can be checked against the non-

functional requirements of the target domain. A viola-

tion of these requirements shows an inconsistency, which

can be resolved by modifications of the source and the

target model.

The inter-model techniques have to ensure correct-

ness and completeness in order to produce reliable re-

sults. Therefore, we apply the well founded approach of

Enterprise Modelling using Algebraic Graph Transformation - Extended Version 17

model transformation and model integration based on

triple graph grammars [27,30,31] for which these char-

acteristics are shown. Besides theses formal results triple

graph grammars convince by its intuitive specification

of compact patterns that show how typical model frag-

ments shall be related. Based on these patterns opera-

tional rules for model transformation and integration are

derived automatically.

The following section presents the main concepts of

triple graph grammars, where we intuitively describe the

used techniques but refer to [30,31] for the formal de-

tails. Thereafter Sections 4.2 to 4.4 explain the concepts

of model integration, model transformation and prop-

agation of constraints based on triple graph grammars.

All concepts are illustrated by an application to business

and IT service models given as ABT-Reo diagrams, i.e.

an application to models in the coordinates (S, B, M)

and (S, I, M) of the model framework in Fig. 5. For this

reason we substantially extend the examples of [26]. Note

that the techniques can be used also for source and tar-

get modelling languages that are quite different like class

diagrams and relational databases as in [31], such that

an application of the techniques to languages in other

coordinates of the enterprise model framework shall be

possible. While triple graph grammars are defined for

the abstract syntax graphs of models we present their

application by showing the model components in con-

crete syntax, i.e. by a visualization of the abstract syntax

graphs as explained in [28]. This way the presentation is

more compact and intuitive for this paper, but the cor-

responding formal theory in [30,31] is based on abstract

syntax graphs.

4.1 Inter-Modelling by Triple Graph Grammars

In the following we lift the concepts of graph transfor-

mation to the case of triple graphs, an extension of plain

graphs dividing elements into source, target and corre-

spondence sections which are connected by graph mor-

phisms. This extension improves the definition of model

transformations, where models of a source language are

translated to models of a target language and correspon-

dence elements can be used to guide the creation of the

sequence of transformation steps. Similarly, triple graph

transformations are suitable for model integration, which

takes a source and a target model and sets up the missing

correspondences between both models.

Example 12 (Triple graph) The triple graph in Fig. 26

shows an integrated model consisting of a business ser-

vice model in the source component (left) and an IT ser-

vice model in the target component (right). Both models

are ABT-Reo diagrams, i.e. they contain abstract be-

haviour type nodes that are connected by Reo connec-

tors. The source model specifies that the data in the

communication channels between the private banking

Filter

E/D

public

E/D

public

NW4:LAN

NW7:LAN

private

Private_Banking:Department

Investment_Banking:Department

private

public

private

public

MS,B,M MS,I,M

Fig. 26 Triple Graph with models MS,B,M and MS,I,M

and investment banking departments is filtered. The fil-

ter has to ensure that the communicated data does not

contain files which contain both, address and balance

information. The target model on the other side spec-

ifies the IT service structure. The local area networks

“NW4” and “NW7”, which are used in the private bank-

ing and investment banking departments, are connected

via an encrypted communication channel shown by the

ABT nodes of type “E/D” for encryption and decryp-

tion. The corresponding elements of both models are re-

lated by graph morphisms (indicated in grey) from the

correspondence graph (light blue) to source and target,

respectively.

Model transformation as well as model integration do

not require deletion during the transformation. The re-

sult of a model integration is the triple graph of the triple

transformation sequence. In the case of model transfor-

mations the result is obtained by restricting the resulting

triple graph to its target component. Thus it is sufficient

to consider triple rules that are non-deleting. This im-

plies that the first step in the DPO graph transforma-

tion approach can be omitted, because the creation of

elements is performed in the second step.

Source TargetCorrespondence

Point

A2A

P2P

ABT

Point

Abstract

Syntax

...

TGABT-Reo TGCTGABT-Reo

...

Concrete

Syntax

Source Target

Correspondence

Name Name

...

TGABT-Reo TGCTGABT-Reo

...

ELABT CompABT

ABT

Fig. 27 Triple Type Graph TGB2IT

18 Christoph Brandt et al.

Example 13 (Triple Graph Grammar) The triple graph

grammar TGGB2IT = (TGB2IT , SB2IT ,TRB2IT ) spec-

ifies how business service models and IT service mod-

els given as ABT-Reo diagrams are related and its type

graph is shown in Fig. 27 in abstract and concrete

syntax. The language of ABT-Reo diagrams is used

for both, the source and the target language and the

type graph shows a correspondence between the relevant

types, which are “ABT” for abstract behaviour type el-

ements and “Point” for the gluing points between input

and output ports of ABT elements and Reo connectors.

The start graph SB2IT is empty and Figures 28 to 30

show some of the triple rules of TRB2IT . Each rule spec-

ifies a pattern that describes how particular fragments

of business and IT models shall be related.

The first rule “DepartmentToLAN” synchronously

creates two ABT elements and a correspondence node

that relates them. This reflects the general correspon-

dence between departments in the business view and the

installed local area networks in the IT view. The rule is

presented in complete and in compact notation as well

as using the concrete syntax. The complete notion shows

that a triple rule consists of a triple graph for the left

hand side (upper one in the figure), a triple graph for

the right hand side (lower one one in the figure) and the

relating morphism in between. Thus, triple rules are non-

deleting and the intermediate graph Kas it appears for

plain graph transformation rules in Sec. 3 is not needed.

The compact notation for triple rules combines the left

and the right hand side of a rule, i.e. the rule is shown

by a single triple graph with special annotations. All el-

ements that are created by the rule, i.e. which appear in

the right hand side only, are marked by green line colour

and double plus signs. The concrete syntax of the rule

shows the ABT diagrams in visual notation, where the

attribute “name” is used as label of the visual elements.

The further figures show rules in compact notation

and in concrete syntax. Similarly to the first rule the rule

“PublicToPublic” has also an empty left hand side. It

synchronously creates two Reo connectors on both sides

and they are related by the points at their input and out-

put ports. The rule “FilterToED” is slightly more com-

plex and shows the pattern how filters in business models

correspond to encrypted connections in the related IT

model. This reflects the abstract business requirement

of hiding confidential information and its possible im-

plementation by encryption in the IT domain. Note that

the left hand side of this rule corresponds to the right

hand side of rule “PublicToPublic”.

Private connections leading to related and secured

public connections are related by the rule “PrivateIn-

ToPrivateIn”. The last rule “FilteredOutToPrivateOut”

in Fig. 30 specifies how outgoing communication from a

secured connection is handled. The private outgoing con-

nection in an IT model corresponds to the gluing of the

filtered public connection to the target ABT element,

which is defined by the box with the label “attach”.

This box specifies the explicit creation of elements in

the source component based on the underlying abstract

syntax, where an input port for the ABT node “S2” and

the linking edges to the existing nodes are created.

The triple rule “PublicToPublicExtend” for symmet-

ric communication is omitted, because it is similar to

“FilterToED” and it is not needed for the example trans-

formations, but it is shown in [6].

Complete

notation

Compact

notation

name = "LAN"

: ELABT

name = "Department"

: ELABT

name = "LAN"

: ELABT

name = "Department"

: ELABT

++ ++ ++ ++ ++

:LAN

:Department :A

++ ++

Compact

notation

Abstract Syntax Concrete

Syntax

: A2A

Fig. 28 Triple Rule “DepartmentToLAN”

Triple Rule PublicToPublic

++ ++ ++

++ ++

Compact

notation

:public

Fig. 29 Triple Rule “PublicToPublic”

Considering the model framework in Fig. 5 there may

be the following situations during the development of

the models. First of all, two models that should be in-

tegrated may be unrelated, thus performing model inte-

gration may detect conflicts between them. Furthermore,

some model instances within the model framework may

not exist already, e.g. business process models and IT

service models usually exist while business service mod-

els may not be developed. The interesting challenge is to

automatically retrieve parts of the missing models from

the existing ones in order to improve interoperability

between system components and enterprise components

in general. For this purpose, model transformation can

be applied e.g. on business process models to derive IT

process models and on IT service models to derive ba-

sic business service models. The results can be checked

against integration conflicts with respect to the other

existing models.

The following sections show that triple graph gram-

mars are a suitable basis for the described needs. We

exemplarily show how operational rules for model trans-

formation and integration are derived from the original

Enterprise Modelling using Algebraic Graph Transformation - Extended Version 19

Triple Rule FilterToED

Compact

notation

:Filter :E/D

:E/D

++ ++ ++

S1:public

:P T1:public

S2:Filter T2:E/D

T3:public

T1:LAN

:private

S1:Department

:private

S3:public

Compact notation

Triple Rule PrivateInToPrivateIn

T3:E/D

S1:Filter T1:E/D

T2:public

T3:E/D

T4:LAN

private

S2:Department

S3:public

Triple Rule FilteredOutToPrivateOut

name = "Department"

S2 : ELABT

: ExtIP

: Point

:glue

:port

attach

Fig. 30 Further Triple Rules of TGGB2IT

triple graph grammar. The underlying formal construc-

tion enables an automatic derivation of the operational

rules as described in [27,7,32]. The application of the

operational rules is controlled, such that correctness and

completeness with respect to the patterns are ensured for

the resulting models [31]. The techniques are illustrated

based on the given scenario of IT and business service

models given by ABT-Reo diagrams.

4.2 Model Transformation based on Forward Rules

As described in Sec. 4.1 triple rules can be used to spec-

ify how two models can be created simultaneously. Thus,

triple rules allow the modeler to define patterns of cor-

respondences between model fragments. Based on these

triple rules the operational forward rules for model trans-

formations from models of the source language to models

of the target language are derived automatically. Since

triple rules have a symmetric character, the backward

rules for backward model transformations from models

of the target to models of the source language are also

derived automatically. In this section we present both di-

rections and show the application in our scenario for the

forward case. In Sec. 4.4 we will reuse the operational

rules for propagating constraints from one domain to a

related domain and illustrate the constructions for the

backward case.

Operational rules for model transformations are for-

ward and backward rules for forward and backward

transformations. Both kinds are derived from the triple

rules that specify pattern by pattern how integrated

models are created, i.e. how source and target models are

developed synchronously. Given a triple rule its forward

rule is derived by replacing the source component in the

left hand side by the source component in the right hand

side. This way the rule requires a complete fragment in

the source component of an integrated model and com-

pletes the missing parts for the correspondence and tar-

get components. Similar to the forward case backward

rules are derived in order to perform backward model

transformations.

31 shows the triple rule “FilterToED” and its derived

forward rule “FilterToEDF”, where the source compo-

nent is now identical in the left and right hand side of

the forward rule. The forward rule is used to transform

a filter into two ABT nodes of the type “E/D”, which

implement the encryption and decryption of communi-

cation data. The underlying idea here is that confiden-

tial communication in a business universe is filtered out

while in the IT universe the data is encrypted for public

channels. Since the left hand side of the forward rule con-

tains already all source elements of the right hand side

of the triple rule, the item “S1” appears in both, in the

left and in the right hand side. The specification of the

triple rule and the automatic derivation of its forward

rule in the AGT Mathematica (AGTM) implementation

[6] is shown in Fig. 31.

In order to perform model transformations based on

the derived forward rules a given source model is ex-

tended to a triple graph G0with an empty correspon-

dence and an empty target component. The transforma-

tion starts with this triple graph. Each step of the trans-

formation starts with the computation of the possible

matches from the left hand sides of the forward rules to

the current triple graph. A valid match according to the

on-the-fly construction in [31] is chosen and the forward

step is performed. The resulting target model of a model

transformation based on forward rules is obtained by re-

stricting the final triple graph to its target component.

This construction leads to a source consistent forward se-

quence that defines the model transformation sequence.

Example 14 (Model Transformation) Using the pre-

sented triple rules and its derived forward rules, the busi-

ness service model MS,B,M is transformed to the IT ser-

vice model MS,I,M . The model transformation sequence

consists of the following 6 forward transformation steps

and is shown in Figures 32 and 33:

20 Christoph Brandt et al.

Triple Rule FilterToED

Forward Rule FilterToEDF

:Filter :E/D

:E/D

++ ++ ++

Compact

notation

S1:public

:P T1:public

Compact

notation

S2:Filter :E/D

:E/D

++ ++ ++

S1:public :P

:P T1:public

1(*creation of graphs SL,CL,TL,SR,CR and TR *)

2...

3FilterToED$L = TGGmakeGraph[SL,CL,TL];

4FilterToED$R = TGGmakeGraph[SR,CR,TR];

5(*TGG rule: L, R and application conditions *)

6FilterToED = TGGmakeRule[FilterToED$L,FilterToED$R,

7{}];

8FilterToEDF = TGGforwardRule[FilterToED];

Fig. 31 Triple Rule, Derived Forward Rule and Mathemat-

ica Source Code

G0=

DepartmentToLANF

=============⇒G1=

DepartmentToLANF

=============⇒G2

PublicToPublicF

==========⇒G3=

FilterToEDF

========⇒G4

PrivateInToPrivateInF

==============⇒G5=

FilteredOutToPrivateOutF

=================⇒G6

where G0= (MS,B,M ← ∅ → ∅). At each step a part of

the source model is completed by the missing elements in

the correspondence and target component. The matches

of the forward rules do not overlap on their effective ele-

ments, which are given by RS\LSof the specified triple

rule and visualized by green colour and plus signs in the

source components of the triple rules. Furthermore, each

element in MS,B,M is matched by an effective element

of a forward rules. Both properties are ensured by a for-

mal condition, called source consistency, which controls

the forward transformation. This way each source ele-

ment is translated exactly once and the resulting triple

graph is a well formed integrated model. The resulting

triple graph G6is shown at the bottom of Fig. 33 and

coincides almost with the triple graph in Fig. 26. Only

the labels “NW4” and “NW7” for the nodes of type

“LAN” are left blank. Such information cannot be de-

termined by the information of any source model and

therefore, the triple rules create blank labels. But note

that real attributes are processed and computed during

the model transformation, e.g. the connector type “pub-

lic” is specified as an attribute of a Reo connector in

PublicToPublicF

:Filter

public

:LAN

Private_Banking:Department

Investment_Banking:Department

private

public

DepartmentToLANF

:Filter

:LAN

Private_Banking:Department

Investment_Banking:Department

private

public

DepartmentToLANF

:Filter

:LAN

Private_Banking:Department

Investment_Banking:Department

private

public

:Filter

Private_Banking:Department

Investment_Banking:Department

private

public

Business Model MS,B,M

Fig. 32 Model Transformation Sequence Part 1

the abstract syntax. The result of of the forward trans-

formation is given by the target component MS,I,M of

G6= (MS,B,M ←G6,C →MS,I,M ). Figure 34 shows

the model transformation in one step from its source

model as input to its target model as output. The figure

additionally contains the corresponding operation calls

in the Mathematica implementation AGTM. Note that

some transformation steps in this sequence are sequen-

tially independent, e.g. the second and the third step are

Enterprise Modelling using Algebraic Graph Transformation - Extended Version 21

:Filter

:E/D

public

:E/D

:LAN

private

Private_Banking:Department

Investment_Banking:Department

private

public

Business Model

MS,B,M

IT Model

MS,I,M

Correspondence

FilterOutToPrivateOutF

PrivateInToPrivateInF

FilterToEDF

:Filter

:E/D

public

:E/D

:LAN

private

Private_Banking:Department

Investment_Banking:Department

private

public

:Filter

:E/D

public

:E/D

:LAN

Private_Banking:Department

Investment_Banking:Department

private

public

Fig. 33 Model Transformation Sequence Part 2

independent. They can be switched leading to an equiva-

lent sequence. For this reason, the notion of parallel inde-

pendence of forward transformation steps in [31] is used

and analyzed during the transformation. This allows to

avoid the computation of the equivalent sequences.

Model transformations based on source consistent

forward sequences are correct and complete with respect

to the triple patterns [31], i.e. with respect to the lan-

guage VL ={G| ∅ =⇒∗Gin TGG}containing the

:Filter

Private_Banking:Department

Investment_Banking:Department

private

public

Business Model MS,B,M

:E/D

public

:E/D

:LAN

private

IT Model MS,I,M

Forward MT

1(*Grammar: Forward Triple Rules ABTReo$RulesMT and

2Integrated Type Graph TripleTG$A2A *)

3ABTReo$GrammarMT={ABTReo$RulesMT, TripleTG$A2A};

4(*Apply Model Transforamation to Model M_SBM *)

5ModelSIM = TGGmodelTrafo[ModelSBM, ABTReo$GrammarMT];

Fig. 34 Model Transformation of Service Models

integrated models generated by the triple rules. More

precisely, each model transformation translates a source

model into a target model, such that the integrated

model that contains both models can be created by ap-

plications of the triple rules to the empty start graph.

This means that both models can be synchronously cre-

ated according to the triple patterns. Vice versa, model

transformation can be performed on each source model

that is part of an integrated model in the generated triple

language VL.

The languages of translatable source models VLSand

of reachable target models VLTare given by

VLS={GS|(GS←GC→GT)∈VL}and

VLT={GT|(GS←GC→GT)∈VL}. Based on these

definitions there is the correctness and completeness re-

sult below according to Theorems 2 and 3 in [33].

Theorem 4 (Correctness and Completeness)

–Correctness: Each model transformation sequence

given by (GS, G0=

tr∗

==⇒Gn, GT), which is based on

a source consistent forward transformation sequence

G0=

tr∗

==⇒Gnwith G0= (GS← ∅ → ∅)and

Gn= (GS←GC→GT)is correct, i.e. GS∈V LS

and GT∈V LT.

–Completeness: For each GS∈V LSthere exists

GT∈V LTwith a model transformation sequence

(GS, G0=

tr∗

==⇒Gn, GT)where G0=

tr∗

==⇒Gnis source

consistent with G0= (GS← ∅ → ∅)and Gn=

(GS←GC→GT).

The result in Thm. 4 goes beyond the available

results for other graph transformation approaches, for

which the available results can only ensure the syntacti-

cal correctness of the resulting target models. In addition

to the correctness and completeness result, the triple

22 Christoph Brandt et al.

graph transformation approach benefits from its intu-

itive triple patterns of corresponding fragments, which

substantially increases usability and maintainability.

4.3 Model Integration based on Integration Rules

The purposes of model integration are first of all in-

teroperability in general and the analysis of consistency

within the overall enterprise model in particular. Con-

ceptually, the challenge of model integration is different

from model transformation. However, both techniques

can be based on triple graph transformation and thus,

they are strongly related in our case. The starting set of

triple rules is even the same - the only differences occur

in the derivation of operational rules and the definition

of the control conditions for the execution. This section

shows the technical constructions and presents the cor-

rectness and completeness result, which is similar to the

case of model transformation.

Triple Rule FilterToED

Integration Rule FilterToEDI

Compact

notation

Compact

notation

:Filter :E/D

:E/D

++ ++ ++

S1:public

:P T1:public

S2:Filter T2:E/D

T3:E/D

++ ++

S1:public :P

:P T1:public

1FilterToEDI = TGGintegrationRule[FilterToED];

Fig. 35 Derived Integration Rule FilterToED Iand Mathe-

matica Source Code

Analogously to forward rules, integration rules are

derived from the set of triple rules, which describe the

patterns of the relations between two models. An inte-

gration rule is obtained from a triple rule by replacing

the source and the target component of the left hand

side by the source and target components of the right

hand side, such that only the correspondence part re-

mains different. This way, a match of the rule requires

that all fragments of the triple pattern in the source and

target component are present before applying the rule,

such that only the correspondences are added to com-

plete the triple pattern.

Example 15 (Integration Rule) Figure 35 shows the

triple rule “FilterToED” and its derived integration rule

“FilterToEDI”. The triple rule synchronously extends a

public connector by a filter in the business model and

its corresponding two de/encryption elements in the IT

model. Thus, an application of the integration rule com-

pletes the correspondence structure of existing and al-

ready related public connectors that have adjacent filter

resp. de/encryption elements.

Model integration based on triple graph transforma-

tion is defined by integration sequences, in which the

derived model integration rules are applied. Given a

source and a target model their integration is performed

by completing the correspondence structure that relates

both models. The consistency of a model integration is

ensured by a formal condition, called S-T-consistency

[30]. This condition ensures that the given source and

target models are completely parsed using the inverted

triple rules restricted to the source and target compo-

nent, respectively. Thus, each fragment of the models is

processed and integrated exactly once.

Example 16 (Model Integration) Figures 36 to 38 shows

the integration of models MS,B,M and MS,I,M , i.e. the

creation of the correspondence relation between them via

a correspondence graph. The model integration is based

on an S-T-consistent integration sequence consisting of

the following 6 steps using the derived model integration

rules as shown in Figures 36 and 37:

G0=

DepartmentToLANI

============⇒G1=

DepartmentToLANI

============⇒G2

PublicToPublicI

==========⇒G3=

FilterToEDI

=======⇒G4

PrivateInToPrivateInI

==============⇒G5=

FilteredOutToPrivateOutI

================⇒G6

with G0= (MS,B,M ←∅→MS,I,M ).

In the first four steps some fragments of the source

and target components are completed by the missing ele-

ments in the correspondence component. In the two last

steps no correspondence nodes are created. The reason

is the following. The triple rules “PrivateInToPrivateIn”

and “FilteredOutToPrivateOut” extend integrated frag-

ments in the source and target model by connecting

Reo elements and they do not create any correspondence

node. Therefore, the derived integration rules do not cre-

ate correspondences either. But these integration rules

are necessary to ensure correct integrations in the way

that the positions of the corresponding private Reo con-

nectors are checked.

The matches of the integration rules do not over-

lap on their effective elements, which are given by

RS∪RT\LS∪LTof the specified triple rule and visu-

alized by green colour and plus signs in the source and

target components of the triple rules. Furthermore, each

element in MS,B,M and MS,I,M is matched by an effec-

tive element of an integration rule. Both properties are

Enterprise Modelling using Algebraic Graph Transformation - Extended Version 23

PublicToPublicI

DepartmentToLANI

Business Model MS,B,M

:Filter :E/D

public

:E/D

NW4:LAN

NW7:LAN

private

Private_Banking:Department

Investment_Banking:Department

private

public

:Filter :E/D

public

:E/D

NW4:LAN

NW7:LAN

private

Private_Banking:Department

Investment_Banking:Department

private

public

:Filter :E/D

public

:E/D

NW4:LAN

NW7:LAN

private

Private_Banking:Department

Investment_Banking:Department

private

public

:Filter :E/D

public

:E/D

NW4:LAN

NW7:LAN

private

Private_Banking:Department

Investment_Banking:Department

private

public

IT Model MS,I,M

Fig. 36 Model Integration Sequence Part 1

ensured by the formal S-T-consistency condition, which

controls the integration sequence. This way each source

element and each target element is integrated exactly

once and the resulting triple graph is a well formed in-

tegrated model. The resulting triple graph G6is shown

at the bottom of Fig. 37 and coincides with the triple

graph in Fig. 26.

The result of the model integration is the completely

integrated triple graph of the sequence and it is shown

in the bottom part of Fig. 38, where the model integra-

:Filter

:E/D

public

:E/D

NW4:LAN

NW7:LAN

private

Private_Banking:Department

Investment_Banking:Department

private

public

Business Model

MS,B,M

IT Model

MS,I,M

Correspondence

FilterOutToPrivateOutI

PrivateInToPrivateInI

FilterToEDI

:Filter

:E/D

public

:E/D

NW4:LAN

NW7:LAN

private

Private_Banking:Department

Investment_Banking:Department

private

public

:Filter

:E/D

public

:E/D

NW4:LAN

NW7:LAN

private

Private_Banking:Department

Investment_Banking:Department

private

public

Fig. 37 Model Integration Sequence Part 2

tion is presented in a single step from the pair of the

source and the model as input to the integrated model

as output. Figure 39 shows the corresponding operation

calls in the Mathematica implementation AGTM.

Integration rules are used to establish or update the

correspondences between two models. The model frame-

work in Fig. 5 shows many coordinates, where models

should be integrated. Two models are consistent with

each other, if they can be completely integrated, other-

wise they show conflicts. Consistency between the mod-

24 Christoph Brandt et al.

:Filter

:E/D

public

:E/D

NW4:LAN

NW7:LAN

private

Private_Banking:Department

Investment_Banking:Department

private

public

Business Model

MS,B,M

IT Model

MS,I,M

Correspondence

:Filter

:E/D

public

:E/D

NW4:LAN

NW7:LAN

private

Private_Banking:Department

Investment_Banking:Department

private

public

Business Model

MS,B,M

IT Model

MS,I,M

Correspondence

Integration

Fig. 38 Model Integration for Service Models

1(*Grammar: Integration Triple Rules ABTReo$RulesMI and

2Integrated Type Graph TripleTG$A2A *)

3ABTReo$GrammarMI={ABTReo$RulesMI, TripleTG$A2A};

4(*Apply Model Integration to Model M_SBM *)

5ModelMI = TGGintegrate[ModelSBM,ModelSIM,ABTReo$GrammarMI];

Fig. 39 Operation Calls for Model Integration

els is ensured by checking S-T-consistency [30], which

means that the integration has to conform to a parsing

of the existing source and target model.

If two models cannot be fully integrated, i.e. no S−T-

consistent integration sequence can be found, then some

parts of the models cannot be related. For instance the

IT model may contain some communication paths that

are not modelled in the business model. Those synchro-

nization fragments are detected by computing the in-

tegration sequences with maximal coverage. Thereafter,

the remaining parts are marked for further synchroniza-

tion that shall be performed by the modelers. The syn-

chronization by the modeler can be supported by the

application of the derived forward and backward triple

rules in the way that additional fragments in one model

are translated to new ones in the other model.

Analogous to the forward case model integration

based on triple rules is correct and complete according

to Thm. 3 in [30] combined with the the result for the

forward case. This means that each model integration

leads to a triple graph that can be created by the appli-

cation of the specified triple rules. Vice versa, integration

can be performed for each pair of a source and a target

model that can be obtained from a model in the language

VL ={G| ∅ =⇒∗Gin TGG}containing all integrated

models generated by the original triple rules.

Theorem 5 (Correctness and Completeness)

–Correctness: Each model integration sequence given

by ((GS, GT), G0=

tr∗

=⇒Gn, Gn)which is based on the

S-T-consistent integration sequence G0=

tr∗

=⇒Gnwith

G0= (GS←∅→GT)is correct, i.e. Gn∈V L.

–Completeness: For each Gn∈V L there exists

a model integration sequence ((GS, GT), G0=

tr∗

=⇒

Gn, Gn), such that G0=

tr∗

=⇒Gnis S-T-consistent,

G0= (GS←∅→GT)and Gn= (GS←GC→GT).

After we have shown how models can be integrated

by model integration based on triple graph grammars,

the next section focusses on a further aspect concern-

ing the analysis of the requirements between different

domains.

4.4 Rule based Propagation of Constraints

Each domain in the model framework for enterprise mod-

elling in Fig. 5 is faced with several non-functional re-

quirements and quite a lot of them are hard requirements

given by e.g. security rules that the enterprise has to im-

plement. This means that the enterprise models have to

be checked against the non-functional requirements. A

local analysis of these requirements for single models is

presented in Sec. 3.3 based on intuitive and visual graph

constraints that are checked against the abstract syntax

graph of the model.

However, even if the existing models of one dimension

in the enterprise model framework in Fig. 5 respect the

non-functional requirements, there may be some other

models in an interconnected dimension that implicitly

violate the requirements. This effect occurs if there are

e.g. IT service models that are not related with busi-

ness models, because the business models for this aspect

of the enterprise are currently not developed. In this

case, the implementation of the modelled IT structure

may lead to a system, in which the non-functional busi-

ness requirements are not respected. The solution is to

transfer the requirements from the specific domain to its

interconnected domains and to analyze the propagated

requirements on the models of the new domains.

In this section, we show how the propagation of graph

constraints from one domain to an interconnected other

Enterprise Modelling using Algebraic Graph Transformation - Extended Version 25

domain can be performed, such that the constraint can

be interpreted in the new domain. This new technique

is based on the triple patterns for model transformation

and model integration, which we used already in Sections

4.2 and 4.3. Since graph constraints in general consist of

model fragments only, instead of full models, we have to

adapt the model transformation technique, such that the

model transformation rules can be applied on fragments.

The left hand sides of the model transformation rules

may be to large for the small fragments. For this reason,

we perform a maximal partial matching and borrow the

missing parts in order to apply the rule. This way, the

source component is extended by the borrowed elements,

which was not the case for the model transformations in

Sec. 4.2.

:E/D

1:public 1:public :E/D

Constraint: publicIsEncrypted

Fig. 40 Graph Constraint for IT Models

In order to illustrate the mechanism of constraint

propagation we reconsider the graph constraint for IT

models in Sec. 3.3 for ensuring secure communication

over public channels in local are networks, which is

shown in Fig. 40 in concrete syntax. The non-functional

requirement is formalized by the graph constraint in the

way that each public Reo connector that can be found

in a model (premise graph P) has to be connected to

ABT elements with encryption/decryption functionality

(conclusion graph C).

public public

public

public public

LHS RHS

Extended

Premise P+

Propagated

Premise P’

Backward Rule PublicToPublicB

Premise P

Common Part

for Partial Match

Extended

Premise P+

public

Fig. 41 Propagation with Borrowing for Premise P

Example 17 (Propagation of Graph Constraint) The

graph constraint “publicIsEncrypted” in Fig. 40 for

IT service models is propagated to a graph constraint

for business models. This means that we perform two

FilterToEDB

:E/D

:public

:Filter

S1:public

PublicToPublicB

:E/D

:public

Conclusion C

Propagated Conclusion C’

:E/D

:public

S1:public

Fig. 42 Propagation for Conclusion C

:E/D

1:public 1:public :E/D

Constraint publicIsEncrypted for IT-models

:Filter

1:public

C’P’

Constraint publicIsFiltered for business models

Propagation

Fig. 43 Constraint Propagation

backward transformations with borrowing - one for the

premise graph of the constraint and one for the con-

clusion graph. Borrowing means that we allow partial

matching for the model transformation rules and add

those parts, which are missing for deriving a total match

[6]. The borrowing is performed by a gluing based on

a pushout along the common parts of the left hand

side of a rule and the triple graph on which the rule

is applied. This construction is illustrated in Fig. 41

for the premise graph of “publicIsEncrypted”. The rule

“P ublicT oP ublicB” requires a Reo connector with ports

and points in the left hand side of the rule and there-

26 Christoph Brandt et al.

fore, the missing ports and points are borrowed for the

premise Pleading to the extended premise graph P+,

which in this example coincides with the left hand side

of the rule. The application of the rule results in a triple

graph containing the extended premise P+and the prop-

agated premise P0, which coincide in this example as

shown in Fig. 41. This step leads to the first step of the

propagation of the conclusion C, which is shown in Fig.

42. In the second step of the propagation of the con-

clusion graph Cwe can apply the rule “FilterToEDB”

and derive the triple graph containing the original con-

clusion Cand the the propagated conclusion C0, which

is shown in Fig. 42. The propagation leads to the con-

straint “publicIsFiltered” in Fig. 43. A check of this new

constraint against the model MS,B,M in Fig. 37 shows

that the constraint is fulfilled, which can be interpreted

as consistency with respect to the security requirement

for IT models.

4.5 Summary of Achievements for Inter-Model

Techniques

The described and illustrated techniques for model

transformation, integration and constraint propagation

in this section improve the interoperability between the

business and the IT service models given by ABT-Reo

diagrams. The techniques are general, such that they

should be applicable to the other visual languages and

coordinates in the model framework for enterprise mod-

elling in Fig. 5 as well. The benefits of the techniques can

be described as follows. Model transformation enables

the construction of model stubs that can be refined by

the experts for the specific domain. Model integration es-

tablishes the correspondences between the existing mod-

els e.g. for data interchange and furthermore, conflicts

between models can be detected and highlighted. Ac-

cording to Theorems 4 and 5 model transformation and

model integration based on triple graph grammars are

correct and complete. Finally, propagation of graph con-

straints supports the analysis of models with respect to

non-functional requirements that can be relevant for dif-

ferent domains in the model framework.

5 Related Work

The related work covers three parts. The first part ad-

dresses requirements about enterprise modelling and en-

terprise models as they can be found in numerous pub-

lications and studies. These requirements are put in re-

lation to the work presented in this paper. The second

part focusses on transformation techniques that are used

in today’s industrial environments. They are compared

with the technique of algebraic graph transformation in

part three that is used in the context of this study.

5.1 Enterprise Modeling and Enterprise Models

5.1.1 Paradigms, Frameworks, Architectures There are

a wide variety [34] of paradigms, frameworks and archi-

tectures for enterprise modelling [35,36] available. We

focus here explicitly on the requirements that emerged

in existing approaches and that are relevant for the po-

tential solution.

Enterprise engineering or modelling as it is discussed

in the literature takes two points of view. The first is

about building organizational models [35]. The second

is about IT models that lead to an IT architecture and

implementation to automate business processes [37]. Be-

cause of the scope of this paper we will focus explicitly

on requirements for organizational models that abstracts

away IT implementation details. We believe that this

will reduce the overall complexity and avoid the burden

of building and maintaining fat models [38]. The reason

for such problems is often an insufficient knowledge in

the field about available types of models and potential

modelling techniques [39]. The types or models required

to handle organizational phenomena need to be expres-

sive enough to describe the static and dynamic aspects

of an organization. They need to be open for extensions

as well as being formal to enable fully automated ver-

ification and validation [40]. Even so enterprise models

are created as descriptive models they should support

organizational control and automation by tools later on

which implies that an organizational model will config-

ure an IT platform running business processes [40]. How-

ever, it should not cover IT implementation aspects [40].

Our new model framework has a good potential to

address these requirements. The modelling framework

organizes the interplay of lean and simple models that

can be integrated towards an holistic view. The sound in-

tegration of human-centric and machine-centric models

supports current modelling workflows in the decentral-

ized organization of Credit Suisse and enables model-

checking capabilities. By putting the focus on services,

processes and rules such an organizational model can

serve as a configuration for service oriented IT architec-

tures. It is further able to capture the understanding of

the domain which is already in use.

5.1.2 Enterprise Modelling aspects The purpose of en-

terprise modelling is to understand [41], develop [42],

manage, optimize [42] and control [43] an organization.

From a social point of view, we can assume that or-

ganizational knowledge is usually distributed and that

the people who carry organizational knowledge are lim-

ited by their bounded rationality [44]. Therefore, build-

ing small and focussed models that can be locally inte-

grated should be given preference over creating big and

extensive models that are integrated by a global meta-

model [44]. Because people are considered to be the cru-

cial source of organizational knowledge their conceptual

understanding needs to be smoothly combined with for-

Enterprise Modelling using Algebraic Graph Transformation - Extended Version 27

mal methods regarding the models, the modelling pro-

cess and modelling techniques [45]. Formal methods used

in this context need to support decentralized organiza-

tional workflows and agile modelling as well as collabo-

rative modelling [46].

From a domain point of view, enterprise models are

class and instance models because they need to represent

the organizational situation as it is [47].

From a technical point of view, domain specific mod-

elling environments are needed that extend the facility

of available meta-CASE tools by giving priority to model

transformation and integration. Such environments must

support the evolution of domain languages as well as

their artefacts [48].

Finally, because modelling causes significant costs

[49] reuse of models, modelling elements and modelling

procedures is required [50]. So, a catalogue of modelling

elements and modelling procedures can help here [51].

Such a catalogue will contain objects that are recon-

structed given environmental realities and objects that

are normatively developed based on available organiza-

tional theories. Quality assurance of catalogue elements

is assumed to be highly effective when reuse scales up

[52].

Our new model framework has the potential to cover

these requirements. Lean and focussed models allow on

one hand decentralized and agile modelling, but on the

other hand there are also integration techniques to take

care of a holistic view. Instance- and class modelling

is possible likewise. The declarative nature of algebraic

graph transformation makes the formalism highly us-

able. Negative application conditions and graph con-

straints allow to control the modelling process. Diagram-

like models and text-like models can be handled homo-

geneously by using their abstract syntax. The interplay

of human- and machine-centric models joins flexibility

requirements during the modelling process with formal

requirements during model evaluation. By using catalogs

of model elements and assemblies a lego-like modelling

system could be provided. The same applies to transfor-

mation rules or sets of transformation rules. Algebraic

graph transformation shows good potential to help to

address all this in a formal way which will support also

automation and quality assurance.

5.1.3 Alignment aspects As already stated in section

2.4 and in [13] and [14] alignment aspects between busi-

ness and the IT models are of high importance. The

presented approach shows potential to support such a

flexible alignment in a (semi)- automated fashion, top-

down as well as bottom-up, by the help of intra-model

integration techniques.

5.1.4 Adaptive Modelling Adaptive modelling [53], [54]

shows up when domain languages and their artefacts

evolve [55]. This happens because domain knowledge is

usually given in an implicit way and can be made explicit

only during the modelling process itself. Another rea-

son why this happens is because the environment that is

modelled changes [56]. Here, new kinds of requirements

may require a change of domain languages as well as

their already existing artefacts [57]. Adaptive modelling

can be supported by techniques of algebraic graph trans-

formation, because the rule based approach allows to

handle modifications and adaptions in an easy way.

5.1.5 Simulation and Analysis aspects As pointed out

in [58] and [59] it should be possible to simulate all kinds

of enterprise models. Simulation models for enterprise

planning purposes can be derived by using model trans-

formation rules. In addition to that, the tool environ-

ment AGG [60] can be used for analysis and simulation

of graph grammars.

5.2 Model Transformation techniques

A taxonomy of model transformation techniques is pre-

sented in [61] and it can be used to help developers decid-

ing which model transformation approach is best suited

to deal with a particular problem. By definition a trans-

formation is the automatic generation of a target model

from a source model, according to a transformation def-

inition, that describes how a model or a set of models

in the source language can be transformed into a model

or a set of models in the target language. Transforma-

tions can be endogenous or exogenous. The first case

is about transformations of models that share the same

language. The second case is about transformations of

models that are build on different languages. Further

on, a transformation can be horizontal or vertical. A

horizontal transformation is a transformation where the

source and target model is at the same abstraction level.

A vertical transformation has source and target models

at different abstraction levels.

Model transformations are based on a concept of

models, where one area of models is the model-driven

architecture initiative created by the Object Manage-

ment Group [62]. Here, platform-specific models are

generated from platform independent models. The ex-

isting model-to-model transformation approaches can

be differentiated into direct manipulation approaches,

relational approaches, graph-transformation-based ap-

proaches, structure-driven approaches and hybrid ap-

proaches. The direct manipulation is the most low-

level approach. It offers little or no support or guid-

ance in implementing transformations. The relational

approach seem to strike a well balance between flex-

ibility and declarative expressions. They provide flex-

ible scheduling and good control of non-determinism.

Some of the QVT [63] submissions fit into this category.

The graph-transformation-based approaches are power-

ful and declarative, but sometimes also complex. The

28 Christoph Brandt et al.

complexity stems from the non-determinism in schedul-

ing and application strategy, which requires careful con-

sideration of termination of the transformation process

and the rule application ordering (including the prop-

erty of confluence). There is a large amount of theoretical

work and good experience with research prototypes. The

structure-driven approach groups pragmatic approaches

that were developed in the context of certain kinds of ap-

plications and the hybrid approach allows the user to mix

and match different concepts and paradigms depending

on the application [64].

5.3 Graph Transformation Approaches

Graph transformation has a long tradition [1], a well-

founded theory [2,5] and has been widely used for ex-

pressing model transformations [7,27,30,31,32,33]. Es-

pecially transformations of visual models can be natu-

rally formulated by graph transformations, since graphs

are well suited to describe the underlying structures of

models [65].

By comparing graph transformation approaches and

QVT we see that in all approaches considered, the typ-

ing information is given by an attributed type graph

or meta-model which contains the structural informa-

tion, inheritance concepts and multiplicity constraints.

AToM3 allows constraints to be expressed in Phython,

algebraic graph transformation shows up with graph

constraints, in QVT typing information is provided from

the source and target meta-models for model transfor-

mation. In the standard graph transformation approach

[5], the type graph of the model transformation con-

sists of the source type graph, the target type graph

and additional reference nodes and edges needed dur-

ing the model transformation. In the triple graph gram-

mar approach proposed in [7,27,30,31,32,33] source

and target graphs are connected by a correspondence

graph and triple rules can generate automatically for-

ward and backward model transformation rules. Fur-

thermore, there are general results that ensure correct-

ness and completeness of model transformations [31]. We

can notice that the graph transformation approaches and

QVT share a number of commonalities. The typing con-

cepts by type graphs or the almost equivalent concept

of meta-models can be found in all approaches. More-

over, all transformation approaches considered are rule-

based, even QVT with its concept of relations between

domain models is very close. While the simple rule-based

approach is unidirectional, triple graph grammars and

QVT relations focus more on bidirectional or even multi-

dimensional transformations. All approaches follow an

idea of pre- and post-conditions expressed by some pat-

terns, equipped with typical actions changing the mod-

els. Main differences can be found in the description of

additional attributes using Java, Python, ASM or OCL

as languages for attribute computations as well as con-

ditions. Moreover, the control of rule applications ranges

from pure rule-based approaches allowing a high degree

of non-determinism, to rather controlled rule applica-

tions using mainly automata-based descriptions [65].

Compared with alternative solutions the technique

of algebraic graph transformation is build on a body of

theory that allows formal proofs and that can therefore

guarantee qualities of model transformation and model

integration results [30,31,32,33]. It is able to check con-

straints about models. It is able to demonstrate how con-

straints can be propagated by the help of triple graph

rules to check for inconsistencies with constraints of

models of different type.

6 Conclusion: Summary and Future Work

The integration of business and IT models on one hand

and human-centric and machine-centric models on the

other hand are major challenges in enterprise modelling.

In addition to that there are several further requirements

depending on the enterprise domain and also specific to

the needs of the enterprise. In this paper, we have pro-

posed a new enterprise modelling framework based on al-

gebraic graph transformation techniques that is focussed

on the requirements of Credit Suisse with the purpose to

improve today’s enterprise models and the interoperabil-

ity between them. Furthermore, we presented suitable

techniques that support the development and analysis

of the models with respect to security, risk and compli-

ance, which are major needs for Credit Suisse. There is

a substantial potential that the results can be applied to

enterprises with similar needs as well.

The first main contribution of this paper is the pro-

posal of a new model framework with decentralized mod-

els in three different dimensions including intra- and

inter-modelling techniques in order to support interoper-

ability between them. Moreover, we have discussed how

the requirements for modeling and interoperability in

this framework can be supported in general by algebraic

graph transformation techniques and tools

The second main contribution of this paper is the ag-

gregation of suitable formal techniques for model devel-

opment, analysis, transformation, integration and prop-

agation of requirements. We illustrated their application

on formalised business and IT service models which are

situated in the machine centric modelling dimension of

the model framework. They shall be aligned with human

centric domain languages as explained in Sec. 2.

In order to support flexible modelling in visual no-

tation we introduced the notion of a construction and a

correction grammar (C&C system). This way the edit-

ing steps of a model development environment can be

equipped with the corresponding construction rules that

realise the formal construction of the abstract syntax

graphs. The correction of models with respect to the

well-formedness rules of the language is performed on the

basis of the correction grammar. This grammar enables

Enterprise Modelling using Algebraic Graph Transformation - Extended Version 29

an automated detection and highlighting of the patterns

that violate the well-formedness rules. We further ex-

plained how the soundness of the C&C system with re-

spect to the set of well-formed models of the modelling

language can be analysed using the results for local con-

fluence and termination according to Theorems 1 and 2,

which are central results of algebraic graph transforma-

tion systems.

Moreover, we have shown how a substantial part of

the functional and non-functional requirements in the

domain of the enterprise can be formalized in an in-

tuitive but formal way by graph constraints in order

to perform automated checks of the models against the

requirements. The validity of graph constraints can be

preserved during the development of models if certain

conditions for the underlying transformation steps are

fulfilled, as stated by Thm. 3.

As third main contribution of this paper, we have

shown how interoperability between models of different

dimensions of the framework can be achieved in order to

support the development process of the models and to

improve maintainability and the possibilities for analy-

sis. For this purpose we have presented how model trans-

formation and model integration are used to construct

and integrate models in order to relate their compo-

nents and to detect inconsistencies between them. Both

techniques are based on triple graph grammars, where

patterns describe how essential model fragments of the

source and target model shall be related. The techniques

can be applied in an automated way and they are shown

to be correct and complete according to Theorems 4 and

Moreover, we have illustrated how the requirements

specified by graph constraints for one domain can be

propagated to other models in the enterprise framework

in order to support consistency of related models.

Altogether, this paper should be considered as a pro-

posal for a new enterprise model at Credit Suisse and

similar decentralized organizations. In fact, in addition

to the general ideas, we have only shown first steps of

how to realize this enterprise model using formal meth-

ods and tools in the area of algebraic graph transforma-

tions. We mainly have focussed on modelling and inter-

operability of business and IT service models using ABT-

Reo diagrams. It remains for future work to extend this

to human-centric models based on other formal specifi-

cation techniques. Moreover, it remains to show semanti-

cal compatibility and to develop techniques for the over-

all integration of all decentralized models. Last but not

least, it is a key challenge to implement the new enter-

prise model at Credit Suisse.

References

1. Ehrig, H., Pfender, M., Schneider, H.J.: Graph-

grammars: An algebraic approach. In: 14th Annual

Symposium on Switching and Automata Theory, IEEE

(1973) 167–180

2. Rozenberg, G., ed.: Handbook of Graph Grammars and

Computing by Graph Transformations, Volume 1: Foun-

dations. World Scientific Publishing Co., Inc. (1997)

3. Ehrig, H., Engels, G., Kreowski, H.J., Rozenberg, G.,

eds.: Handbook of Graph Grammars and Computing

by Graph Transformation, Volume 2: Applications, Lan-

guages and Tools. World Scientific Publishing Co., Inc.

(1999)

4. Ehrig, H., Kreowski, H.J., Montanari, U., Rozenberg, G.,

eds.: Handbook of Graph Grammars and Computing by

Graph Transformation: Volume 3: Concurrency, Paral-

lelism, and Distribution. World Scientific Publishing Co.,

Inc. (1999)

5. Ehrig, H., Ehrig, K., Prange, U., Taentzer, G.: Fun-

damentals of Algebraic Graph Transformation. EATCS

Monographs in Theor. Comp. Science. Springer (2006)

6. Brandt, C., Hermann, F., Ehrig, H., Engel, T., Adamek,

J., Sch¨olzel, H.: Security and Consistency of IT and

Business Models at Credit Suisse realized by Graph Con-

straints, Transformation and Integration using Algebraic

Graph Theory (Long Version). Technical report, Tech-

nische Universit¨at Berlin,Fakult¨at IV (to appear 2010)

draft version available: http://tfs.cs.tu-berlin.

de/publikationen/Papers10/BHE+10.pdf.

7. Kindler, E., Wagner, R.: Triple Graph Grammars:

Concepts, Extensions, Implementations, and Application

Scenarios. Technical Report TR-ri-07-284, Universit¨at

Paderborn (2007)

8. Object Management Group: Unified Modeling Language:

Superstructure – Version 2.1.1. (2007) formal/07-02-05,

http://www.omg.org/technology/documents/

formal/uml.htm.

9. Object Management Group: Catalog Of OMG

Business Strategy, Business Rules And Busi-

ness Process Management Specifications. (2009)

http://www.omg.org/technology/documents/

br_pm_spec_catalog.htm.

10. Groote, J.F., Mathijssen, A., Reniers, M., Usenko, Y.,

van Weerdenburg, M.: The formal specification lan-

guage mcrl2. In Brinksma, E., Harel, D., Mader,

A., Stevens, P., Wieringa, R., eds.: Methods for Mod-

elling Software Systems (MMOSS). Number 06351 in

Dagstuhl Seminar Proceedings, Dagstuhl, Germany, In-

ternationales Begegnungs- und Forschungszentrum f¨ur

Informatik (IBFI), Schloss Dagstuhl, Germany (2007)

11. Arbab, F.: Abstract Behavior Types: A Foundation

Model for Components and Their Composition. Science

of Computer Programming 55 (2005) 3–52

12. Brandt, C., Hermann, F., Engel, T.: Modeling and Re-

configuration of critical Business Processes for the pur-

pose of a Business Continuity Management respecting

Security, Risk and Compliance requirements at Credit

Suisse using Algebraic Graph Transformation. In: Proc.

Int. Workshop on Dynamic and Declarative Business

Processes (DDBP 2009), IEEE Xplore Digital Library

(2009) (accepted).

13. Zhang, L.J., Zhang, J., Cai, H.: Enterprise Modeling. In:

Services Computing, Springer (2007) 259–274

14. Wegmann, A., Lˆe, L.S., Regev, G., Wood, B.: Enterprise

modeling using the foundation concepts of the rm-odp

30 Christoph Brandt et al.

iso/itu standard. Inf. Syst. E-Business Management 5(4)

(2007) 397–413

15. Pemmaraju, S., Skiena, S.: Computational Discrete

Mathematics: Combinatorics and Graph Theory with

Mathematica. Cambridge University Press, New York

(2003) The University of Iowa and SUNY at Stony

Brook.

16. Brewer, D.F.C., Nash, M.J.: The Chinese Wall Security

Policy. In: IEEE Symposium on Security and Privacy.

(1989) 206–214

17. Kl¨uppelholz, S., Baier, C.: Symbolic model check-

ing for channel-based component connectors. In: Proc.

Int. Workshop on the Foundations of Coordination

Languages and Software Architectures (FOCLASA’06).

(2006)

18. Arbab, F.: Reo: a channel-based coordination model

for component composition. Mathematical Structures in

Computer Science 14(3) (2004) 329–366

19. Wirsing, M., Pattinson, D., Hennicker, R., eds.: Re-

cent Trends in Algebraic Development Techniques, 16th

International Workshop, WADT 2002, Frauenchiemsee,

Germany, September 24-27, 2002, Revised Selected Pa-

pers. In Wirsing, M., Pattinson, D., Hennicker, R., eds.:

WADT. Volume 2755 of LNCS., Springer (2003)

20. Scheer, A.W.: ARIS-Modellierungs-Methoden, Meta-

modelle, Anwendungen. Springer, Berlin/Heidelberg

(2001)

21. Boehmer, W., Brandt, C., Groote, J.: Evaluation of a

business continuity plan using process algebra and modal

logic. IEEE TIC Toronto (2009)

22. Reisig, W.: Petri Nets: An Introduction. Volume 4

of Monographs in Theoretical Computer Science. An

EATCS Series. Springer (1985)

23. van der Aalst, W.M.P., ter Hofstede, A.H.M., Kie-

puszewski, B., Barros, A.P.: Workflow Patterns. Dis-

tributed and Parallel Databases 14(1) (2003) 5–51

24. Rensink, A.: Representing First-Order Logic Using

Graphs. In Ehrig, H., Engels, G., Parisi-Presicce, F.,

Rozenberg, G., eds.: Proc. Int. Conference on Graph

Transformation (ICGT’04). Volume 3256 of LNCS.,

Springer (2004) 319–335

25. Jurack, S., Lambers, L., Mehner, K., Taentzer, G.,

Wierse, G.: Object Flow Definition for Refined Ac-

tivity Diagrams . In Chechik, M., Wirsing, M., eds.:

Proc. Fundamental Approaches to Software Engineering

(FASE’09). Volume 5503 of LNCS., Springer (2009) 49–

26. Brandt, C., Hermann, F., Engel, T.: Security and Con-

sistency of IT and Business Models at Credit Suisse re-

alized by Graph Constraints, Transformation and Inte-

gration using Algebraic Graph Theory. In: Proc. Int.

Conference on Exploring Modeling Methods in Systems

Analysis and Design 2009 (EMMSAD’09). Volume 29 of

LNBIP., Heidelberg, Springer Verlag (2009) 339–352

27. Sch¨urr, A.: Specification of Graph Translators with

Triple Graph Grammars. In Tinhofer, G., ed.: Proc.

Int. Workshop on Graph-Theoretic Concepts in Com-

puter Science (WG’94). Volume 903 of LNCS., Springer

(1994) 151–163

28. Ermel, C., Biermann, E., Ehrig, K., Taentzer, G.: Gen-

erating Eclipse Editor Plug-Ins using Tiger. In Sch¨urr,

A., Nagl, M., Z¨undorf, A., eds.: Proc. Int. Symposium

on Applications of Graph Transformation with Indus-

trial Relevance (AGTIVE’07). Volume 5088 of LNCS.,

Heidelberg, Springer (2008) 583–585

29. Object Management Group: Meta-Object Facility

(MOF), Version 2.0. (2006)

30. Ehrig, H., Ehrig, K., Hermann, F.: From Model Trans-

formation to Model Integration based on the Algebraic

Approach to Triple Graph Grammars. In Ermel, C.,

de Lara, J., Heckel, R., eds.: Proc. Workshop on Graph

Transformation and Visual Modeling Techniques (GT-

VMT’08). Volume 10., EC-EASST (2008)

31. Ehrig, H., Ermel, C., Hermann, F., Prange, U.: On-

the-Fly Construction, Correctness and Completeness of

Model Transformationsbased on Triple Graph Gram-

mars. In Sch¨urr, A., Selic, B., eds.: ACM/IEEE 12th

International Conference on Model Driven Engineering

Languages and Systems (MODELS’09). Volume 5795 of

LNCS., Springer (2009) 241–255 To appear.

32. Ehrig, H., Ehrig, K., Ermel, C., Hermann, F., Taentzer,

G.: Information preserving bidirectional model transfor-

mations. In Dwyer, M.B., Lopes, A., eds.: Fundamen-

tal Approaches to Software Engineering. Volume 4422 of

LNCS., Springer (2007) 72–86

33. Ehrig, H., Hermann, F., Sartorius, C.: Completeness and

Correctness of Model Transformations based on Triple

Graph Grammars with Negative Application Conditions.

In Heckel, R., Boronat, A., eds.: Proc. Workshop on

Graph Transformation and Visual Modeling Techniques

(GT-VMT’09), EC-EASST (2009)

34. Giaglis, G.M.: A Taxonomy of Business Process Model-

ing and Information Systems Modeling Techniques. In-

ternational Journal of Flexible Manufacturing Systems

13(2) (2001) 209–228

35. Sousa, G., Van Aken, E., Rentes, A.: Using enterprise

modeling to facilitate knowledge management in organi-

zational transformation efforts. Portland International

Conference on Management of Engineering and Technol-

ogy. IEEE. 1(2001) 62

36. Lillehagen, F., Krogstie, J.: State of the Art of Enterprise

Modeling. In: Active Knowledge Modeling of Enterprises,

Springer (2008) 91–127

37. Lankhorst, M.: Enterprise Architecture at Work. Mod-

elling, Communication and Analysis. Springer (2005)

38. Pereira, C.M., Sousa, P.: A method to define an En-

terprise Architecture using the Zachman Framework.

In: Proc. ACM symposium on Applied Computing

(SAC’04), New York, NY, USA, ACM (2004) 1366–1371

39. Camarinha-Matos, L.M., Afsarmanesh, H., Ollus, M.,

eds.: Virtual Organizations. Springer (2005)

40. Popova, V., Sharpanskykh, A.: A Formal Framework

for Modeling and Analysis of Organizations. In Ra-

lyt´e, J., Brinkkemper, S., Henderson-Sellers, B., eds.:

Situational Method Engineering. Volume 244 of IFIP.,

Springer (2007) 343–358

41. Delen, D., Dalal, N.P., Benjamin, P.C.: Integrated mod-

eling: the key to holistic understanding of the enterprise.

Commun. ACM 48(4) (2005) 107–112

42. Dalal, N.P., Kamath, M., Kolarik, W.J., Sivaraman, E.:

Toward an integrated framework for modeling enterprise

processes. Commun. ACM 47(3) (2004) 83–87

43. Delen, D., Pratt, D., Kamath, M.: A new paradigm

for manufacturing enterprise modeling: reusable, multi-

Enterprise Modelling using Algebraic Graph Transformation - Extended Version 31

tool modeling. Proc. IEEE Simulation Conference (1996)

985–992

44. Kateel, G., Kamath, M., Pratt, D.: An overview of CIM

enterprise modeling methodologies. Proc. IEEE Simula-

tion Conference (1996) 1000–1007

45. Hoogervorst, J.A.: Enterprise Governance and Enter-

prise Engineering. Springer (2009)

46. Zhiming, C., Jun, Y.: The Process Conducting and Mem-

ber Audit in the Distributed Enterprise Modeling. IEEE

Asia-Pacific Services Computing Conference (2008) 416–

420

47. Agarwal, R., Bruno, G., Torchiano, M.: Enterprise mod-

eling using class and instance models. Seventh Asia-

Pacific Software Engineering Conference. IEEE. (2000)

336–343

48. Englebert, V., Heymans, P.: Towards More Extensible

MetaCASE Tools. [66] 454–468

49. Work, B., Balmforth, A.: Using abstractions to

build standardized components for enterprise models.

Proc. IEEE Software Engineering Standards Symposium

(1993) 154–162

50. Sarder, M., Ferreira, S., Rogers, J., Liles, D.: A Method-

ology for Design Ontology Modeling. Portland Interna-

tional Center for Management of Engineering and Tech-

nology. IEEE. (2007) 1011–1018

51. Malone, T., Crowston, K., Lee, J., Pentland, B.: Tools for

inventing organizations: toward a handbook of organiza-

tional processes. Second Workshop on Enabling Tech-

nologies: Infrastructure for Collaborative Enterprises.

IEEE. (1993) 72–82

52. Fernandes, J.M., Duarte, F.J.: A reference framework

for process-oriented software development organizations.

Software and System Modeling 4(1) (2005) 94–105

53. Himsl, M., Jabornig, D., Leithner, W., Regner, P.,

Wiesinger, T., K¨ung, J., Draheim, D.: An Iterative Pro-

cess for Adaptive Meta- and Instance Modeling. In Wag-

ner, R., Revell, N., Pernul, G., eds.: DEXA. Volume 4653

of LNCS., Springer (2007) 519–528

54. Whitman, L., Ramachandran, K., Ketkar, V.: A taxon-

omy of a living model of the enterprise. In: Proc. Confer-

ence on Winter Simulation (WSC’01), Washington, DC,

USA, IEEE Computer Society (2001) 848–855

55. Valentin, E.C., Verbraeck, A.: Domain specific model

constructs in commercial simulation environments. In:

Proc. Conference on Winter Simulation (WSC’07), year

= 2007, isbn = 1-4244-1306-0, pages = 785–795, location

= Washington D.C., publisher = IEEE Press, address =

Piscataway, NJ, USA,

56. Mertins, K., Jochem, R.: Integrated enterprise modeling:

method and tool. SIGGROUP Bull. 18(2) (1997) 63–66

57. Han, Y., Tai, S., Wikarski, D., eds. In Han, Y., Tai,

S., Wikarski, D., eds.: Engineering and Deployment of

Cooperative Information Systems (EDCIS’02). Volume

2480 of LNCS., Springer (2002)

58. Sadowski, D., Bapat, V.: The arena product family:

enterprise modeling solutions. In: Proc. Conference on

Winter Simulation (WSC’99), ACM (1999) 159–166

59. Kubota, F., Sato, S., Nakano, M.: Enterprise modeling

and simulation platform integrating manufacturing sys-

tem design and supply chain. IEEE International Con-

ference on Systems, Man, and Cybernetics 4(1999) 511–

515

60. TFS-Group, TU Berlin: AGG. (2009) http://tfs.cs.

tu-berlin.de/agg.

61. Mens, T., Czarnecki, K., Gorp, P.V.: 04101 Discus-

sion – A Taxonomy of Model Transformations. In

Bezivin, J., Heckel, R., eds.: Language Engineering for

Model-Driven Software Development. Number 04101 in

Dagstuhl Seminar Proceedings, Dagstuhl, Germany, In-

ternationales Begegnungs- und Forschungszentrum f¨ur

Informatik (IBFI), Schloss Dagstuhl, Germany (2005)

62. : MDA Specifications. http://www.omg.org/mda/

specs.htm (2009)

63. Object Management Group: Meta Object

Facility (MOF) 2.0 Query/View/Transforma-

tion Specification. Version 1.0 formal/08-04-03.

http://www.omg.org/spec/QVT/1.0/. (2008)

64. Czarnecki, K., Helsen, S.: Classification of Model Trans-

formation Approaches. In: OOPSLA’03 Workshop on

Generative Techniques in the Context of Model-Driven

Architecture. (2003)

65. Taentzer, G., Ehrig, K., Guerra, E., de Lara, J., Lengyel,

L., Levendovszky, T., Prange, U., Varr´o, D., , Varr´o-

Gyapay, S.: Model Transformation by Graph Trans-

formation: A Comparative Study. In: ACM/IEEE 8th

International Conference on Model Driven Engineering

Languages and Systems, Montego Bay, Jamaica (Octo-

ber 2005)

66. Krogstie, J., Opdahl, A.L., Sindre, G., eds. In Krogstie,

J., Opdahl, A.L., Sindre, G., eds.: Proc. Conference on

Advanced Information Systems Engineering (CAiSE’07).

Volume 4495 of LNCS., Springer (2007)