scieee Science in your language
[en] (orig)
Managing Dependency Relations in
Inter-Organizational Models
Lianne Bodenstaff
Ph.D. dissertation committee
Chairman and secretary
Prof. dr. ir. A.J. Mouthaan University of Twente, the Netherlands
Promotor
Prof. dr. R.J. Wieringa University of Twente, the Netherlands
Co-promotor
Prof. dr. M.U. Reichert University of Ulm, Germany
Members
Prof. dr. ir. M. Aksit University of Twente, the Netherlands
Prof. dr. P.M.G. Apers University of Twente, the Netherlands
Prof. dr. E. Damiani University of Milan, Italy
Prof. dr. J. Gordijn VU University Amsterdam, the Netherlands
Dr. H. Ludwig IBM TJ Watson Research Center, USA
Prof. dr. S. Rinderle-Ma Universit¨
at Wien, Austria
CTIT Ph.D. Thesis Series No. 10-167
Centre for Telematics and Information Technology
P.O. Box 217, 7500 AE
Enschede, The Netherlands
SIKS Dissertation Series No. 2010-15
The research reported in this thesis has been carried out
under the auspices of SIKS, the Dutch Research School
for Information and Knowledge Systems.
This research was financially supported by the Nether-
lands Organisation for Scientific Research (NWO) under
contract number 612.063.409.
Printed and bound by Ipskamp Drukkers B.V.
Cover image from http://dreamstime.com (photographer: Nadya Pyastolova)
ISBN: 978-90-365-2996-9
ISSN: 1381-3617 (CTIT Ph.D. thesis Series No. 10-167)
http://dx.doi.org/10.3990/1.9789036529969
Copyright c
2010, Lianne Bodenstaff
All rights reserved. No part of this book may be reproduced or transmitted in any form or
by any means, electronic or mechanical, including photography, recording, or any infor-
mation storage and retrieval system, without prior written permission of the author.
MANAGING DEPENDENCY RELATIONS
IN INTER-ORGANIZATIONAL MODELS
DISSERTATION
to obtain
the doctor’s degree at the University of Twente,
on the authority of the rector magnificus,
prof. dr. H. Brinksma,
on account of the decision of the graduation committee,
to be publicly defended
on Thursday, 17 June 2010, at 16.45
by
Lianne Bodenstaff
born on June 4, 1977
in Assen, The Netherlands
This dissertation has been approved by:
Prof. dr. R.J. Wieringa (promotor)
Prof. dr. M.U. Reichert (co-promotor)
ABSTRACT
In various fields like software development, information systems development, and e-
business development, model-based approaches allow specifying different models of which
each emphasizes one specific aspect or part of the software system. In this thesis we con-
sider particularly model-based approaches for defining inter-organizational cooperations.
These cooperations are usually complex in terms of coordination, agreements, and value
creation for involved partners.
At design time one should ensure that the different models are consistent with each
other, i.e., that they describe the same system. At runtime we additionally have to deal
with the fact that behavior of the software system might be different from that agreed
upon. Such deviant behavior can, for example, be caused by partners in the cooperation
that do not behave according to the agreement. Therefore, the challenges are to ensure
consistency at design time as well as to monitor the system at runtime in order to detect
inconsistencies with the models it relies on.
When managing complex cooperations, it is also vital to maintain the models describ-
ing them to keep an overview on the successfulness of the cooperation. Changing one
model to regain consistency with the running system might result in new inconsistencies
between the different models. As a consequence, this maintenance phase of the models is
time consuming and grows in complexity with increasing number of models describing
the system.
This thesis proposes a method that supports ensuring and maintaining consistency
between running system and underlying models for inter-organizational cooperations. We
provide a structured and model-independent approach to check and maintain consistency.
Thereby, we focus on identifying and maintaining these inter-model relations.
We validate our method by conducting two case studies in two different fields of re-
search. The first scenario deals with business and coordination models, while the sec-
ond one addresses Web service compositions. Furthermore, we provide a prototypical
implementation as proof-of-concept evaluation of both scenarios. We conclude with an
empirical validation of the Web service composition scenario by an extensive and interac-
tive survey conducted among 34 participants. This survey confirms the suitability of our
proposed management solution provided for real life use.
ACKNOWLEDGEMENTS
CONTENTS
List of figures xi
List of tables xv
I Introduction & Motivation 1
1 Introduction 3
1.1 Motivation.................................. 3
1.2 Problemstatement ............................. 4
1.3 Researchdesign............................... 7
1.4 Contribution................................. 7
1.5 Outline ................................... 9
II Solution 11
2 Conceptual frame 13
2.1 Scope .................................... 13
2.2 Consistency................................. 14
2.3 Categorization for models and consistency . . . . . . . . . . . . . . . . . 16
2.3.1 Typeofmodels........................... 16
2.3.2 Type of consistency . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.3 Ensuring consistency . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Orthogonal categorization for models and consistency . . . . . . . . . . . 17
2.5 Summary .................................. 18
3 Problem investigation & related work 19
3.1 Modelheterogeneity ............................ 19
3.1.1 Syntactic heterogeneity . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.2 Semantic heterogeneity . . . . . . . . . . . . . . . . . . . . . . . 21
CONTENTS
3.1.3 Pragmatic heterogeneity . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Alignment with the running system . . . . . . . . . . . . . . . . . . . . . 25
3.3 Maintainingmodels............................. 26
3.4 Solutionrequirements............................ 26
3.5 State-of-the-art research . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.1 Discussion on related work and solution requirements . . . . . . 34
3.6 Summary .................................. 36
4 MaDe4IC: An abstract method for managing model dependencies in inter-
organizational cooperations 37
4.1 Generalapproach.............................. 37
4.1.1 Model characteristics . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.2 Themethod............................. 38
4.2 Runningexample .............................. 40
4.3 Phase I: Model analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.1 Step 1: Model analysis . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.2 Step 2: Homogenization . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Phase II: Inter-model analysis . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.1 Step 3: Inter-model relation detection . . . . . . . . . . . . . . . 46
4.4.2 Step 4: Inter-model consistency constraints . . . . . . . . . . . . 50
4.5 Phase III: Intra-model analysis . . . . . . . . . . . . . . . . . . . . . . . 55
4.5.1 Step 5: Intra-model relation detection . . . . . . . . . . . . . . . 55
4.5.2 Step 6: Intra-model consistency constraints . . . . . . . . . . . . 55
4.6 Phase IV: Combined analysis . . . . . . . . . . . . . . . . . . . . . . . . 58
4.6.1 Step 7: Dependency analysis . . . . . . . . . . . . . . . . . . . . 58
4.7 Phase V: Management phase . . . . . . . . . . . . . . . . . . . . . . . . 61
4.7.1 Step 8: Log analysis . . . . . . . . . . . . . . . . . . . . . . . . 61
4.7.2 Step 9: Causal analysis . . . . . . . . . . . . . . . . . . . . . . . 63
4.8 Summary .................................. 66
III Scenario 1: Business & Coordination Models 69
5 Managing dependency relations: Business and coordination models 71
5.1 Basics.................................... 72
5.1.1 Business perspective . . . . . . . . . . . . . . . . . . . . . . . . 72
5.1.2 Process perspective . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.1.3 Eventlogs.............................. 73
5.2 Step1:Modelanalysis ........................... 75
5.3 Step 2: Homogenization . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.4 Step 3: Inter-model relation detection . . . . . . . . . . . . . . . . . . . 77
5.5 Step 4: Inter-model consistency constraints . . . . . . . . . . . . . . . . 79
5.5.1 Transferlevel............................ 79
5.5.2 Business transaction . . . . . . . . . . . . . . . . . . . . . . . . 80
vi
CONTENTS
5.6 Step 5: Intra-model relation detection . . . . . . . . . . . . . . . . . . . 81
5.6.1 Valuemodel ............................ 82
5.6.2 Coordination model . . . . . . . . . . . . . . . . . . . . . . . . 82
5.7 Step 6: Intra-model consistency constraints . . . . . . . . . . . . . . . . 82
5.7.1 Valuemodel ............................ 83
5.7.2 Coordination model . . . . . . . . . . . . . . . . . . . . . . . . 85
5.8 Step 7: Dependency analysis . . . . . . . . . . . . . . . . . . . . . . . . 87
5.8.1 Value model abstraction . . . . . . . . . . . . . . . . . . . . . . 87
5.8.2 Coordination model abstraction . . . . . . . . . . . . . . . . . . 88
5.8.3 Formalization of constraints . . . . . . . . . . . . . . . . . . . . 89
5.9 Step8:Loganalysis............................. 90
5.10 Step 9: Causal analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.10.1 Causes ............................... 92
5.10.2 Changes............................... 93
5.10.3 Causalanalysis........................... 96
5.10.4 Minimize the number of changes: Theorem and proof . . . . . . 97
5.11 Related work on value and coordination models . . . . . . . . . . . . . . 99
5.12Summary ..................................101
6 Proof-of-concept implementation: Business and coordination model 103
6.1 Thebusinesscase..............................103
6.1.1 Valuemodel ............................104
6.1.2 Coordination model . . . . . . . . . . . . . . . . . . . . . . . . 105
6.2 Consistency constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.3 Implementation...............................107
6.3.1 Average value of transfers . . . . . . . . . . . . . . . . . . . . . 108
6.3.2 Average number of transfers . . . . . . . . . . . . . . . . . . . . 108
6.3.3 The equation system . . . . . . . . . . . . . . . . . . . . . . . . 108
6.4 Managing the value model . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.5 Visualization ................................112
6.6 Evaluation of our developed management approach . . . . . . . . . . . . 114
6.7 Summary ..................................114
IV Scenario 2: Service Level Agreements for Composite Services117
7 Managing dependency relations: Service compositions 119
7.1 Basics....................................120
7.1.1 Service Level Agreements . . . . . . . . . . . . . . . . . . . . . 120
7.1.2 Businesscase............................121
7.2 Step 1: Model analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.3 Step 2: Homogenization . . . . . . . . . . . . . . . . . . . . . . . . . . 124
7.4 Step 3: Inter-model relation detection . . . . . . . . . . . . . . . . . . . 125
7.5 Step 4: Inter-model consistency constraints . . . . . . . . . . . . . . . . 129
vii
CONTENTS
7.5.1 Generalization: Impact factors . . . . . . . . . . . . . . . . . . . 130
7.6 Step 5: Intra-model relation detection . . . . . . . . . . . . . . . . . . . 133
7.7 Step 6: Intra-model consistency constraints . . . . . . . . . . . . . . . . 134
7.8 Step 7: Dependency analysis . . . . . . . . . . . . . . . . . . . . . . . . 136
7.8.1 Compositiontree..........................138
7.8.2 Expected impact tree . . . . . . . . . . . . . . . . . . . . . . . . 139
7.9 Step8:Loganalysis.............................146
7.10 Step 9: Causal analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
7.10.1 Realized impact tree . . . . . . . . . . . . . . . . . . . . . . . . 148
7.10.2 Feedbacktree............................150
7.11RelatedworkonSLAs ...........................154
7.11.1 SLAmodels ............................154
7.11.2 Managing Web services . . . . . . . . . . . . . . . . . . . . . . 155
7.11.3 Root Cause analysis . . . . . . . . . . . . . . . . . . . . . . . . 156
7.11.4 Service monitoring approaches . . . . . . . . . . . . . . . . . . . 156
7.11.5 QoS-based service composition . . . . . . . . . . . . . . . . . . 157
7.12Summary ..................................157
8 Proof-of-concept implementation: Service compositions 159
8.1 Examplescenario..............................159
8.2 Implementation...............................160
8.2.1 Contribution factors . . . . . . . . . . . . . . . . . . . . . . . . 162
8.2.2 Service contribution . . . . . . . . . . . . . . . . . . . . . . . . 163
8.2.3 Impactfactors............................164
8.3 Generation and execution . . . . . . . . . . . . . . . . . . . . . . . . . . 164
8.4 Visualization ................................165
8.5 Summary ..................................169
9 Evaluation of MoDe4SLA: Service compositions 171
9.1 Evaluation plan for effectiveness ......................171
9.2 Evaluating usefulness: Setup . . . . . . . . . . . . . . . . . . . . . . . . 174
9.3 Course of evaluating usefulness . . . . . . . . . . . . . . . . . . . . . . . 176
9.4 Conclusions from evaluating usefulness . . . . . . . . . . . . . . . . . . 177
9.4.1 Demographics ...........................177
9.4.2 Statistics ..............................178
9.4.3 Conclusions.............................185
9.5 Summary ..................................186
V Discussion 187
10 Discussion & lessons learnt 189
10.1Methodrequirements............................189
10.2 Cross-scenario discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 192
viii
CONTENTS
10.3 Applying our MaDe4IC method . . . . . . . . . . . . . . . . . . . . . . 193
10.3.1 Step 1: Model analysis . . . . . . . . . . . . . . . . . . . . . . . 193
10.3.2 Step 2: Homogenization . . . . . . . . . . . . . . . . . . . . . . 194
10.3.3 Step 3: Inter-model relation detection . . . . . . . . . . . . . . . 194
10.3.4 Step 4: Inter-model consistency constraints . . . . . . . . . . . . 195
10.3.5 Step 5: Intra-model relation detection . . . . . . . . . . . . . . . 195
10.3.6 Step 6: Intra-model consistency constraints . . . . . . . . . . . . 196
10.3.7 Step 7: Dependency analysis . . . . . . . . . . . . . . . . . . . . 196
10.3.8 Step 8: Log analysis . . . . . . . . . . . . . . . . . . . . . . . . 196
10.3.9 Step 9: Causal analysis . . . . . . . . . . . . . . . . . . . . . . . 197
10.3.10Lessonslearnt............................197
10.4 Validating MoDe4SLA . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
10.5 Answering research questions . . . . . . . . . . . . . . . . . . . . . . . 199
10.6Futureresearch ...............................201
10.6.1 Our MaDe4IC method for managing dependencies . . . . . . . . 201
10.6.2 Our approach for managing SLAs of composite services: MoDe4SLA202
Appendix A Evaluation 205
A.1 Transcript ..................................205
A.2 Hand-out ..................................207
A.3 Surveyresults................................240
Appendix B Related publications by the author 259
Bibliography 261
ix
LIST OF FIGURES
1.1 Researchdesign............................... 8
2.1 Intra-model, inter-model, and runtime consistency relations . . . . . . . . 15
2.2 Multi-model approaches for maintaining consistency . . . . . . . . . . . 18
3.1 Consistency relations between models, event logs, and information systems 20
3.2 Perspectiveandfocus............................ 22
3.3 Coarseningmodels ............................. 23
4.1 MaDe4IC: Method for managing dependency relations in inter-organizational
models.................................... 39
4.2 Running example: Selling bikes . . . . . . . . . . . . . . . . . . . . . . 41
4.3 Dependency relations between viewpoints and partial models . . . . . . . 42
4.4 Example: Asymmetric and symmetric dependency relations . . . . . . . 48
4.5 Possible generalization over symmetric consistency constraints . . . . . . 53
4.6 Possible generalization over asymmetric consistency constraints . . . . . 54
4.7 Possible generalization over intra-model consistency constraints . . . . . 57
4.8 Consequence analysis for changing models . . . . . . . . . . . . . . . . 65
5.1 Example case: Business model (e3-value notation) . . . . . . . . . . . . . 73
5.2 Example case: Coordination model (BPMN notation) . . . . . . . . . . . 74
5.3 Example case: Event log (XML notation) . . . . . . . . . . . . . . . . . 74
5.4 Relations between models and real-life entities . . . . . . . . . . . . . . 78
5.5 Inter-model dependency relations . . . . . . . . . . . . . . . . . . . . . . 78
5.6 Constraints between models and event log . . . . . . . . . . . . . . . . . 81
5.7 Example case: Intra-model dependencies . . . . . . . . . . . . . . . . . 82
5.8 Example case: Intra-model consistency constraints . . . . . . . . . . . . 85
5.9 Sameclassmodels ............................. 94
5.10Observablechanges............................. 94
5.11 Example case: Causal analysis of coordination model . . . . . . . . . . . 97
LIST OF FIGURES
5.12 Relating constraints and changes . . . . . . . . . . . . . . . . . . . . . . 98
6.1 Example case: Business model (e3-value notation) . . . . . . . . . . . . . 105
6.2 Example case: Coordination model (Petri Net notation) . . . . . . . . . . 106
6.3 Example case: Realized and estimated average value of transfers . . . . . 108
6.4 Example case: Realized and estimated average number of transfers . . . . 109
6.5 Example case: Customer ratios and introduced variables (e3-value notation)111
6.6 Proof-of-concept implementation: Graphical user interface . . . . . . . . 112
6.7 Proof-of-concept implementation: Coloring the value model . . . . . . . 114
7.1 Overview: MoDe4SLA approach . . . . . . . . . . . . . . . . . . . . . . 120
7.2 SubscribedNews and NewsRequest: Dependency cost model . . . . . . . 127
7.3 SubscribedNews: Response time dependency model . . . . . . . . . . . . 128
7.4 NewsRequest: Response time dependency model . . . . . . . . . . . . . 128
7.5 SubscribedNews and NewsRequest: Impact trees . . . . . . . . . . . . . 132
7.6 Illustrative service composition . . . . . . . . . . . . . . . . . . . . . . . 137
7.7 Small example: Service composition . . . . . . . . . . . . . . . . . . . . 141
7.8 Mainfigure .................................145
7.9 Illustrative example: Cost feedback tree . . . . . . . . . . . . . . . . . . 154
8.1 Example scenario: Service composition . . . . . . . . . . . . . . . . . . 160
8.2 Example scenario: Agreed upon QoS . . . . . . . . . . . . . . . . . . . . 161
8.3 Example scenario: Estimated impact tree for cost . . . . . . . . . . . . . 162
8.4 Example scenario: Realized QoS . . . . . . . . . . . . . . . . . . . . . . 166
8.5 Monitoring example scenario: Cost feedback tree . . . . . . . . . . . . . 167
8.6 Monitoring example scenario: Response time feedback tree . . . . . . . . 168
9.1 Evaluating effectiveness...........................172
9.2 Evaluating usefulness . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
9.3 The offered composition appears to be complex. . . . . . . . . . . . . . . 178
9.4 Concerning costs: It is easier to determine the impact each service has on
the composition with the analysis than without it. . . . . . . . . . . . . . 179
9.5 MoDe4SLA approach is helpful when managing this composition with
regard to accurately depicting malfunctioning services. . . . . . . . . . . 179
9.6 Concerning costs: It takes less time to see relations between different
services and the composition. . . . . . . . . . . . . . . . . . . . . . . . . 180
9.7 MoDe4SLA approach is helpful when managing this composition with
regard to faster selecting services to renegotiate. . . . . . . . . . . . . . . 181
9.8 After seeing the MoDe4SLA analysis, how is your confidence about the
service selection for renegotiation you made before? . . . . . . . . . . . 181
9.9 Assume only a subset of services can be renegotiated regarding their
SLAs. I would feel confident in selecting services for renegotiation. . . . 182
xii
LIST OF FIGURES
9.10 Assume only a subset of services can be renegotiated regarding their
SLAs. I would feel more confident in selecting services for renegotia-
tion with MoDe4SLA than without. . . . . . . . . . . . . . . . . . . . . 182
9.11 MoDe4SLA is helpful for managing service compositions. . . . . . . . . 183
9.12 The presentation before the evaluation is sufficient to properly understand
MoDe4SLAapproach. ...........................184
xiii
LIST OF TABLES
1.1 Research questions related to the chapters . . . . . . . . . . . . . . . . . 9
3.1 Approaches for checking consistency . . . . . . . . . . . . . . . . . . . 29
3.2 Solution requirement compatibility of related work . . . . . . . . . . . . 34
5.1 Estimations value model . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2 Causes of intra-model constraint violation . . . . . . . . . . . . . . . . . 93
5.3 Categorization of model changes . . . . . . . . . . . . . . . . . . . . . . 95
6.1 Implementation: Equation system . . . . . . . . . . . . . . . . . . . . . 110
6.2 Implementation: Realized and estimated customer values . . . . . . . . . 111
7.1 SLAs for the SubcribedNews service . . . . . . . . . . . . . . . . . . . 122
7.2 SLAsNewsRequest ............................123
7.3 Cost dependency model constructs . . . . . . . . . . . . . . . . . . . . . 126
7.4 Response time dependency constructs . . . . . . . . . . . . . . . . . . . 127
7.5 Impacttreevertices.............................131
7.6 Supporting services of SubscribedNews and NewsRequest: Impact factors 133
7.7 Matching composition vertices and vertices for dependency trees . . . . . 137
9.1 Effectivenessindicators...........................173
A.1 TimeTranscript...............................206
Part I
INTRODUCTION & MOTIVATION
CHAPTER 1
INTRODUCTION
1.1 Motivation
Model-based implementation approaches are used in various fields like software devel-
opment, information systems development, and e-business development [53, 71, 112].
Many of these approaches allow specifying several models, each emphasizing one spe-
cific aspect or part of the software system. In this thesis we consider such model-based
approaches for modelling inter-organizational cooperations. For example, we consider
Web service compositions and e-business cooperations. These cooperations are often
complex in terms of coordination, agreements, and value creation for the involved part-
ners.
Due to the complex nature of inter-organizational cooperations, usually, a variety of
models is used to specify the information system to be developed. For example, financial
benefits are captured in a business model [92], while coordination details are captured in
a process model [40]. Using several models to represent one complex information system
has many advantages. Especially, understandability of the models is enhanced since each
model only represents some of the information about the system to be developed. As
a result, complexity is reduced for managers reading the models as well as for engineers
developing and maintaining them; especially in cooperations where different partners with
different business goals need to come to an agreement, such a multi-model approach is
beneficial. As typical example of inter-organizational cooperation, consider product and
change management where different partners need to agree on a particular product change.
For example, an automotive vendor and its suppliers need to agree on changes in the
design of a car [89].
Although using several models to represent one complex system enhances usability
when developing a specific model, new challenges arise. Modelling complexity is re-
duced by developing several models at design time, but these models together do form the
basis for the running cooperation and in the end the running information system; i.e., the
implementation must represent the combination of these different models. Therefore, it is
of importance that the different models describe the same system, i.e., that they are con-
sistent with each other, which constitutes our first major challenge. For example, if a high
CHAPTER 1. INTRODUCTION
level business model states that partner A receives money for delivering several products
or services to partner B, the coordination model describing the system should contain this
exchange, and the information systems model should enable it. The challenge is to ensure
consistency between the different models describing one system before implementation.
We refer to this as the problem of ensuring design time consistency.
If the different models describing a particular cooperation are consistent with each
other, there is a proper basis for implementing the information system. However, at run-
time the behavior of the system might be different from that agreed upon. Such deviant
behavior can be caused by implementation errors. Another major cause for these devia-
tions are partners in the cooperation that do not behave according to the agreement. For
example, business partners might not do their payments in time, or agreed upon response
times are violated. Furthermore, deviant behavior is caused by events that cannot be con-
trolled by the business partners, but this behavior is merely estimated when the models are
developed. For example, customer behavior described in models is typically estimated.
However, in real life there can be deviations from these expectancies. This may be bad
(e.g., business partners not satisfying SLAs) or good (e.g., customers buying more goods)
but in any case this is something to be observed. In all these cases the running system
behaves differently from the agreed upon models, i.e., the running system and the models
describing it are inconsistent. We refer to this as runtime consistency. Runtime incon-
sistency is not always problematic, but in any case typically some action is taken when
inconsistencies occur. The challenge is to monitor the system such that inconsistencies
with the models it relies on can be detected. This thesis introduces techniques to make
these things observable.
Furthermore, when managing complex cooperations, it is vital to maintain the models
describing them in order to keep an overview on the behavior and successfulness of the
cooperation. If one model is changed, consistency with other models might be broken.
Therefore, it is a big challenge to regain consistency between the running system and its
models. Especially this maintenance phase is challenging since the different models are
tightly connected and describe different perspectives of the same system. Changing one
model to regain consistency with the running system might result in new inconsistencies
between the different models. As a consequence, this maintenance phase of the models is
time consuming and grows in complexity with increasing number of models describing
the system.
1.2 Problem statement
The problem of checking consistency between related models, of checking consistency
between a running system and its underlying models, and of managing the running system
by maintaining consistency between models and running system is not new. Concerning
design time consistency, there exist multi-model approaches, for example, Unified Mod-
elling Language (UML) [79] and Open Distributed Processing (ODP) [29]. Both aim
at consistent model development. However, these approaches to consistency are model-
4
1.2. PROBLEM STATEMENT
specific and not applicable to other modelling languages. Especially when using different
modelling languages that are not directly related, developers do not have such support.
Furthermore, there exist some approaches that support multi-model development, but they
stay on a very high level explaining rather what should be done than how this should be
accomplished [88, 103].
Concerning runtime consistency, there exist monitoring approaches that support con-
sistency checking of the running system and the models describing it [99, 101]. However,
these approaches mainly focus on monitoring the running system against one model, ne-
glecting dependencies between this model and others. Furthermore, the most challenging
and dynamic part of the problem, i.e., maintaining consistency between models and the
running system, is even less supported in such consistency approaches.
The main problem in ensuring and maintaining consistency between a set of models
is the following: these models are interrelated and, therefore, changing one model might
affect several other models. Therefore, the main challenge is to first identify the exact
nature of the relation between the models, and, secondly, to identify the effects changes
in one model have on the other models.
In this context, this thesis proposes a method that supports ensuring and maintaining
consistency between models and running system for inter-organizational cooperations.
Our goal is to provide a structured and model-independent approach on how to check and
maintain consistency. Thereby, we focus on identifying and maintaining these inter-model
relations.
There are several research questions to be answered in this thesis, and driving the de-
velopment of our approach. Basically, we consider four main research questions. The
first one aims at defining criteria against which we evaluate our solution. These crite-
ria are determined based on a problem analysis through literature research to figure out
characteristics of models and running system for inter-organizational cooperations. Fur-
thermore, we keep the intended users of our method (i.e., researchers challenged with
checking and ensuring consistency in models for inter-organizational cooperations) in
mind when determining the criteria. Based on these characteristics we formulate criteria
for our solution method. In addition, we determine whether current research approaches
suit our requirements.
Research Question 1: What are solution criteria that a method for checking and
ensuring consistency in inter-organizational cooperations should satisfy?
Q1a: What are characteristics of models and running system in the context of inter-
organizational cooperations?
Q1b: What are criteria for a method that checks and ensures consistency in such
models?
The second research question aims at determining current state of the art on the above
sketched topic. In addition, we check whether this research suits the criteria defined by
answering Research Question 1.
5
CHAPTER 1. INTRODUCTION
Research Question 2: What is state of the art on maintaining consistency relations
in inter-organizational models?
Q2a: How is consistency checked at design time in existing solutions?
Q2b: How is consistency ensured during runtime in existing solutions?
Q2c: How suitable are current solutions with regard to the criteria defined in question
Q1b?
The third research question addresses the design of the method for managing consis-
tency relations. Based on the identified criteria and research gap, we build the method.
Firstly, we need to define guidelines on how to ensure inter-model consistency, i.e., we
need to define when we consider two models to be consistent with each other. Secondly,
we need to define guidelines on how to ensure intra-model consistency, i.e., when do
we consider a model to be consistent with regard to the cooperation. Thirdly, we need
to define guidelines on how to ensure consistency during runtime and, finally, we need
to define guidelines on how to maintain consistency for a running system in an efficient
manner.
Research Question 3: How can a solution method for checking and ensuring inter-
model consistency be built?
Q3a: How can inter-model consistency be ensured?
–How can inter-model dependencies be detected?
–How can consistency constraints be defined using these inter-model de-
pendencies?
Q3b: How can intra-model consistency be ensured?
–What intra-model dependencies exist?
–How can consistency constraints be defined using these dependencies?
Q3c: How can consistency between a running system and its underlying models be
checked?
Q3d: How can consistency between a running system and its underlying models be
efficiently maintained?
Our fourth and last research question addresses the validation of our method. Since
this method aims at being suitable for a variety of models, the scenarios should be suffi-
ciently different. We chose as a first scenario business and coordination models and as a
second one Service Level Agreements of composite services. Furthermore, the results of
applying the method to both scenarios are evaluated through implementation.
6
1.3. RESEARCH DESIGN
Research Question 4: How can the solution method be validated?
Q4a: How well applicable is the solution method in different scenarios according to
the criteria identified by answering Research Question 1?
Q4b: How good are the developed solutions when applying the method?
–Validate the solution of both scenarios with a proof-of-concept imple-
mentation.
–Validate the implementation of one of the scenarios through a usability
survey.
1.3 Research design
The research design for this thesis is depicted in Figure 1.1. We start with a literature
study to facilitate a thorough problem investigation. Based on this literature study, we
formulate solution criteria our method should comply with. Furthermore, we evaluate
current state of the art to confirm the necessity of our method for checking and ensuring
consistency.
Secondly, we design the method based on the problem investigation. It is developed
through literature study and design research. The method consists of a stepwise approach
assisting the developer in setting up a proper management environment for the different
models.
Thirdly, we validate the method by conducting two case studies in two different fields
of research. One scenario comprises business and coordination models, while the other
one addresses Web service compositions. Applicability to different scenarios in different
research fields supports the claim that our method is applicable to a variety of conceptual
models.
Fourthly, we provide a prototypical implementation as evaluation of both scenarios.
We conclude with an empirical validation of the Web service composition scenario
by an interactive survey among 34 participants.
1.4 Contribution
The primary contribution of this thesis is the development of an abstract method for man-
aging model dependencies in inter-organizational cooperations. This method is described
in Chapter 4. In addition to this primary contribution, we provide several secondary con-
tributions:
•We provide an extensive categorization of characteristics of different models used
for modelling inter-organizational cooperations. This contribution is provided in
Chapters 2 and 3, and it answers Research Questions 1 and 2.
7
CHAPTER 1. INTRODUCTION
Perform literature study
Chapters 2 and 3 Evaluate state of the art
Chapter 3
Perform literature study
Chapters 3 and 4 Perform design research
Chapter 4
Perform case study:
Scenario 1: Business and
coordination models
Chapter 5
Perform case study:
Scenario 2: Service
compositions
Chapter 7
Provide proof-of-concept
implementation
Chapter 8
Provide proof-of-concept
implementation
Chapter 6
Conduct interactive
survey
Chapter 9
Formulate solution criteria
Chapter 3
Problem investigation
Solution design
Solution validation
Figure 1.1: Research design
•We introduce a comprehensive method that allows ensuring consistency for models
at design time, checking consistency between models and running system during
runtime, and maintaining consistency between models and running system during
runtime of the system. This contribution is provided in Chapter 4 and it answers
Research Question 3.
•We present evaluation of our method application to two different scenarios:
•Scenario 1: Business and coordination models:
–We introduce formal inter-model and intra-model dependency relations, and
dependency relations between running system and underlying models. This
contribution is provided in Chapter 5, and it answers Research Question 4a.
–We provide a proof-of-concept implementation of these dependency relations
that allow users to manage their business models. This contribution is pro-
vided in Chapter 6, and it answers Research Question 4b.
•Scenario 2: Service compositions:
–We introduce formal inter-model and intra-model dependency relations, and
dependency relations between running system and underlying models. Chap-
ter 7, Research Question 4a.
8
1.5. OUTLINE
Part II Part III Part IV
Ch. 2Ch. 3Ch. 4Ch. 5Ch. 6Ch. 7Ch. 8Ch. 9
Q1 x x
Q2 x
Q3 x
Q4 xxxxx
Table 1.1: Research questions related to the chapters
–We provide a proof-of-concept implementation of these dependency relations
that allow users to manage their composite services. This contribution is pro-
vided in Chapter 8, and it answers Research Question 4b.
–We demonstrate usefulness of the implementation for service managers through
an interactive survey. This interactive survey confirms importance of our re-
search. This contribution is provided in Chapter 9, and it answers Research
Question 4b.
1.5 Outline
Table 1.1 shows in which chapters which research questions are addressed. Part I shows
the motivation for this thesis. More specifically, Chapter 1 gives a motivation and problem
statement.
Part II of this thesis introduces our method for managing models of inter-organizational
cooperations. Chapter 2 provides the conceptual frame of our research with basic defi-
nitions used throughout this thesis. In Chapter 3 we conduct a problem investigation by
considering related work. This investigation leads to identification of solution criteria.
The state of the art is reviewed in the light of these criteria. Chapter 4 introduces our
comprehensive method for managing models of inter-organizational cooperations.
In Part III we show applicability of our method to the first scenario where differ-
ent models of inter-organizational cooperations (i.e., business and coordination models)
need to be managed. Chapter 5 discusses the application of the method, while Chapter 6
provides a proof-of-concept implementation of these results to support application of the
method.
Part IV discusses the second scenario, which is inherently different from the first one.
Here, we discuss applicability of our method to service compositions. Again, Chapter 7
describes the application of the method. Then, we discuss our proof-of-concept imple-
mentation in Chapter 8. In addition to this validation, in Chapter 9 we discuss an extensive
interactive survey conducted among experts. This survey supports the suitability of the
proposed management solution provided by the method for real-life use.
Part V concludes this thesis with a discussion on the results and some suggestions for
future research in Chapter 10.
9
Part II
SOLUTION
CHAPTER 2
CONCEPTUAL FRAME
In this chapter we discuss the conceptual frame for our research. The goal is to clarify the
setting and scope of this thesis. In Section 2.1 we explicate our research scope. Further-
more, we discuss the term ‘consistency’ as used in this thesis in Section 2.2. We conclude
with a categorization of types of models and types of consistency in Section 2.3, and an
orthogonal categorization in Section 2.4.
2.1 Scope
The aim of this thesis is to provide a method to manage models of inter-organizational
cooperations. Our goal is to check consistency relations between different models, and
to ensure consistency of models during runtime. Our method is applicable to models
describing inter-organizational interactions that are enabled by information technology.
It is important to clarify the scope of our method, and to be clear on the terminology used
in this thesis.
Inter-organizational relations can be categorized based on the type of relationship part-
ners have. Traditionally, a distinction is made between markets and nonmarkets [60].
Markets are characterized by discrete interactions [73] with limited personal involvement,
no future commitments, and noncooperative and self-interested interactions between the
partners [97]. Nonmarket interactions are characterized by the existence of some sort of
relationship between the partners. Often there exist longer running contracts where the
same service or product is repeatedly exchanged [60]. Such nonmarkets are either hierar-
chically organized with unilateral interactions as, for example, in franchise contracts, or
they are collaborations which are based on bilateral interactions [73, 97].
In collaborations, partners tighten their relationships to gain market strength, to achieve
higher profits, or to exploit new opportunities [98]. A collaboration is often defined as
inter-organizational cooperation which is negotiated in an ongoing communicative pro-
cess [94]. Typically, it is emphasized that a collaboration does neither rely on market nor
on hierarchical mechanisms of control [70].
With the emergence of electronic commerce (e-commerce), the ways of doing busi-
ness have changed dramatically [35, 116]. Inter-organizational systems that do not fit
CHAPTER 2. CONCEPTUAL FRAME
classical categorization of either market, hierarchical or collaborative interaction arise.
Furthermore, different authors use different definitions, and many authors do not explain
which definition they use.
Especially the terms cooperation and collaboration are often used interchangeable in
e-commerce research. However, in cognitive psychology a clear difference between these
terms is made [75]. In a cooperation the problem is split into several tasks, and each task
is executed by one participant. In a collaboration a mutual engagement of participants
exists to solve the problem together [39]. Furthermore, in a cooperation the participants
work together to achieve a clearly defined goal, while in a collaboration often open-ended
tasks without clear goals are present. The main focus is on sharing information in order to
evolve ideas and opinions rather than to achieve a certain goal [16]. From this perspective,
current e-commerce systems resemble more a cooperative than a collaborative form since
there is some mutually compatible interest, each participant has its own contribution to
the overall product, and the relations between the participants are often not personal. The
main difference between cooperations and collaborations on the one hand and markets
on the other hand, is the element of competition [36]. Competitiveness, and as a result
opportunistic behavior, make marketplaces a non-cooperative form of inter-organizational
interaction. The control factor in markets is price. In collaborations or cooperations the
important factor is some relation you have with other parties [97].
In this thesis we refer to inter-organizational cooperations where a cooperation is
some voluntary interaction between two or more partners. Such a cooperation can be
short term and market based, but also long term and of collaborative nature. Models
describing these cooperations are typically conceptual models, but can be described in
a variety of languages like UML Activity Diagrams [90], Petri Nets [64], and BPMN
[113]. An inter-organizational model is suitable to be assessed by our method when it is a
conceptual model that focuses on the exchanges, i.e., interactions, between different part-
ners. We do not support management of any internal behavior of the partners involved.
Furthermore, we assume communication and exchange of information between partners
is (partly) dependent on information technology. Typically, such information technology
enabled business models are referred to as e-commerce business models [108].
2.2 Consistency
In this thesis we support consistency checking at design time as well as maintaining con-
sistency during runtime of the system. Consistency is checked and maintained between
different models and within models.
Consistency can be defined in many ways, however, in this thesis we use the classical
definitions for consistency. Classical Aristotelian logic provides us with a semantic notion
of consistency [102]:
Two or more statements are considered to be consistent if they are simulta-
neously true under some interpretation.
In modern logic the syntactic notion for consistency is defined as follows [68]:
14
2.2. CONSISTENCY
ISIS
Intra-model
consistency Inter-model
consistency
Runtime
consistency
Figure 2.1: Intra-model, inter-model, and runtime consistency relations
A set of statements is considered to be consistent to a certain logical calculus
if no formula P∧ ¬Pcan be derived from those statements by the rules of the
calculus, i.e., the statements are free from contradictions.
Therefore, when we use the term ‘consistency’ we mean the absence of contradic-
tions. At design time of the models, we distinguish between consistency within the mod-
els (i.e., intra-model consistency), and consistency between two or more models (i.e.,
inter-model consistency). Consistency is always determined under some interpretation. A
schematic view on the different consistency checks in this thesis is given in Figure 2.1.
For intra-model consistency we assume the interpretation under which consistency is
determined is given by the definition of the model-specification language. The produced
model needs to be syntactically well-formed and meaningful, i.e., consistent with the
specification. Aside from the official specification, additional constraints on the models
can be formulated in a specific context. For example, one might want to reduce expres-
siveness to avoid complex models. Furthermore, one can extend a language for a specific
goal if it is not sufficiently rich. In this thesis we assume that the models provided are
intra-model consistent (i.e., well-formed) with respect to their specification. Our interest
lays in the relations between the different models.
Refinement of problem statement. We refine the problem statement as defined in Sec-
tion 1.2 for design time and runtime. The challenge in checking inter-model consistency
at design time is defining the proper interpretation under which these models are consid-
ered being consistent. Especially for models defined on different levels of abstraction, or
defined in different modelling languages, this is not a straightforward exercise.
During runtime we first check consistency between the running system and each
model against some interpretation. Again, defining this interpretation is a challenge. As a
second step, we maintain consistency by adapting models or implementations when con-
tradictions are detected. As a consequence of a change in one model, the relations it has
with the other models need to be checked for consistency again.
15
CHAPTER 2. CONCEPTUAL FRAME
2.3 Categorization for models and consistency
Both in Software and Systems Engineering, developing several models that describe to-
gether one system is a commonly used approach to reduce complexity of the models.
To discuss research done in these areas, we define a categorization of the different ap-
proaches. We distinguish between the type of models which is considered, the type of
consistency which is ensured, and how consistency is checked through the different ap-
proaches.
2.3.1 Type of models
We distinguish approaches which handle consistency between different viewpoints on a
system and approaches which handle consistency between different partial models of a
system. A viewpoint on a system describes the entire system under development and fo-
cuses on a specific characteristic (e.g., messages exchanged between partners). Reduction
of complexity in modelling the system is accomplished by leaving out those aspects of
the system that do not belong to the viewpoint characteristic. For example, one viewpoint
might be the cost perspective of the cooperation, while another one describes the order in
which messages are exchanged. As opposed to viewpoint models, partial models describe
different parts of the system in separate models. To reduce complexity, the system under
development is divided in parts that are separately modelled. For example, a company
develops separate models for each partner it is interacting with.
The distinction between these two approaches is important since it influences the con-
sistency relation between the models. Different viewpoints have a complete overlap in the
modelling domain while their focus is disjoint. The challenge is to find the exact relation
between the different foci. Partial models might have an overlap in the domain, but this is
never a complete overlap. The focus of the models, however, might be equal. For exam-
ple, two Entity-Relationship diagrams where each describes part of the system, have the
same focus. In this case the challenge is to find the relation between the different partial
models, rather than to find the relation between the foci.
Since conceptual models used for modelling inter-organizational cooperations can be
both viewpoints and partial models, we look for an approach that checks consistency for
both types.
2.3.2 Type of consistency
We distinguish different types of consistency.Intra-model consistency considers the well-
formedness of a model. The interpretation used for determining consistency is according
to the requirements set for the specification language. Inter-model consistency checks
consistency between two or more models. The interpretation used for determining consis-
tency depends on the type of model used and on restrictions set by the engineer. However,
in this thesis two models are considered to be consistent with each other if a specifi-
cation can be found which represents both models. Homogeneous (also referred to as
intra-language) approaches consider models of the same type, while heterogeneous (i.e.,
16
2.4. ORTHOGONAL CATEGORIZATION FOR MODELS AND CONSISTENCY
inter-language) approaches are able to handle consistency checks between two models
expressed in different languages.
For modelling inter-organizational cooperations typically heterogeneous models are
used. Therefore, we look for an approach that handles such heterogeneity.
2.3.3 Ensuring consistency
Further, we distinguish between different ways of ensuring consistency. Two main op-
tions are to check consistency after models are developed or to ensure consistency by
construction during the development process. Checking consistency can be done by test-
ing the models with some model checker, or by finding a translation. Usually models
are translated into a semantically well-defined formalism which allows for formal consis-
tency checking. When translating models, either they are completely translated or only the
overlapping parts between them are translated. A complete translation is time consuming,
while in a partial translation first the overlap between models is determined. Especially
when dealing with heterogeneous models this is not straightforward. When consistency
is ensured during construction of the model, either additional development requirements
for the models are set, or consistency is defined by relating their meta-models.
Aside from consistency checking, we aim at maintaining consistency during runtime
of the system through some adaptations. Maintaining consistency cannot be done through
construction since consistency through construction is done at design time. Maintaining
consistency is done at runtime. Therefore, our approach should allow consistency ensur-
ing through checking rather than through construction.
2.4 Orthogonal categorization for models and consistency
An orthogonal distinction between types of consistency is on the type of relation these
models have. These relations are depicted in Figure 2.2.
In viewpoint approaches the relation is between foci of the models (cf. Figure 2.2a).
For example, how does the order of messages in a coordination model relate to costs of
collaborating with a partner. Usually, this is a heterogeneous consistency relation defined
on the entire model.
The relation between parts of partial model approaches is different in nature. Here,
different types are distinguished. Firstly, there are models that describe a different part of
the system, but are on the same level of abstraction. These might be homogenous models,
for example two Entity-Relationship diagrams, or heterogeneous models, for example an
Entity-Relationship Diagram and an Activity Diagram. This type of consistency relation
is often referred to as horizontal consistency [78] (cf. Figure 2.2b).
Another relation is between models on different levels of abstraction covering the
same part of the system. One model is a refinement of the other one. These models
are said to have a vertical consistency relation [45] (cf. Figure 2.2b). In partial model
approaches often high-level models are defined which are iteratively refined until the level
of abstraction is such that the model can be translated into executable code. With this type
17
CHAPTER 2. CONCEPTUAL FRAME
Viewpoint2
Viewpoint1'
System under
Development
Viewpoint1
evolution
(a) Viewpoints
System under
Development
M1
M1' M2
M3
horizontal
vertical
evolution
(b) Partial Models
Figure 2.2: Multi-model approaches for maintaining consistency
of development, refinement consistency is constructed rather than checked. It should be
noted that during the refinement process often information is added to models that is not
present in the higher levels. Therefore, these relations are usually not pure refinements.
A third dimension is evolution consistency [78] which is present in both viewpoint
and partial model approaches (cf. Figure 2.2). When a model evolves during development
process, the relation between old and new model is referred to as evolution consistency.
This relation is always between homogeneous models.
2.5 Summary
In this chapter we discuss techniques for checking and maintaining consistency across
models describing a single system. For our purpose, we seek an approach that is language-
independent, is able to handle heterogeneous models, is suitable for both viewpoints and
partial models, and ensures consistency through checking rather than through construc-
tion.
18
CHAPTER 3
PROBLEM INVESTIGATION & RELATED WORK
Inter-organizational cooperations are getting ever more complex due to the increasing use
of IT. In particular this holds for models describing these systems. To reduce complexity,
inter-organizational cooperations are often described by more than one model where each
model focuses on a specific aspect of the cooperation. The models together form the basis
for implementing the cooperation. As a consequence, consistency between models needs
to be ensured when designing the cooperation and be maintained while running it.
In this chapter we assess the problem of ensuring and maintaining consistency be-
tween models and running system by considering difficulties in identifying relations be-
tween models and running system. When comparing different models their heterogeneity
gives rise to several challenges that are discussed in Section 3.1 (cf. Figure 3.1). Details
on checking alignment of the running system with the models describing it are discussed
in Section 3.2 (cf. Figure 3.1). Besides compatibility issues between models and between
models and running system, we analyze specific issues that occur when maintaining such
systems in Section 3.3. Based on this analysis, we discuss solution requirements for a
method designed to ensure and maintain consistency between models and running system
at hand in Section 3.4. These requirements solve a subset of the identified problems in
this chapter. Finally, we discuss state of the art concerning existing methods for managing
consistency between models in Section 3.5. Several methods exist but, as we show, none
of them complies with all solution requirements identified in Section 3.4.
3.1 Model heterogeneity
Different conceptual models jointly describe an inter-organizational cooperation. Each
model has a different purpose and, therefore, the models are often denoted in different
modelling languages. Checking consistency between such heterogenous models while de-
signing the system is a difficult process. Challenges arise because different models have
different focus or view, but often have an overlap in parts of the system they describe.
Consistency problems occur at overlapping parts if models contradict in their description.
For example, most models describe the actors involved in the cooperation. It is therefore
important to ensure that all models describe the different actors in a consistent manner.
CHAPTER 3. PROBLEM INVESTIGATION & RELATED WORK
Model A Model B
ISIS
ELEL check consistency
assume consistency
Section 3.2: model heterogeneity
Section 3.3: Alignment with running system
Figure 3.1: Consistency relations between models, event logs, and information systems
Furthermore, models may depend on each other. For example, a business model might
describe what information and products are exchanged in a cooperation, while an imple-
mentation model describes how these exchanges are realized. Consequently, whether the
goals in the business model are achieved depends on a proper implementation of the im-
plementation model. As a result, the challenge at hand is to compare overlapping parts in
models possibly described in different modelling languages and with different purposes.
Furthermore, dependencies between models should be identified, analyzed, and made
explicit. Next, we identify heterogeneity problems that arise when comparing heteroge-
neous models. These problems are in the way of an easy identification of overlap and
dependencies. We distinguish between syntactic, semantic, and pragmatic heterogeneity.
3.1.1 Syntactic heterogeneity
When comparing two models described in different languages the first challenge is to
compare the relation between constructs in different languages. For example, an arrow in
one language might be used to describe data flow, while in another language it denotes
event flow. By comparing the syntax (i.e., the structure) of the different languages, rela-
tions and dependencies between them can be identified. For example, an activity in one
language might be related to data flow in another language. These syntactic characteristics
are language dependent and need to be identified by hand.
When dealing with syntactic heterogeneity, the challenge is to identify both match-
ing concepts and non-matching concepts. Typically, conceptual modelling languages use
concepts and relations between concepts to structure the world. Often, these concepts
and relations appear to match concepts and relations in another language. However, usu-
ally there exist subtle differences between them and we need to identify exactly these
differences.
20
3.1. MODEL HETEROGENEITY
3.1.2 Semantic heterogeneity
The second kind of heterogeneity between models concerns semantic heterogeneity. This
is a broad research area closely related to ontology matching [55, 87, 93], where the
challenge is to find a match between an ontology used in one model and an ontology used
in another model. A common problem is to identify differently named concepts in two
models referring to the same entity in the cooperation; i.e., to find coreferences in the
different models. For example, one model might use the term “seller” where another one
uses the term “provider”. Another common problem is to identify homographs where one
semantic concept is used in different models to refer to different entities in the cooperation.
For example, in one model the term “seller” might refer to a wholesaler in the cooperation,
while in another model it refers to the retailer that buys from the wholesaler. When
modelling inter-organizational cooperations, semantic heterogeneity is often the result of
different model developers, different actors discussing the models, and different purpose
of the models. Although ontology matching is a well established research area, automatic
ontology matching constitutes a challenge where many matchings are still done by hand
which is a tedious process.
3.1.3 Pragmatic heterogeneity
We refer to heterogeneity between two conceptual models describing an inter-organizational
cooperation that is not caused by semantical or syntactical differences as pragmatic het-
erogeneity. Pragmatic heterogeneity is the result of differences in purpose and focus of the
models, which leads to a variety of representations [95]. However, both overlap and de-
pendency between models need to be identified so that consistency can be checked. For
this, heterogeneity is identified and handled. Here, we summarize common pragmatic
heterogeneity in inter-organizational models.
Perspective & focus. As discussed, it is important to provide several models on the
inter-organizational cooperation that together capture the full complexity of the coopera-
tion. Every model focusses on a specific aspect of the system ensuring all details of that
aspect are captured in the model. As a consequence, other parts of the cooperation that are
not part of the focus, are suppressed or filtered out in the model at hand. Secondly, while
focusing on a specific aspect, the cooperation is described from different perspectives.
Next, we describe both focus and perspective of a model.
First, there is a choice how to focus the model. Typically, either partial models or
viewpoints are used, as discussed in Chapter 2.3 (cf. Figure 3.2). In a partial model the
focus is on a subset of the cooperation that is described. For example, one model might
describe interactions between all suppliers in a cooperation, while another one describes
the interactions between one specific supplier and its customers. Here, the distinction is
made by splitting the physical world to be described into parts. In a viewpoint, a particular
aspect of the cooperation is modelled, ignoring all other aspects. For example, one model
might focus on money being exchanged between actors, while another describes network
21
CHAPTER 3. PROBLEM INVESTIGATION & RELATED WORK
bird’s eye single actor
Perspective
Focus
Information
System
Information
System Information
System
Information
System
Viewpoint
model Viewpoint
model partial
model
partial
model
Figure 3.2: Perspective and focus
messages exchanged between the actors. In both cases the complete physical world is
modelled, but details about this world are left out.
Second, there is a choice from what perspective to describe the model. Typically,
either a single actor perspective or a bird’s eye perspective is chosen (cf. Figure 3.2).
On the one hand, a model with single actor perspective ignores any information that is
not related to this specific actor concerning the cooperation. For example, a cooperation
where a group of wholesalers sells goods to a group of retailers, might be described by
a model depicting the relation between one specific retailer with wholesalers, ignoring
retailers and wholesalers it has no relation with. On the other hand, a model from a bird’s
eye perspective describes the cooperation with all actors involved.
Both foci (i.e., partial models and viewpoints) can be described from both perspectives
(i.e., single actor perspective and bird’s eye perspective). For example, a model might
describe network connections in a cooperation (i.e., viewpoint) from the perspective of a
specific seller (i.e., single actor perspective). Another example is a model describing just
the suppliers (i.e., partial model) and all their relations (i.e., bird’s eye view).
Although the models together describe the complete cooperation, typically, several
parts of the cooperation are described in more than one model, i.e., typically, there exists
an overlap between the different models. The challenge is to check consistency, espe-
cially concerning overlapping parts, between models with different focus. For example,
comparing a model describing a specific supplier with one describing average behavior of
a group of suppliers, raises the challenge to compare one specific supplier with average
values of a group. Secondly, there often exist dependencies between the different models
where some aspects in one model influence the performance of another model. Consider,
for example, one partial model describing a company’s relation with its customers and
22
3.1. MODEL HETEROGENEITY
Coarse grained model
Fine grained model
Coarsening
Abstraction
Generalization
Leave out
information
wholesaler retailer
sellers
Model A’
Model A
Model B
Model B’
Generalize
Figure 3.3: Coarsening models
another one describing its relation with its suppliers. Now, performance of the model be-
tween company and suppliers influences performance of the model depicting the relation
with its customers. In more detail, when the supplier model describes delivery times of
two weeks after a request, the customer model needs to comply with these two weeks.
Identifying focus and perspective of a model provides a starting point to find overlap and
dependencies between models as well as to ensure consistency between them.
Granularity. Typically, a cooperation is described through models of various granular-
ity. Granularity is the level of detail with which the cooperation is described in a model.
More granular models (i.e., more specific models) are referred to as fine-grained mod-
els as opposed to coarse-grained ones. Coarsening a model, i.e., making a model less
detailed, is another way of filtering out details on the cooperation that are not necessary
for the purpose of the model [117]. We distinguish two different types of coarsening:
abstraction and generalization [117] (cf. Figure 3.3).
Coarsening through abstraction is the process of leaving out details on the cooperation
(cf. Figure 3.3). In conceptual models, when describing inter-organizational cooperation,
transitive abstraction is often used to reduce complexity. For example, a company might
deliver its products using a transporting company, while a model describing this process
might mention the transfer of products from company to customer, leaving out the trans-
porter. A requirement for transitive abstraction is that relationships are of the same type
and in the same direction. Another commonly used technique is substitutional abstrac-
tion where a set of related concepts is substituted by one concept describing the set. Other
than in transitive abstraction, relations might be of different types. Moreover, besides re-
moving concepts and relations, a new concept is added. For example, the description of
the internal business processes for handling an incoming order, might be represented as
one process named “handle order”.
23
CHAPTER 3. PROBLEM INVESTIGATION & RELATED WORK
Coarsening through generalization is the process where commonalities between con-
cepts or their relations are identified and the result is used to describe a set of concepts
or relations (cf. Figure 3.2). In this case, no information is left out, but rather described
on a higher level of detail. Common ways of generalizing in conceptual models for co-
operations are (1) to identify patterns [80] and (2) to identify hierarchies [107]. When
generalizing through patterns, several sets of concepts and their relations are described as
one general set. For example, a company allows both payment by bank transfer and by
credit card, while a model describes the pattern of money payment in general. When gen-
eralizing through hierarchies, a set of concepts is described through one general concept.
For example, ‘wholesalers’ and ‘retailers’ are grouped into ‘sellers’.
The challenge at hand is to find relations and dependencies between concepts and rela-
tions in models with different granularity levels. For example, relating high level concepts
on sales targets in one model with low level concepts on network exchanges in another
model is not straightforward. Another solution is to bring models to the same granular
level by coarsening through abstraction and generalization. An obvious consequence of
coarsening models is loss of information.
Time frames. A third pragmatic heterogeneity factor is difference in time frames of
models. Each conceptual model of a cooperation is meant for a specific period of time.
The smallest possible time frame is captured in instance-based models, while other mod-
els describe a period of time. We distinguish between models that have different length in
modelled period of time, and models that describe an equal length, but have a shifted time
frame. For example, a model describing average costs of a commodity for the coming
year and another model describing expected profits for selling the product containing that
commodity for the coming month have different time frame length. A model describ-
ing the cooperation for the coming week and another one for the following week have a
shifted time frame.
The problem at hand is to check models for consistency since their time frames do not
match. Consider the example where average commodity costs are determined per year and
expected profit per month. It is difficult to state something about their consistency since
the current expected profit might not fit average commodity costs, while the remaining
eleven months of profit might make up for this. Therefore, a choice in handling these
time frame differences needs to be made, and a first step is to recognize these differences.
Estimation and prescription. Since models considered in this thesis describe inter-
organizational cooperation as it should be, they are referred to as prescriptive models.
Typically, these models describe agreements between different actors in the cooperation.
Their implementation enforces actors involved to act according to the agreement. For
example, a model might describe delivery of goods is done only after receiving a payment.
This behavior might be enforced in the implementation. However, besides agreements
such models might also contain estimations. Typically, these estimations are done for this
part of the cooperation that cannot be controlled through implementation like customer
behavior. Typically, estimations are made on the number of expected customers, expected
24
3.2. ALIGNMENT WITH THE RUNNING SYSTEM
revenue, payment choices, etc. Implementation of these estimations should allow the
estimated behavior as well as deviations from it. For example, when it is estimated that
fifty customers will purchase a product this month, the system should allow this as well
as deviations from this behavior, i.e., more or less customers.
Often, it is not immediately clear whether certain behavior is an estimated average
or an agreed average. For example, a business model might describe an average of fifty
customers per month (i.e., an estimated average) that should receive their ordered products
on average in three days (i.e., an agreed average with the suppliers). Both averages are
depicted as transfers between actors, leaving the difference between estimated and agreed
average implicit. However, this difference should be implemented and when comparing
high level models (like business models) with more detailed, low level models that are
directly implemented (like workflow models) this difference should become apparent.
In this thesis we refer to prescriptions when parts of a model enforce behavior, and
we refer to estimations when parts of a model are expected to behave in a certain way.
3.2 Alignment with the running system
Aside from checking consistency between the different models at design time, their con-
sistency with the running system should be checked (cf. Figure 3.1). Checking a model
against the running system is usually done based on event logs and is typically referred to
as conformance checking [99] or consistency checking [8, 49]. In particular, it is crucial
to check whether the models are implemented accurately, whether all actors behave ac-
cording to the made agreements, and whether estimated behavior is indeed realized. An
event log is consistent with a model if the essential parts of the model do not contradict
reality, i.e., it does not contradict the content of the event log, or vice versa.
In this thesis, we assume the event log is consistent with the running system (cf. Figure
3.1). Consequently, the event log is used as correct representation of the running system.
For consistency checking between a running system and its models, we distinguish two
main challenges. The first one is to identify which essential parts in the model actually
appear in the event logs. For example, when estimations are done on the number of
customers that register the coming month on a Web site, this data is detected as events
in event logs. However, estimations on the male-female ratio of these registrations might
not be visible in such log. The second challenge is to abstract essential information from
event logs, i.e., to abstract information that enables consistency checking between running
system and model. Typically, either the system is adapted in such a way that events
entering the event log have the proper format or the necessary format is reconstructed
from raw event logs after they are created. Although the first option, i.e., adaptation during
runtime, is preferred since it is a one time effort, often this is not possible because of used
software. As a consequence, event logs are often analyzed after runtime, i.e., necessary
information is reconstructed. In this thesis, we explain both techniques in Chapter 4.
25
CHAPTER 3. PROBLEM INVESTIGATION & RELATED WORK
3.3 Maintaining models
When checking consistency, contradictions between model and running system or be-
tween two models might be detected. Ideally, these inconsistencies are resolved by adapt-
ing either model or implementation. Resolving inconsistencies is part of model main-
tenance. Although we do not propose any maintenance solutions, we do provide suffi-
cient feedback for the developer to make proper maintenance decisions. Furthermore, the
method in this thesis should allow for extensions and further development of automatic
model adaptation.
Maintaining a set of models describing the same system is particulary challenging
since the different models overlap and contain dependencies. As a consequence, changing
one model to regain consistency with another one could introduce inconsistencies with
other models. Therefore, not only the inconsistency itself should be identified, but also
its causes and, if possible, information on the effects of changes in the model to resolve
inconsistency. As discussed in Chapter 2, this is typically not provided by multi-model
consistency approaches, where inconsistencies are identified, but no solutions for model
maintenance are provided.
3.4 Solution requirements
Based on the conceptual frame of our research discussed in Chapter 2 and the problem
analysis done in this chapter, we formulate solution requirements for our method. The
aim of the method is to provide an approach to check and maintain consistency between
models for inter-organizational cooperations.
The scope of our research determines the scope of our method. The first requirements
concern this scope. It is important that our method enables handling models specified
in different languages since we aim supporting management of conceptual models for
inter-organizational cooperations in general. Therefore, the approach should be language-
independent (Requirement 1). Furthermore, the approach should support management of
heterogeneous models (cf. Section 3.1) since a cooperation is typically described by a set
of models using different specification languages (Requirement 2). A third design time
requirement is that the method supports checking consistency (cf. Chapter 2.3.3). This is
necessary since ensuring consistency through construction does not provide support for
checking consistency at runtime where models are already constructed. In summary, we
provide the following requirements:
26
3.4. SOLUTION REQUIREMENTS
•R1 The method should be language-independent.
•R2 The method should be able to handle heterogeneous models, i.e., models
described in different languages.
•R3 The method should ensure consistency through checking rather than
through construction.
After defining the scope of the method, we define guidelines the approach should pro-
vide to manage consistency of models at design time. One goal of the method is to define
consistency constraints for inter-organizational models (Requirement 7) (cf. Chapter 2.2).
These guidelines for defining consistency constraints are only possible after we compare
heterogeneous models. Therefore, the method should provide guidelines to overcome het-
erogeneity problems discussed in Section 3.1 (Requirement 4). To compare models we
should provide guidelines to identify overlap (Requirement 5) and to identify dependen-
cies (Requirement 6) between different models. In summary, the following requirements
should be fulfilled:
•R4 The method should provide guidelines for overcoming model heterogene-
ity.
•R5 The method should provide guidelines for identifying overlap between
models.
•R6 The method should provide guidelines for identifying dependencies be-
tween models.
•R7 The method should provide guidelines for defining consistency constraints
for inter-organizational cooperation models.
In Section 3.2 we discuss alignment of models with the running system. The method
should provide guidelines to identify overlap between event logs and models (Require-
ment 8). If there are inconsistencies between running system and models, these are de-
tectable in overlapping parts. Furthermore, it is important that necessary information to
check consistency between running system and models is logged in a usable format (Re-
quirement 9). Aside from gathering necessary information, it is important to provide an
approach that allows abstracting this information from event logs (Requirement 10). Us-
ing overlap between models and running system, and abstracted information from event
logs, it is possible to define consistency constraints. These consistency constraints de-
pict the relation between running system and model (Requirement 11). In summary, we
formulate the following requirements to enable consistency checking between event logs
and models:
27
CHAPTER 3. PROBLEM INVESTIGATION & RELATED WORK
•R8 The method should provide guidelines to identify the overlap between event
logs and model.
•R9 The method should provide an approach to log information necessary for
consistency checking.
•R10 The method should provide an approach to analyze an event log to abstract
necessary information for consistency checking.
•R11 The method should provide guidelines for defining consistency constraints
between running system and its underlying models.
To complete lifecycle management of our models, we discuss model maintenance in
Section 3.3. We identify the necessity to show consequences of model adaptations to
regain consistency (Requirement 12). Furthermore, it is important to provide feedback
to users of our management approach. These users can be, for example, managers that
maintain models. Such feedback should contain information on constraint violations,
and on consequences of solving such violations (Requirement 13). We formulate the
following method requirements for maintaining consistency at runtime:
•R12 The method should provide an approach to show consequences of model
adaptations on consistency relations.
•R13 The method should provide an approach to provide monitoring results as
feedback.
3.5 State-of-the-art research
Terminology differs greatly among researchers. However, related work described in this
section is done in terminology used in this thesis. Table 3.1 provides an overview of the
different approaches discussed in this section. The table arranges approaches according to
the categorization discussed in Chapter 2.3. The type of models that are handled by the ap-
proaches is specified in the first part of the table. Secondly, we depict whether approaches
provide mechanisms to cope with inter-model and intra-model consistency constraints.
Furthermore, some approaches are limited to homogeneous models, i.e., different models
described in one language, while others are able to handle heterogeneous models. The last
part of the table specifies how consistency is ensured. Some approaches provide mecha-
nisms to check consistency through testing, translation of overlapping parts, or complete
translation of models. Three approaches ensure consistency through construction. At the
end of this section, we discuss whether or not any approach fits the solution requirements
for the method (cf. Section 3.4).
28
3.5. STATE-OF-THE-ART RESEARCH
Type of Models Type of Consistency Ensuring Consistency
Viewpoints Partial Inter-model Consistency Intra-model Checking Construction
Models Homo- Hetero- Consistency Testing Translation
geneous geneous OverlapComplete
Mens et al. [79] x x x x
Astesiano et al. [10] x x x x
Engels et al. [47] x x x x
xlinkit [85] x x x
Egyed et al. [44] x x x
Varr´
o et al. [111] x x x x
χbel [41] x x merge
Uchitel et al. [110] x x merge
Fradet et al. [52] x x x
Bowman et al. [30, 29, 37] x x x
Hunter et al. [61] x x x
Viewpoints [51] x x x
Table 3.1: Approaches for checking consistency
29
CHAPTER 3. PROBLEM INVESTIGATION & RELATED WORK
Partial models. Mens et al. [79] target at supporting consistent evolution of UML mod-
els. However, their approach also allows checking intra-model consistency. Their model
checker is description logic based and implements the different UML metamodels. The
metamodels ensure intra-model consistency, and relations between metamodels as defined
by UML ensure inter-model consistency. Since their approach relies on implementing ex-
isting metamodels (that specify consistency constraints) of UML, this approach is not
usable in a non-UML context.
Astesiano et al. [10] investigate existence of ambiguities and inconsistencies in the
language definition of UML. The authors do not aim at solving inconsistencies between
UML diagrams for a particular specification, but aim at finding these ambiguities and in-
consistencies in the language itself. Their aim is to develop a consistent UML language
using a logic-algebraic method. This approach focuses on reducing inconsistencies in
UML by improving the metamodels. Therefore, they are classified as achieving consis-
tency through construction by improving the metamodel (cf. Table 3.1). However, this
approach relies on translating models.
Engels et al. [47] develop a method to check consistency of UML models to decide at
which point in time of the development process, UML partial models should be consistent
with each other. They distinguish between consistency of dynamic and of static models
where dynamic models specify behavior as opposed to static models. In UML consis-
tency requirements exist that specify consistency relations between different model types.
An example of such a consistency rule is that a statechart has to accept each stimulus
a sequence diagram specifies. Their implementation (the Consistency Workbench) tests
whether two models are consistent against these consistency rules. They partially formal-
ize the models (i.e., only overlapping parts) into a common semantic domain. For each
consistency rule the suitable semantic domain for consistency checking is determined.
A discovered inconsistency is either tolerated or resolved. Their approach is originally
developed for horizontal consistency, but is later extended to evolution consistency [46].
With evolution consistency the emphasis lies in preserving certain aspects of the model
while it is evolving, e.g., preserving the absence of deadlocks. This is achieved by adding
rules to the implementation. A drawback of this approach is the use of several semantic
domains for one set of models. Relations between constraints across domains are then not
expressed. A specific problem is the question what the effect of solving an inconsistency
between two models is in respect to other constraints these models might have to satisfy.
In our work we avoid the use of different semantic domains to avoid losing these relations.
Xlinkit [85] is a method for expressing constraints between heterogeneous models. It
offers a semantics that shows links between two mutually inconsistent elements of dif-
ferent models. Their focus is on identifying inconsistencies rather than solving them
although their diagnostic method has later been extended with a repair actions method
[86]. Although xlinkit is mainly used for UML models the authors argue their method is
language-independent. The consistency rules are expressed in the tool using a restricted
form of first order logic, which restricts expressiveness of the rules. Furthermore, the
models to be checked for consistency have to be transformed completely into XML for-
mat. Both restriction on the rule definition and constraint that models must be expressed
30
3.5. STATE-OF-THE-ART RESEARCH
in XML makes this approach unsuitable for our problem definition.
Egyed and Medvidovic [44] provide an approach for heterogeneous software devel-
opment. It enables mapping of an architectural design model into UML models. This is
a heterogeneous refinement approach since the architecture is refined into UML models.
It ensures initial consistency only since it is a unidirectional approach. This means that
consistency is ensured between architectural model and UML model, but any updates to
UML models, or refinement of UML models into other UML models might interfere with
the original architectural model. To overcome the problem of further refinement of UML
models and their possible inconsistency with the overall architectural model, abstractions
from concrete models to abstract ones (vertical) and from specific ones to generic ones
(e.g., instance to class) are supported. Finally rules for transforming one language into
the other in a consistent manner are defined. Although the authors state their approach is
language-independent, it has only been illustrated by transforming C2 models [44] into
UML models.
Many approaches rely on model transformations. The goal is to transform models
from one tool to another by using an intermediate universal language (e.g. XML). How-
ever, a correctly defined metamodel is crucial to handle these transformations. Varr´
o and
Pataricza [111] tackle several of the metamodelling problems (causing inconsistencies) by
defining different rules in their construction. They offer a metamodelling method which is
applicable to UML as well. Their method proposes a multilevel metamodelling approach
to overcome the well-known problem of replication of concepts. Heterogeneous refine-
ment is supported in a consistent way. Although focus is on metamodelling and not on
consistency checking, it does facilitate the development of consistent models. However,
their approach does not extend beyond the redefinition of metamodels.
Viewpoints. Easterbrook and Chechik [41] develop the χbel framework for merging in-
consistent state machine models, i.e., state machine models that describe different behav-
ior. χcheck is a model checker which checks properties of merged models. Multi-valued
logics are used which allow statements like “the majority says” instead of only “true” and
“false” (i.e., “everyone says” and “no one says”). This enables reasoning over inconsis-
tent models. The merging and reasoning process over different models depends on the
relation models have with each other. Different models can be (partially) overlapping,
can be different versions, or can be just interacting. The goal is to reason with stakehold-
ers about different options they have to merge models. The models can be analyzed in
different merge scenarios as well as before the merge. Since there is inter-model incon-
sistency, several ways of regaining consistency through merging techniques are possible.
However, some stakeholders have to give up certain requirements and make concessions.
The approach is only suitable for homogeneous models and is, therefore, not suitable for
our problem.
Uchitel and Chechik [110] develop an approach to merge partial behavioral models in
the same language. Here, partial refers to partial behavior where models provide concepts
for not yet known behavior. Their approach is suitable for viewpoint models. It assumes
models being intra-model consistent and argues that the result of the merger should be the
31
CHAPTER 3. PROBLEM INVESTIGATION & RELATED WORK
minimal common refinement of considered models. The result is said to be consistent if
it is a common refinement of both models. This approach is suitable for any state-based
behavioral system with formal semantics. It focuses on observable behavior of models
rather than on structural aspects. The restriction made in respect to homogeneous state-
based models is not sufficient in the context of our problem statement.
Fradet et al. [52] develop a method for defining multiple view architectures. Their
approach is formal, suitable for heterogeneous models, and not language-specific. The
structural part of each view is represented as uninterpreted graph. Consistency between
different views is checked on graphs by means of an algorithm. The interpretation of
graphs is done through formulating a set of constraints that specifies both intra-model and
inter-model requirements. Checking consistency of diagrams with respect to requirements
is done through some decision procedure. Although it is recognized that formalizing all
constraints in graphs might be cumbersome for large models, the authors state that this is
not a problem since their graphs can be expressed in constraints. Their approach is specif-
ically designed for software architectures where the focus is on different components and
their connections. More specifically, they focus on the structural part of the architecture,
while our method aims at a more complete approach where also communication between
different actors is modelled.
Consistency checking is a big concern in Open Distributed Processing (ODP). ODP
provides a method for distributed development where five viewpoints are proposed for
the modelling phase: enterprise, information, computational, engineering, and technol-
ogy. Several viewpoints on the same system are developed, each having its own focus.
The requirements modelled in each of these viewpoints should be reflected in the overall
description of the system. Each viewpoint is described in a separate specification. All
specifications together should be reflected in the overall description of the system. An
approach to ensure or check the existence of such a description in ODP is proposed by
Bowman et al. [30, 29, 37]. They aim at checking and ensuring existence of an overall sys-
tem description capturing each viewpoint. Consistency between specifications is defined
as the existence of an internally valid description which represents all requirements of the
specifications. Consistency is checked between a viewpoint specification and the overall
description, but not between two viewpoints. As a result, consistency requirements be-
tween one viewpoint and the overall description, might differ from requirements between
another viewpoint and the overall description. This difference occurs when viewpoints are
described in different languages and have different levels of abstractions. The authors re-
fer to this as unbalanced consistency. By doing bilateral consistency checks (i.e., between
each viewpoint and the descriptions separately) it is difficult to create global consistency.
Each viewpoint might be consistent with one or more descriptions, but finding a descrip-
tion which is consistent with all viewpoints is hard to find. Therefore, they propose to
ensure global consistency by unification of viewpoints. Two viewpoints are unified after
one of them is translated into the other, or after both of them are represented in a common
semantic domain. By showing intra-model consistency of the unified model, two view-
points are proven to be consistent with each other. Now, a third viewpoint can be unified
in the same manner with the result of the previous unification. For our purpose this ap-
32
3.5. STATE-OF-THE-ART RESEARCH
proach is less suitable since it relies on one universal language in which all viewpoints
are translated. This approach might work for ODP, but not for our purposes.
Hunter and Nuseibeh [61] propose a logic-based approach for reasoning in the pres-
ence of inconsistencies. They propose quasi-classical logic, which is a weakened version
of classical logic. It allows reasoning with inconsistencies by deriving all resolvants of as-
sumptions without allowing trivial derivations. This approach first labels information and
then these labels are propagated through the reasoning process. This allows tracking in-
consistent information and provides a better problem analysis. Furthermore, this approach
computes maximally consistent subsets of the inconsistent information. Obviously, this
means that viewpoints are translated into logic.
The Viewpoints framework [51] and extensions to it [42, 50] allow inconsistencies
when developing the different viewpoints in order not to kill creativity. Their method is
logic-based and allows checking well-formedness (i.e, intra-model consistency) as well as
inter-viewpoint consistency (i.e., inter-model consistency). The viewpoints are translated
into logic and tested against predefined consistency and well-formedness rules. Con-
sistency rules are created per viewpoint and are locally stored. So, there is no overall
consistency checking mechanism. The authors assume that each developer is concerned
with consistency of the viewpoint he is working on. For a relation between two models
the Viewpoints framework defines two rules: one belonging to the first model and one to
the other model. As a result, engineers of the models both have one consistency rule to
manage. If a rule is violated, its “owner” determines whether or not it should be resolved.
For each kind of rule violation there exists a solution approach. Since the goal is not to
maintain global consistency, this approach is not suitable for our problem. The focus is
rather on bilateral consistency, resulting in a local view. As a result, it is not calculated
what the effects are on relations other than the bilateral relation that is dealt with.
Overview approaches. Spanoudakis and Zisman [103] introduce a method with a six
step approach to maintain consistency in model development. Their approach is the uni-
fication of several other approaches and tries to cover all concerns. The six steps are as
follows: detecting overlap, detecting inconsistencies, diagnosis of inconsistencies, han-
dling inconsistencies, tracking, and specification and application of an inconsistency man-
agement policy. An interesting detail in this method is the distinction between different
overlap types. Many approaches assume that there either exists a complete overlap or
no overlap at all, which is not realistic. For example, small differences in arity are of-
ten not allowed in such approaches when comparing two Entity Relationship Diagrams,
while this approach does. As solution most approaches use a shared ontology, or require
some human inspection, or there is some automated similarity analysis in which syntac-
tics and semantics are checked between models. Detection of inconsistencies is done with
logic-based approaches, model checking approaches, specialized model analysis, or with
human centered exploration. The authors state that the main challenges in inconsistency
detection are efficiency and scalability, especially when dealing with evolving models.
Although this approach does not provide a tool or specific approach for maintaining con-
sistency, the identification of concerns in maintaining consistency relations is impressive.
33
CHAPTER 3. PROBLEM INVESTIGATION & RELATED WORK
Nuseibeh et al. [88] describe a high-level method for managing consistency in soft-
ware development. In their method consistency rules are applied to detect inconsistencies
during the monitoring process. Then inconsistency is analyzed and it is determined how
to deal with the inconsistency. Consequences of handling the inconsistency are, in turn,
monitored. Conclusions of some practical experience are observations on how difficult it
is to decide when to do a consistency check. Especially since partial models are devel-
oped in parallel and updates might look incomparable to the original model checked for
consistency. It might be too costly to do the check. As a last point they state that during
model development, inconsistencies might be tolerated. Many of these inconsistencies
sort out themselves. Obviously, hoping that an inconsistency resolves itself or that the in-
consistency does not cause any problems, causes significant risks in information systems
engineering.
Although these overview approaches provide some starting points for maintaining
consistency of inter-organizational models, they do not provide sufficient detail to over-
come model heterogeneity and to define consistency constraints. Therefore, they provide
a good starting point, but are not sufficient for our purpose.
3.5.1 Discussion on related work and solution requirements
R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13
Mens et al. [79] v v v v
Astesiano et al. [10] v v v
Engels et al. [47] v v v v
xlinkit [85] v v v v v v
Egyed et al. [44] v v v v v
Varr´
o et al. [111] v v v v v
χbel [41] v v v v
Uchitel et al. [110] v v v v
Fradet et al. [52] v v v v v v v
Bowman et al. [30, 29, 37] v v v v v v v
Hunter et al. [61] v v v v v v v
Viewpoints [51] v v v v v v v
Table 3.2: Solution requirement compatibility of related work
Table 3.2 depicts how well discussed related work fits solution requirements for the
method defined in Section 3.4, where a “v” indicates the approach satisfies the require-
ment. None of the discussed approaches satisfies all requirements. However, many of
them could be extended so that they satisfy most. Requirements R1 - R3 should be satis-
fied from the start: R1 states the approach should be language-independent. Approaches
that are language-dependent are too specific in their solution to be applicable in general.
R2 states the approach should be able to handle heterogeneous models. Approaches that
34
3.5. STATE-OF-THE-ART RESEARCH
focus on homogeneous models cannot be extended so that they are suitable for hetero-
geneous models since their solution is too specific. R3 states that ensuring consistency
should be done through construction. The reason is that our aim is to maintain the models
during runtime. Therefore, it should be possible to check and adapt models after finishing
the development phase. Consistency ensuring through construction makes it impossible
to check consistency afterwards.
Requirements R4 - R7 concern the definition of guidelines. If approaches do not
provide guidelines, it is possible to extend it. Requirements R8 - R13 concern runtime
requirements. None of the discussed approaches is developed for runtime use, but most
of them could be extended for this purpose.
Considering the necessity for satisfying R1 - R3, we conclude that xlinkit [85], Fradet
et al. [52], Bowman et al. [30], Hunter et al. [61], and Viewpoints [51] provide an approach
that might be extendible for our purposes (shaded grey in Table 3.2). However, each of
these approaches lacks some functionality as we will show in the following discussion.
Xlinkit [85] has several restrictions which makes its use in an inter-organizational
cooperation setting less suitable. Particularly, xlinkit requires a complete translation of the
considered models into XML format. Especially since we aspire a language-independent
approach, it is not feasible to provide a general approach for this translation. Furthermore,
their method requires specification of consistency rules in a restricted form of first order
logic. This limits the expressibility of consistency rules too much for our purpose.
Fradet et al. [52] rely on a complete translation of each viewpoint model into an un-
interpreted graph. Also consistency constraints are represented as graphs. Consistency
checking is done on graphs. As the authors recognize themselves, such an approach is too
cumbersome when considering large, complex, and semantically rich models. Therefore,
this approach is not suitable for our needs.
Bowman et al. [30] develop and approach for ODP consistency checking, which is -
strictly speaking - not language-independent. However, this approach appears to be appli-
cable to other languages as well. Consistency requirements are modelled for each relation
between viewpoints separately, which is, in our opinion, a smart approach. However, it
relies on a universal language into which all viewpoints are completely translated. This
translation is done through unification of viewpoints: one viewpoint is unified with an-
other one, then a third one is added to this unification, etc. The authors provide a universal
language for all ODP specifications. However, for our language-independent approach, it
is not possible to provide one language that allows complete translation of every possible
inter-organizational model. Therefore, this approach is not suitable for our purpose.
Hunter et al. [61] provide an approach that is suitable for multi-model development
where not all inconsistencies need to be resolved immediately. This approach relies
on a full translation of each viewpoint in quasi-logic which is not possible for inter-
organizational cooperations where we aim to preserve necessary details. A quasi-logic
translation does not allow for these details.
The Viewpoints [51] approach supports multi-model development from the develop-
ers perspective where each developer is responsible for his own model. As a result this
approach provides techniques to preserve local consistency. However, we aim at global
35
CHAPTER 3. PROBLEM INVESTIGATION & RELATED WORK
consistency through a consistency management approach rather than leaving consistency
checks at the developers table. Especially since it is difficult for a single developer to
oversee the results of his local choices on the overall system.
In conclusion, there exist many approaches for checking and/or maintaining consis-
tency over many different disciplines. However, none of these approaches is suitable for
our problem. Many solutions have a high level description of the problem and lack sug-
gestions how to solve it. Other solutions are often language specific and are not usable
in other domains. The few approaches which are on the right level of abstraction, lack
either the option to apply them in a heterogeneous context or rely on a common semantic
domain (i.e., an universal language is assumed).
3.6 Summary
In this chapter we discuss specific complexities that arise when ensuring and maintain-
ing consistency for conceptual models on inter-organizational cooperations. We discuss
design time issues (Section 3.1), runtime issues (Section 3.2), and maintenance issues
(Section 3.3). Together with results from Chapter 2 we formulate requirements for our
method (Section 3.4). We conclude our chapter with a review of related work against
solution requirements (Section 3.5). We conclude that there is currently no method avail-
able that satisfies our complete set of requirements, or one that can be extended for this
purpose. Therefore, we define our method in the next chapter.
36
CHAPTER 4
MADE4IC: AN ABSTRACT METHOD FOR MANAGING
MODEL DEPENDENCIES IN
INTER-ORGANIZATIONAL COOPERATIONS
In this chapter we describe our MaDe4IC method (MAnaging DEpendencies for Inter-
organizational Cooperations) for managing models of inter-organizational cooperations.
When companies cooperate, different conceptual models need to be related to each other.
In this thesis we describe a stepwise method for relating such models. Our goal is to
provide a method that can be used to manage rather than solely monitor models. We de-
velop our method using results from our problem investigation (cf. Chapter 3). Typically,
monitoring and managing models is done by gathering information about behavior of dif-
ferent entities in the cooperation. Conclusions on why deviant behavior appears are drawn
by trying to reconstruct relations between the different entities. In this method, we treat
dependencies and relations between entities as the most important part for monitoring
and managing such models. We use dependencies between and within models to analyze
causes for deviant behavior. By considering these dependencies from the beginning, as
opposed to reconstructing them in retrospect, we enable a detailed analysis of problems
and provide useful information on consequences of model changes when trying to regain
consistency. In Section 4.1 we sketch specific characteristics of such models and discuss
what our MaDe4IC method entails. We introduce a running example in Section 4.2. In
the remainder of the chapter we describe each step of the method in detail.
4.1 General approach
4.1.1 Model characteristics
We consider conceptual models that depict cooperation between different companies or
systems. A typical conceptual model consists of concepts representing entities from the
real world. These entities are characterized by some properties which are also repre-
sented by the concepts. Furthermore, relations are used to depict interrelated concepts.
Typically, models of cooperative systems that abstract from any internal behavior contain
CHAPTER 4. MADE4IC: AN ABSTRACT METHOD FOR MANAGING MODEL
DEPENDENCIES IN INTER-ORGANIZATIONAL COOPERATIONS
the following types of concepts and relations:
1. Actors in the cooperation, i.e., parties cooperating together,
2. Exchanged objects (such as information or money) that are used to establish the
relation between actors,
3. Relations between concepts, i.e., between actors, and between exchanged objects
in different models.
We characterize these concepts by properties. For example, a concept representing
a bike might have the property “price”, indicating the specified bike has a certain price.
Furthermore, the nature of the relation might differ. For example, there are causal and
temporal relations indicating some concepts have a causal relationship, while others have
a temporal one.
Which real-life entities and relations in the cooperation are captured by a specific
model depends on the type of model used. Our MaDe4IC method is applicable to co-
operative systems showing these characteristics. It focuses on identifying dependencies
between concepts within and between models. Furthermore, at runtime we construct an
event log model that depicts relations between the different entities. These event logs reg-
ister events occurring between the different actors. Our event log model is related to and
compared with models developed at design time. These dependencies within and between
models form the basis for managing the models by analyzing causes for inconsistencies.
4.1.2 The method
Figure 4.1 gives an overview of our approach. It is divided in five phases. Input is pro-
vided by different conceptual models developed for the inter-organizational cooperation.
As example consider two models with one model describing how each actor benefits from
the cooperation, and another model describing details which messages are exchanged be-
tween the actors to accomplish this.
In the first phase, model analysis, preparations are done for identifying dependencies
within and between models. This phase comprises two steps. In Step 1, each model
is analyzed resulting in model characteristics. The latter are used to homogenize the
models in Step 2 in order to make these (potentially heterogeneous) models comparable.
Although this constitutes an important step for enabling model comparison [15, 105],
this part does not constitute the focus of this thesis. We give some guidelines to tackle
heterogeneity problems in a structured way, but without giving a detailed description on
how to do this.
In the second phase, inter-model analysis, we identify different model relations and
use them to define consistency constraints. This second phase also comprises two steps.
In Step 3 we compare each pair of models, using knowledge about their characteristics
(cf. Step 2) to identify inter-model relations. For example, the existence of a concept in
one model might depend on the existence of a concept in another model. Based on these
relations, for each model pair we define a set of consistency constraints in Step 4. These
38
4.1. GENERAL APPROACH
Model
analysis
Characteristics
Homogenization
Homogeneous
models
Models
Inter-model
relation
detection
Step 3 Intra-model
relation
detection
Step 5
Inter-model
relations Intra-model
relations
Dependency
analysis
Dependency
models
Inter-model
consistency
definition
Inter-model
consistency
constraints
Step 4
Intra-model
consistency
definition
Intra-model
consistency
constraints
Step 6
Log analysis
Event logs
Management
models
If A then B
If C then D If A then B
If C then D
Phase I: Model analysis
Phase II:
Inter-model
analysis
Phase III:
Intra-model
analysis
Phase IV:
Combined
analysis
Phase V:
Management phase
Step 1
Step 2
Step 8
Step 7
Causal
analysis
Step 9
Section 4.4
Section 4.5 Section 4.6
Section 4.7
Section 4.8
Figure 4.1: MaDe4IC: Method for managing dependency relations in inter-organizational
models
39
CHAPTER 4. MADE4IC: AN ABSTRACT METHOD FOR MANAGING MODEL
DEPENDENCIES IN INTER-ORGANIZATIONAL COOPERATIONS
constraints explicate when we consider two models to be consistent with each other. For
example, if the existence of a concept from one model depends on the existence of a
concept from another model, the constraint explicates this dependency relation. Now, the
models are considered inconsistent if the concept exists in one model, but not in the other.
In the third phase, intra-model analysis, we identify in Step 5 for each model the
type of relations used to connect the different concepts. This analysis helps us to explicate
intra-model consistency constraints in Step 6. These constraints describe when a model
is considered to be consistent with the running system.
In the fourth phase, combined analysis, the identified dependency relations and the
consistency constraints are used to perform a combined dependency analysis in Step 7 that
creates the combined dependency models. Together, these models describe the different
dependencies and consistency constraints in a structured way so that they form a proper
base for managing the models. These dependency models are formal models for easy
implementation. Furthermore, they only depict those parts of the original models that
influence the consistency constraints.
The fifth phase, management phase, occurs at runtime of the system and comprises
two steps. Step 8 checks consistency constraints in the log analysis against the event logs
where the dependency models are used to construct feedback for managing the models.
This feedback enables causal analysis for constraint violation as well as prediction of
consequences for solving inconsistencies in Step 9.
The first seven steps are done manually and (possibly) before the system is running.
Steps 8 and 9, the actual management steps, can be automated through implementation,
using the formalization created in Step 7. In the following sections we describe each
phase in detail.
4.2 Running example
We introduce a running example to illustrate the different steps of our MaDe4IC method
(cf. Figure 4.2). In this example, we are interested in the cooperation between a company
selling bikes online, and its customers and providers. The company offers both moun-
tain bikes and city bikes for online purchase. The company buys the bikes in parts from
a provider, then assembles them and finally resells them. Each product is sent to the
customer for a fixed delivery price. In addition, a customer can choose fast delivery, or
delivery on a specific moment like evenings or weekends. For such service an additional
fee is calculated.
We use an easy modelling notation to model our running example in different ways.
For example, we show how to model viewpoints (cf. left part of Figure 4.3) and partial
models (cf. right part of Figure 4.3). With this modelling notation, concepts that con-
tain one or more properties can be modelled. These concepts and properties can have
symmetric or asymmetric relations.
40
4.3. PHASE I: MODEL ANALYSIS
Provider bike parts Bike selling company Online customers
Bike parts Bike
Figure 4.2: Running example: Selling bikes
4.3 Phase I: Model analysis
In the model analysis part of our MaDe4IC method, first of all, each model is analyzed
to identify its specific characteristics (Step 1). Following this, related model pairs are
homogenized (Step 2). As discussed, homogenization is not the core part of this thesis.
However, in consistency checking between different models of one system, it is inevitable
to address this problem. Therefore, we provide a set of guidelines in Step 2 to stepwise
tackle the problem without discussing solutions in detail. In the remainder of this thesis
we assume heterogeneity problems are overcome.
4.3.1 Step 1: Model analysis
Goal: Identify model characteristics of each conceptual model of the cooperation to
enable inter-model and intra-model analysis.
Our method starts with a model analysis phase in which each model is analyzed for
its characteristics (cf. Step 1 in Figure 4.1). This analysis aims at identifying different
conceptual characteristics as discussed in Section 3.1.3. These characteristics are later on
used to enable inter-model as well as intra-model analysis. We analyze each model for
the following characteristics:
(i) Focus: Viewpoint ↔Partial model
(ii) Perspective: Single actor ↔Bird’s eye view
(iii) Property type: Estimation ↔Prescription
(iv) Time frame: Instance-based ↔Period of time
To illustrate Step 1, we consider two examples:
Example 1. When considering the example described in Section 4.2 a possible choice
for modelling this scenario is to develop two viewpoint models. Assume model A
describes exchanges that have some value between customer and company, while
model B describes messages exchanged between actors. The left part of Figure 4.3
depicts these two models.
41
CHAPTER 4. MADE4IC: AN ABSTRACT METHOD FOR MANAGING MODEL
DEPENDENCIES IN INTER-ORGANIZATIONAL COOPERATIONS
Figure 4.3: Dependency relations between viewpoints and partial models
Example 2. Another possible choice for modelling the scenario from Section 4.2 is
to develop two partial models. The right side of Figure 4.3 depicts two such models
where each one describes one entity with different properties. The mountain bike is
the product purchased by the customer, while the bike parts are represented by the
box containing the unassembled mountain bike as purchased by the company.
(i) Focus: A model focusses on a subset of entities as well as relations of the system
(i.e., a partial model), or on the complete system with focus on a specific characteristic
(i.e., a viewpoint model). Typically, models related to the same system have the same
focus type, i.e., all of them either constitute partial models or viewpoints. Example 1 in
the left part of Figure 4.3 depicts our scenario with two viewpoint models, while Example
2 in the right part of the figure depicts two partial models. Identifying the focus type is an
important prerequisite for both intra-model and inter-model analysis (cf. Figure 4.1).
(ii) Perspective: A model can be described from a local perspective of a specific actor
in the cooperation (i.e., single actor perspective) or from a global perspective where the
system is considered as a whole (i.e., a bird’s eye perspective). The models in Figure
4.3 all reflect a single actor perspective, i.e., they are described from the perspective of
the company. Other than with focus, perspectives often differ between models describing
one system. This heterogeneity difference is dealt with rather than homogenized since
the choice in perspective is model-specific and should not be changed. A difference in
perspective might lead to a difference in granularity where a single actor perspective might
describe the situation for one specific actor, while a bird’s eye perspective describes the
situation for a set of actors. In such situation it is important to identify how the part
description from the single actor perspective is related to the whole description of the
bird’s eye perspective. Identifying perspective type is necessary for both inter-model and
intra-model analysis.
(iii) Property type: The type of a property describes whether a property value is an
estimation or prescription. This type can differ within a model where some properties are
42
4.3. PHASE I: MODEL ANALYSIS
estimations, while others are prescriptions. Consider, for example, the left part of Figure
4.3 where the company models with the value viewpoint the value of a bike, and what a
customer pays for the bike. These are prescribed values of the properties which prescribe
behavior. The message viewpoint, however, describes an expected time frame in which
messages are exchanged. There are estimations on exchange times described with the
property ‘time’. The estimations are predictions of reality, rather than prescriptions. It
is important to distinguish the two types for both intra-model and inter-model analysis
where properties of different types are related.
(iv) Time frame: The time frame used in the model should be identified. Especially
whether a model is valid for a specific period of time or whether it is an instance-based
model. For example, a model might describe behavior for the coming half year (period
of time) or describe behavior for each invocation separately (instance-based). This in-
formation is needed to homogenize the models for the inter-model analysis (cf. Figure
4.1).
The result of Step 1 is the following:
•Each model is characterized by its focus,perspective, and time frame.
•Each property in the model is characterized by its property type.
4.3.2 Step 2: Homogenization
Goal: Identify heterogeneity between model pairs using model characteristics identi-
fied in Step 1. Homogenize differences between model pairs if possible.
Wehomogenize the different models to enable their comparison (cf. Step 2 in Figure
4.1). For homogenization we need to overcome differences between the models. For
this, we address syntactic, semantic and pragmatic heterogeneity (cf. Chapter 3.1) where
certain heterogeneity problems are dealt with in later step, while others are homogenized
in Step 2:
•syntactic: deal with in later steps
•semantic
–coreferences: homogenize in the current step
–homographs: homogenize in the current step
•pragmatic
–perspective: deal with in later steps
–focus: deal with in later steps
–granularity: homogenize in current step
–time frame: homogenize in current step
43
CHAPTER 4. MADE4IC: AN ABSTRACT METHOD FOR MANAGING MODEL
DEPENDENCIES IN INTER-ORGANIZATIONAL COOPERATIONS
–estimation and prescription: deal with in later steps
It is not necessary to solve all heterogeneity problems through homogenization since
this might cause loss of information. For example, syntactic heterogeneity is inherently
present since models are simply described using different languages. The key here is to
identify syntactic commonalities and differences between the modelling languages. Ex-
plicating the differences and commonalities between concepts,relations, and properties
of two models suffices.
Example. The models from Figure 4.3 are described in the same language, i.e.,
they use the same constructs for concepts, relations, and properties. There are no
syntactic differences.
Furthermore, semantic heterogeneity must be addressed, especially through identify-
ing and solving coreferences and homographs. Recall that coreferences are semantically
different concepts in two models referring to the same entity in the system, and homo-
graphs are semantically equal concepts in two models referring to different entities in the
system.
Example. The value viewpoint model A in Figure 4.3 describes a concept bike,
while the partial model in the same figure models a concept mountain bike. Although
the concepts differ semantically, they refer to the same real-life entity, i.e., they are
coreferences.
This needs to be identified and resolved by choosing one semantics to describe the
entity. Also when two semantically equal concepts in different models refer to differ-
ent entities (i.e., homographs) one concept should be renamed. As discussed in Section
3.1.2, this is a broad research area and a detailed description on how to handle semantic
heterogeneity is out of scope for this thesis.
In addition, some pragmatic heterogeneities can be homogenized in the current step,
while others are simply recognized here and dealt with when comparing the models in
later steps. Dealing with heterogeneity between models later means it becomes then more
difficult to find overlap or relations between them since the models are still heterogeneous.
However, by identifying where the models are different in the current step, rather than ho-
mogenizing them, relating the models in later steps becomes easier. As discussed before,
foci, perspectives, and property type differences are used to ease identifying relations in
later steps, rather than being homogenized in Step 2. Concerning pragmatic homogeniza-
tion, only time frame differences and granularity differences are homogenized.
Atime frame difference between two models needs to be resolved before the models
can be compared in the following steps. Changing the time frame of a model such that
it fits the time frame of another model is not a straightforward process. It involves dis-
cussions with all involved actors to come to an agreement on how to handle the changes.
Generally speaking, there are two approaches that can be followed to homogenize time
frames: either a time frame is shortened or it is lengthened. Both approaches have their
own hurdles that need to be overcome.
44
4.3. PHASE I: MODEL ANALYSIS
Example. The Value viewpoint model A from Figure 4.3 describes the monetary
relation between bikes the company sells and money the company receives for this.
The model might be valid for a period of one year, i.e., there is a time frame of one
year. The related Message viewpoint model B, however, describes necessary message
exchanges between partners per bike sale, i.e., the time frame is instance-based. This
time frame difference is resolved by shortening the time frame of the Value viewpoint
model A from a period of one year to an instance-based model.
When shortening the time frame, challenges arise with agreed upon average values
and with indivisible exchanges. For example, if a contract specifies an average value to
accomplish over twelve months, this average value cannot be assumed to hold in the first
six months only. This especially cannot be assumed if values differ, for example, due to
seasonal behavior. Furthermore, if there are exchanges between actors that only occur
once during a period, shortening this period implies dividing a single exchange which
is not always possible. For example, if the company expects to sell one bike per year,
reducing a model describing this year to a model with a time frame of half a year will not
be possible since splitting the sale of one bike into two parts is not possible.
When extending a time frame, in turn, the biggest challenge is to estimate content of
future contracts and models. For example, if a contract is specified for the coming year
and we need to extend the model for the coming two years, either all contracts need to be
extended, or estimations on future contracts become necessary. Changing a time frame
is done per model pair since it is desirable to keep the comparison between models as
close to their original time frame as possible. Therefore, the changes typically come with
estimations of behavior.
The second pragmatic difference between models to be homogenized in this step con-
stitutes the granularity difference between the models. In order to check consistency
between two models they need to describe the system on the same level of granularity.
Coarsening is typically used to overcome granularity differences as described in Chapter
3.1.3. Whether abstraction or generalization techniques are used needs to be decided by
the developer and will differ per model. Coarsening is done per model pair since it is im-
portant to consider models on the most fine-grained level as possible because coarsening
also leads to possible inconsistencies in the coarsened parts of the models.
The result of Step 2 is the following:
•All models are semantically homogeneous,
•Each model pair is time frame homogeneous, and
•Each model pair has the same level of granularity.
45
CHAPTER 4. MADE4IC: AN ABSTRACT METHOD FOR MANAGING MODEL
DEPENDENCIES IN INTER-ORGANIZATIONAL COOPERATIONS
4.4 Phase II: Inter-model analysis
The goal of inter-model analysis is to identify dependencies between different models
describing the same system, and to use these dependencies for explicating inter-model
consistency constraints. These constraints are then checked and ensured during the man-
agement phase (cf. Figure 4.1). We first identify inter-model relations between the ho-
mogenized models (Step 3). Then we define inter-model consistency constraints based on
identified relations (Step 4).
4.4.1 Step 3: Inter-model relation detection
Goal: Identify inter-model relations for each model pair. More specifically, we iden-
tify dependencies between models, concepts, and properties.
In Step 2 models are prepared per pair for comparison. The goal of Step 3 is to expli-
cate inter-model relations. When considering partial models, models describing different
system parts are interconnected. This interconnection needs to be identified. For example,
if one partial model describes interactions on the customer side and another one describes
the interactions on the provider side, these two models need to be interconnected before
implementation. When considering viewpoint models overlapping parts between models
(i.e., where two models describe the same system) need to be identified. For example, if
one viewpoint model describes which monetary actions are expected in a cooperation and
another one describes the order in which messages are exchanged between the actors in
the cooperation, the monetary actions and messages that refer to the same real-life entity
need to be related. These inter-model relations are used in Step 4 to formulate consistency
constraints.
The term relationship has a broad meaning. Therefore, we start with explicating which
types of relations are distinguished in this step. The goal is to ensure consistency between
models which is accomplished by explicitly identifying those parts of the models that
influence each other. We consider any type of dependency relation between concepts.
This dependency can be strong as, for example, in a causal relation where one concept
causes another one to occur. However, also less strong dependencies are considered. For
example, in a temporal dependency one concept always occurs before another one without
being its cause for occurrence.
Further, relations can be symmetric:
Example. In Figure 4.3, payment of a bike (Value viewpoint model) and its deliv-
ery (Message viewpoint model) have a symmetric relation since there is no payment
without delivery and no delivery without payment.
Relations can be asymmetric as well. For example, regarding payment of a bike and
its bill, the existence of the payment depends on the existence of a bill, whereas the bill
can also exist without the existence of a payment.
46
4.4. PHASE II: INTER-MODEL ANALYSIS
We distinguish relations between concepts and those between properties. A depen-
dency relation between concepts is referred to as existence dependency, while a depen-
dency relation between properties is referred to as property dependency.
Existence and property dependencies. An existence dependency between concepts in-
dicates that the existence of these concepts depends on each other.
Example. Considering our running example (cf. Section 4.2), the existence of a
concept referring to the payment of a mountain bike by a customer depends on the
existence of a concept referring to the actual bill created by the company stating the
total cost of the purchase. In other words, without a bill of the company the customer
will not pay.
Aproperty dependency indicates the value of one property depends on the value of
the other one:
Example. The amount of money (represented as property value of concept mountain
bike, cf. Figure 4.3) paid by the customer for a bike depends on the amount of money
(represented as property value of concept bike parts) paid by the company to its
suppliers for the bike parts. Here, the value property of one concept depends on
the one of another concept.
If properties of two concepts are dependent on each other, the concepts themselves
have an existence dependency as well:
Example. Since the properties of concepts mountain bike and bike parts depend on
each other (cf. Figure 4.3), the two concepts are existence dependent on each other.
The existence of concept mountain bike depends on the existence of concept bike
parts since there exists no bike if there are no bike parts.
In other words, if two values are dependent on each other the existence of concepts
containing these values depends on each other.
Symmetric and asymmetric dependencies. A second characteristic of dependency is
its direction. A dependency can be asymmetric where one concept depends on one or
more other concepts (i.e., 1-to-n relation). To illustrate asymmetric dependencies, we use
an additional model constructed from our running example:
Example. To model how the costs of purchasing a bike from the company are divided,
a cost dependency model is developed. The left part of Figure 4.4 depicts that pur-
chase cost depends on the product that is purchased, the delivery cost, and additional
service costs for fast or weekend delivery. The total cost to be paid by the customer
for a bike depends on product cost (i.e., the bike), delivery cost, and possibly service
cost for fast or special delivery. This is an asymmetric dependency relation.
47
CHAPTER 4. MADE4IC: AN ABSTRACT METHOD FOR MANAGING MODEL
DEPENDENCIES IN INTER-ORGANIZATIONAL COOPERATIONS
Example 3:
1-to-n, asymmetric
dependency
Example 4:
n-ary, symmetric
dependency
purchase
cost
product delivery service delivery payment
concept
asymmetric
dependency
symmetric
dependency
Figure 4.4: Example: Asymmetric and symmetric dependency relations
Alternatively, a dependency relation may be symmetric if concepts depend on each
other (i.e., n-ary relation). To illustrate this dependency, we use an additional model
constructed from our running example (cf. Section 4.2):
Example. To model a dependency between delivering the bike by the company to
the customer and payment of the costs by the customer, another dependency model is
developed in the right part of Figure 4.4. Delivery of the bike depends on payment
of the cost, and vice versa. However, if it is not specified whether payment occurs
before or after delivery, the payment depends on the delivery as well.
Both existence and property dependencies can be symmetric as well as asymmetric.
In summary, we distinguish the following four types of dependency relations:
•Asymmetric existence dependency, where the existence of a concept depends on
the existence of one or several other concepts,
•Asymmetric property dependency, where the property value depends on one or
many other property values,
•Symmetric existence dependency, where the existence of concepts depend on each
other,
•Symmetric property dependency, where property values depend on each other.
How to identify inter-model relations is explained next for viewpoint and partial mod-
els. Corresponding inter-model relations depict for viewpoint models overlapping parts,
while for partial models they depict connecting parts.
Viewpoints. When identifying relations between two viewpoint models, the goal is to
identify their overlap. We adopt the definition of overlap as given by Engels et al. [47]:
“Overlap is defined as two specifications which are not independent since
they describe common aspects.”
48
4.4. PHASE II: INTER-MODEL ANALYSIS
Our aim is to find these common aspects and to identify the type of relation they have.
In conceptual modelling the common aspects are concepts with potentially different prop-
erties referring to the same real-life entity. Preprocessing models in the homogenization
phase (Step 2) eases identification of concepts referring to the same entity. Identifying the
type of relation between these commonalities is done by hand:
Example. The example in the left part of Figure 4.3 depicts a Value viewpoint model
as well as a Message viewpoint model. Furthermore, it depicts the dependencies
between the two models. In our example, we assume the model engineers refer to the
bike sold to the customer with both concept bike in model A and concept delivery in
model B. Furthermore, they refer to the money paid by the customer to the company
with both concepts money in model A and payment in model B. In both cases the
concepts refer to the same entity in the real world, and in both cases existence of
one concept assumes existence of the other. For example, when a bike is delivered
(Message viewpoint model), it is also paid for (Value viewpoint model). Therefore,
the concepts have a symmetric existence dependency.
Partial models. When identifying relations between partial models, the goal is to iden-
tify relations between concepts, referring to different real-life entities, and between the
same properties in different concepts. This can be a more challenging task than identify-
ing overlap in viewpoints since there are no commonalities to observe because each entity
is modelled in only one model:
Example. In the right part of Figure 4.3 one partial model depicts the mountain bike
and the other one the bike parts. The two models refer to different entities, but there
exist dependencies between the models. For example, the value of the bike depends
on the value of its parts. Identifying these dependencies constitutes a challenge since
there is no overlap between the models.
Usually, there exists some (implicit) model that links the partial models. For example,
when a complex cooperation between different systems is developed, there exists a com-
mon model that explains which partial model is connected to which other one and what
this connection looks like. However, the challenge is that these are high level connections,
describing the relation on model level rather than on concept level:
Example. In the right part of Figure 4.3 the two partial models are related. There
exists a common model that the mountain bike depends on its parts (i.e., a common
model describing high level connections). The challenge, however, is to find the exact
relations between these two models on a concept level. For example, what is the exact
relation between delivery time of the bike parts and possible delivery time of the bike
itself (i.e., identify the relations on a concept level).
The approach taken in our MaDe4IC method is to identify different properties that are
modelled for each real-life entity in a concept. This way, property dependencies are iden-
tified between the same properties in different, but related concepts. In partial models each
49
CHAPTER 4. MADE4IC: AN ABSTRACT METHOD FOR MANAGING MODEL
DEPENDENCIES IN INTER-ORGANIZATIONAL COOPERATIONS
real-life entity is represented in one model as one concept with a set of properties. For
example, a concept in a partial model might contain information on its monetary value,
its size, and its validity. The concepts in related models are related through identifying
equal properties. For example, the monetary value of one concept might depend on the
monetary value of other concepts, while their physical size is unrelated:
Example. In the right part of Figure 4.3 a schematic representation of identifying
these relations is represented. The two partial models each describe one entity with
different properties. The value of the mountain bike depends on the value of its parts.
Also the possible delivery time of the bike depends on the delivery time of the parts.
This asymmetric property dependency relation is depicted.
The result of this step is the following:
•Identification of inter-model dependency relations between concepts and prop-
erties,
•Inter-model relations are categorized as follows (i) symmetric and asymmetric,
and (ii) property and existence dependencies.
4.4.2 Step 4: Inter-model consistency constraints
Goal: Identify inter-model consistency constraints for each model pair. More specifi-
cally, we use the identified dependency relations from Step 3 to formulate constraints
for each relation.
As discussed in Section 2.2, we consider two models being consistent if they have no
contradictions. Since contradictions only occur in related models, they only emerge in
inter-dependent model parts. In Step 3 we identify these inter-model dependencies. In
Step 4 we now use them to formulate consistency constraints. These constraints are di-
vided into different categories, in analogy to the different dependency relations introduced
in Step 3. For each identified dependency, we formulate a consistency constraint. Each
dependency constraint is formulated according to the related dependency type:
•If concept xis asymmetric existence dependent on set Yof one or more concepts,
the constraint states: If xexists then Yexists.
•If concepts in set Xof two or more concepts are symmetric existence dependent
on each other, the corresponding constraint states: If x∈Xexists, all concepts in X
exist.
We illustrate formulating consistency constraints for symmetric existence dependen-
cies by means of an example:
50
4.4. PHASE II: INTER-MODEL ANALYSIS
Example. In the left part of Figure 4.3 the two viewpoint models have a symmetric
existence dependency relation as discussed in Step 3. These relations are translated
into consistency constraints. For example, concepts bike of Model A and delivery of
Model B are symmetric existence dependent. The corresponding constraint states: If
concept bike exists, concept delivery exists, and vice versa. This constraint depicts
that if at runtime the bike gets delivered it also is paid for, and vice versa. If this is
not the case, the constraint is violated.
In case of asymmetric and symmetric property dependencies there exists a relation
between property values. The exact relation between the values is model-dependent. For
example, property value of xmight be twice as big as related property value of y. The gen-
eral format for defining consistency constraints for asymmetric and symmetric property
dependency is as follows:
•If concept xis asymmetric property dependent on set Yof one or more concepts,
and zis the predicate describing this relation, the corresponding constraint states:
Property value of xrelates to property values of Yaccording to predicate z.
•If concepts in set Xof two or more concepts are symmetric property dependent
on each other, and zis the predicate describing this relation, the corresponding
constraint states: For each x∈Xit holds that property value of xrelates to all other
concepts in Xaccording to predicate z.
We illustrate formulating consistency constraints for asymmetric property dependen-
cies by means of an example:
Example. In the right part of Figure 4.3 the two partial models have asymmetric
property dependency relations as discussed in Step 3. Assume that the relation be-
tween value property of Mountain bike and value property of Bike parts states the
value property of Mountain bike is always larger than the value property of Bike
parts. Then, this relation is translated into the following consistency constraint: Con-
cept Mountain bike is asymmetric property dependent on concept Bike parts, where
the property value of Mountain bike is larger than the property value of Bike parts
(i.e., this is the predicate). The corresponding constraint states: The property value
of Mountain bike is larger than the property value of Bike parts. This constraint
depicts at runtime the value of the bike is larger than the value of its parts. If this is
not the case then the constraint is violated.
Often it is possible to formulate generalized consistency constraints where the con-
straints are defined over a set of inter-model dependencies. Since every identified depen-
dency relation results in a consistency constraint, the number of constraints becomes very
large. Therefore, it is more convenient to explicate one general consistency constraint that
captures a set of similar single consistency constraints.
51
CHAPTER 4. MADE4IC: AN ABSTRACT METHOD FOR MANAGING MODEL
DEPENDENCIES IN INTER-ORGANIZATIONAL COOPERATIONS
Example. For example, if hundreds of payments in one model are existence de-
pendent on a bill in another model, each of these dependency relations results in
a separate constraint stating “If payment A exists, also bill B exists”. However, a
single constraint stating: “If a payment with characteristic Y exists, also a bill with
characteristic Z exists”, would generalize over this large space of constraints.
This generalization process can be compared to the one used to solve granularity dif-
ferences between models as discussed in Step 2. Generalization is possible under specific
circumstances. Furthermore, it is applicable in both viewpoint models and partial mod-
els. For both types of models it holds that generalization is only possible over related
combinations with the same type of dependency relation and, therefore, over consistency
constraints of the same type. For example, it is not possible to define a general consistency
constraint for two sets of related concepts where one set has an asymmetric existence re-
lation and the other one a symmetric existence relation. Generalization constraints differ
for viewpoint models and partial models. Therefore, we discuss them separately in the
following paragraphs.
Viewpoint models. In viewpoint models it often occurs that a set of concepts in one
model is related to concepts in another model. Currently, each relation between the two
models has a separate constraint. However, it is often possible to create one general
constraint that describes the complete set of constraints:
Example. Consider the left part of Figure 4.3 where two symmetric existence depen-
dency relations are depicted. Figure 4.5 shows exactly these two relations. The value
viewpoint model describes which products are transferred to the actors. The message
viewpoint model, in turn, specifies which messages are exchanged between the actors.
If there is a message indicating the bike is delivered or a payment is done (message
viewpoint), it is concluded the bike or payment is received (value viewpoint), re-
spectively. If the bike or money has exchanged hands (value viewpoint), it further is
concluded there must be a message stating the bike is delivered or the money is paid
(message viewpoint). Therefore, existence of a good transfer (e.g. a bike or money)
and existence of a message exchange (e.g. a delivery message or payment message)
depend on each other, i.e., they have a symmetric dependency. Without any gener-
alization over constraints, there are now two consistency constraints describing the
relation between the value and message viewpoint model. One states that if the bike
is transferred also a message confirming the bike delivery exists, and vice versa. The
second constraint states that if money for the bike is transferred, a message confirm-
ing the bike payment exists, and vice versa.
We construct a general consistency constraint that covers both single constraints by
stating something in general about the relation between the value viewpoint model
and the message viewpoint model. The general consistency constraint states, for
example: “If a valuable product is handed over, a message confirming this exists,
and vice versa”.
52
4.4. PHASE II: INTER-MODEL ANALYSIS
Value
viewpoint
Message
viewpoint
value
value
time time
bike money
delivery payment
generalization
value
time
product
message
Figure 4.5: Possible generalization over symmetric consistency constraints
Generalization in viewpoint models is possible if there are several consistency con-
straints between two models that are based on the same type of relation (e.g. symmetric
existence dependency). If generalization of property dependency constraints occurs, the
properties in the different constraints is the same. For example, if one constraint describes
a dependency between two time frames, while another one describes a dependency be-
tween monetary values, it is not possible to generalize over these two constraints.
Main advantage of a general consistency constraint between two models is the pos-
sibility to check whether they describe the same cooperation. The constraint typically
describes the nature of the models. In this case, we state that every concept that repre-
sents some valuable transfer in the value viewpoint has a related concept in the message
viewpoint describing the message transfer:
Example. In a value and message viewpoint, several entities in the cooperation need
to be modelled in both viewpoints. For example, in the left part of Figure 4.3, money
paid for a bike is modelled as valuable transfer between actors in the first viewpoint
and as message transfer between two actors in the second viewpoint. The other
way around does not hold since not every concept describing messages transferred
between actors has a monetary value.
Therefore, we state that for each message transfer in the message viewpoint contain-
ing some value there is a concept representing this value in the value viewpoint model.
With this consistency constraint we check whether all necessary concepts are modelled or
whether a model is incomplete.
Aside from checking whether all concepts are present, it is important for each business
transaction to check whether both models describe the same set of transfers. For example,
if both viewpoints model entities “bike” and “money” for the bike, it is important that no
viewpoint model assumes two bike transfers occur for one money transfer, while the other
viewpoint assumes one bike transfer occurs for a money transfer. Therefore, an additional
general consistency constraint is formulated describing that for each business transaction
modelled in the viewpoint models, the concepts should occur in the same setting.
53
CHAPTER 4. MADE4IC: AN ABSTRACT METHOD FOR MANAGING MODEL
DEPENDENCIES IN INTER-ORGANIZATIONAL COOPERATIONS
customer
payment
delivery
cost
special
cost product
cost
Partial models
value
value value value
customer
payment
delivery
cost
special
cost product
cost
Partial models
value
value value value
customer
payment
value
customer
payment
value
generalization
Figure 4.6: Possible generalization over asymmetric consistency constraints
Partial models. In partial models we often observe the property values of a set of con-
cepts in different models are dependent on each other:
Example. In the left part of Figure 4.6 the concept customer payment has three
dependencies: money paid by the customer depends on special costs, but also on
product costs and delivery costs. Each property dependency relation has a sepa-
rate constraint clarifying how customer payment depends on the different costs. For
example, one constraint might state: “The amount of money paid by the customer
contains special costs”.
However, it is possible to construct one general constraint that describes the three
separate ones:
Example. The right part of Figure 4.6 depicts that customer payment and its three
relations are interconnected. Now, the general constraint states: “The amount of
money paid by the customer is at least the sum of special costs, product costs, and
delivery costs.”
In general, we state that constructing a generalization of constraints in partial models
is possible if (i) the dependency relations described by the constraints are interconnected,
and (ii) they connect the same type of property. For asymmetric relations it should be
possible to form a tree out of the dependency relations and for symmetric relations it
should be possible to create an undirected graph from the dependency relations.
In both scenarios analyzed in this thesis (i.e., in the viewpoint model scenario in Chap-
ter 5 and the partial model scenario in Chapter 7) we show in detail how to generalize sets
of consistency constraints.
Result of Step 4 are as follows:
•Identification of consistency constraints for both symmetric and asymmetric
dependencies, and property and existence dependencies, and
•Illustration of generalization of consistency constraints.
54
4.5. PHASE III: INTRA-MODEL ANALYSIS
4.5 Phase III: Intra-model analysis
Intra-model analysis identifies dependencies between different concepts within one model
(Step 5). Furthermore, we define intra-model consistency constraints based on these rela-
tions (Step 6).
4.5.1 Step 5: Intra-model relation detection
Goal: Identify intra-model relations for each model. More specifically, we identify
dependencies between concepts and properties.
For detecting intra-model relations we use the original models and not the homoge-
nized ones since we want to preserve as much original data as possible. Although concep-
tual models have in common that they describe relations between concepts and properties,
the type of relation used differs over different models. In order to get a complete view on
dependencies between concepts and properties over different models, it is important to
analyze the type of relation used within each model. Therefore, we explicate the relation
type used in the language for depicting relations between concepts and properties within
a single model. We use the same distinction as discussed in Step 3. However, here de-
pendencies between concepts and properties are detected within one model as opposed
to inter-model relations in Step 3. More than one type of relationship can be used in a
model.
In viewpoint models these dependency relations typically exist between concepts and
properties referring to different entities, but describing the same property. For example, in
the left part of Figure 4.3, concepts bike and money both have a value, while they describe
different entities that depend on each other.
In partial models these dependency relations typically exist between different proper-
ties referring to the same entity. For example, in the right part of Figure 4.3 the concept
mountain bike contains a property value that depends on the property value of delivery
time, both properties refer to the same real-life mountain bike entity.
The results of this step are the following:
•Identification of intra-model dependency relations between concepts and prop-
erties,
•Dependency relations are categorized in (i) symmetric and asymmetric, and (ii)
in property and existence dependencies.
4.5.2 Step 6: Intra-model consistency constraints
Goal: Identify intra-model consistency constraints for each model. More specifi-
cally, we use the intra-model dependency relations identified in Step 5 to formulate
constraints for each relation.
55
CHAPTER 4. MADE4IC: AN ABSTRACT METHOD FOR MANAGING MODEL
DEPENDENCIES IN INTER-ORGANIZATIONAL COOPERATIONS
Analogously to defining inter-model consistency constraints in Step 4, we define intra-
model consistency constraints in Step 6. Note that these constraints still assume the mod-
els are built properly, i.e., that the models are well-formed. For example, if a modelling
language prescribes every activity is followed by an arc, we assume this is the case. Intra-
model constraints depict constraints on concepts, properties, and their relations within the
model, not on the language used to describe the model. For example, there is no con-
straint stating that concepts can only be connected through a specific relation since this is
a language constraint. However, there exist intra-model constraints stating that a specific
concept shall be present if another one occurs. For example, if a payment is done, a bike
needs to be shipped because this is a model-specific constraint (i.e., a specific constraint
for our example).
Dependency relations identified between the different concepts in Step 5 are used
to define the constraints. The same structure for building the constraints as in Step 4
is applied. The difference is that constraints are now defined within a model, and not
between models.
In addition to consistency constraints, which are defined based on dependencies be-
tween concepts, the existence of the concepts itself, with or without a specific property
value, is defined here. For example, if a concept represents money transfer from cus-
tomer to company, this concept should also occur in the implementation, regardless of
dependencies with other concepts. The general form of such a constraint is as follows:
•Let xbe a concept with property yin a model. The corresponding consistency
constraint states: xexists with property y.
For example, if concept money transfer with property value 100 euro exists in a model,
the constraint states this concept with property value needs to exist in the implementation.
Often it is possible to generalize over different consistency constraints as it is done
for inter-model consistency constraints in Step 4. However, the approach for generaliz-
ing intra-model consistency constraints differs from the one used in Step 4. The same
advantage for generalization of inter-model consistency constraints holds for intra-model
consistency constraints. Namely, by generalizing over a set of constraints, the number
of constraints to be checked reduces significantly, increasing applicability of our method.
Next, we discuss for both viewpoint models and partial models which consistency con-
straints are generalized and how this is accomplished.
Viewpoint models. In Step 5 intra-model dependencies are identified. In this step, each
of them is used to formulate a consistency constraint. As a result there are many similar
consistency constraints. To illustrate generalization in viewpoint models, we consider an
example:
56
4.5. PHASE III: INTRA-MODEL ANALYSIS
Partial model:
bike purchase
customer
payment
delivery
cost
special
cost bike
parts
Viewpoint model:
value
value
value value value
# customers
price
model
bike
Figure 4.7: Possible generalization over intra-model consistency constraints
Example. The left part of Figure 4.7 depicts a viewpoint model that describes mon-
etary values of different entities of our cooperation. For example, the bike parts have
a certain monetary value and delivery costs are paid by the company to the delivery
service. The properties of the concepts (i.e., monetary values) are dependent on each
other. For example, the total price (i.e., property value) for the customer depends on
how much the bike parts cost.
Each intra-model dependency relation results in a separate constraint. However, it is
possible to generalize over these constraints under certain circumstances.
Generalization is done for constraints that depict the same type of dependency, and
then only over constraints being inter-connected through the different concepts and prop-
erties. This is the same approach as taken for generalization of partial models for inter-
model consistency constraints.
Example. There are three constraints formulated for the value Viewpoint model (cf.
left part of Figure 4.7): 1) costs for the customer depend on special costs, 2) costs
for the customer depend on bike part costs, and 3) costs for the customer depend
on delivery costs. These constraints are generalized into one general constraint that
states: Total costs for the customer depend on the sum of special costs, bike part
costs, and delivery costs.
In general, we state that generalization in viewpoint models is possible if the depen-
dency relations are interconnected and if they connect the same type of property. For
asymmetric relations it should be possible to form a tree out of the dependency relations
(as done in the example) and for symmetric relations it should be possible to create an
undirected graph from the dependency relations.
Partial models. The dependencies in partial models identified in Step 5 typically exist
between properties within one concept that refer to the same entity. To illustrate general-
ization in partial models, we consider the following example:
57
CHAPTER 4. MADE4IC: AN ABSTRACT METHOD FOR MANAGING MODEL
DEPENDENCIES IN INTER-ORGANIZATIONAL COOPERATIONS
Example. The right part of Figure 4.7 depicts a partial model for the concept bike
from our running example. The bike has three properties: expected number of cus-
tomers,price, and model type (e.g. mountain bike). The number of customers de-
pends on the price that needs to be paid for the bike and the price, in turn, depends
on the model type. Each of these dependencies results in a consistency constraint.
Generalization over these constraints is possible. In this case we develop one consis-
tency constraint that captures both dependency relations, i.e., the relations between
number of customers and price, and between price and model type. The separate
constraints state: 1) For a mountain bike (i.e., a specific model) xeuro are paid, and
2) If a customer pays xeuro for a bike, ycustomers will buy one. The general con-
straint now states: For a mountain bike the price is xeuro, and ycustomers buy the
bike.
Generalization within partial models is possible over those constraints that describe
relations between different properties of one concept (i.e., one entity) if these properties
are inter-connected. For asymmetric relations like in our example, it should be possible
to build a tree of the different properties and their relations. For symmetric relations, in
turn, it should be possible to build an undirected graph of the different properties and their
relations.
Joint constraints. Each model is built with a specific purpose. It prescribes (i) which
entities should occur, (ii) which properties they should have, and (iii) in which way they
should manifest in the cooperation. Typically these are model generic constraints where
a model depicts, for example, (i) which transfers occur between actors in one business
transaction, (ii) what the value of certain exchanges between actors is, or (iii) the order
in which entities should occur in a business transaction. Model-specific consistency con-
straints are formulated taking the specific model purpose into account. It is not possible to
formulate a general consistency constraint for this purpose since this is model-dependent.
Generalization is often not necessary for these constraints since they are typically model-
specific and therefore general.
The results of this step are the following:
•Identification of intra-model consistency constraints, and
•Illustration of generalization of consistency constraints.
4.6 Phase IV: Combined analysis
4.6.1 Step 7: Dependency analysis
Goal: Formalization of model parts that are checked for consistency, and formaliza-
tion of the defined intra-model and inter-model consistency constraints. This formal-
ization allows easy implementation for automatic consistency checking.
58
4.6. PHASE IV: COMBINED ANALYSIS
As described in Section 2.3.3, we check consistency between models after their devel-
opment. Checking consistency is done by testing the models with some model checker,
or by finding a translation. Since we not only check consistency between models, but
also between models and running system, we choose to translate the models. Typically,
models are translated into a semantically well-defined formalism, which allows for formal
consistency checking. Either models are completely translated, or only their overlapping
parts are translated. In the inter-model and intra-model analysis phase (Phase II and Phase
III) we identified crucial parts for consistency checking, i.e., we identified their overlap-
ping parts. Therefore, we choose to partially translate the models, i.e., only these parts
that are crucial for consistency checking.
During runtime we check whether both intra-model and inter-model consistency con-
straints (Step 4 and Step 6) hold with regard to the running system. In this method we
check these constraints by translating those model parts that influence consistency into a
language-independent, formal notation. Consistency influencing parts of the models are
identified in the inter-model and intra-model analysis phase where both model relations
and consistency constraints are analyzed. In Step 7 we combine these results and repre-
sent both constraints and essential model elements in a formal model. Formalization of
model parts and consistency constraints allow easy implementation. As explained at the
beginning of this chapter, implementation facilitates automatic checking of the constraints
at runtime in the Management Phase (cf. Steps 8 and 9).
To manage models of inter-organizational cooperations, we monitor several parts of
the models. We monitor:
•concepts with their properties,
•relations between properties, and
•relations between concepts.
We monitor these items by checking consistency constraints as defined in Steps 4 and
6. These constraints depict dependencies between concepts and between properties. We
check whether the constraints hold by comparing running system and models.
To allow automatic monitoring in the following steps, we formalize those parts of
the models that are part of the consistency constraints, and the consistency constraints
themselves so that they can be easily implemented. This formalization of model parts
results in a formal model. We illustrate what is present in the formal models with the
following examples:
59
CHAPTER 4. MADE4IC: AN ABSTRACT METHOD FOR MANAGING MODEL
DEPENDENCIES IN INTER-ORGANIZATIONAL COOPERATIONS
Example. When considering the left part of Figure 4.3, the value viewpoint model
consists of two concepts with a value property that have a symmetric dependency
relation. Both concepts and their constraint (based on the dependency relation) are
included in the formal model. Furthermore, from the message viewpoint model all
concepts have some dependency relation and are, therefore, used in one or more
constraints. As a result, all concepts in this model are part of the formal model.
Also constraints describing dependency relations between concepts in the message
viewpoint model are included in the formal model. This also holds for constraints
describing symmetric relations between bike and delivery, and between money and
payment, respectively.
Example. When considering the right part of Figure 4.3, both concepts mountain
bike and bike parts are included in the formal model since both their properties have
dependency relations. Furthermore, constraints describing the asymmetric property
dependency relations between the two prices and the two delivery dates, respectively,
are also included in the formal model. These are inter-model consistency constraints
for the models. Also the intra-model consistency constraints (i.e., property depen-
dency between price and delivery date of the bike and the bike parts, respectively)
are part of the formal model.
Although many formalizations are possible, in this thesis we describe the use of sets
and graphs to create the formal models. In Scenario 1 (cf. Chapter 5) we show how
to apply sets, while in Scenario 2 (cf. Chapter 7) we show how to apply graphs for
this purpose. However, many other formalizations are possible. The key is to group
representations of concepts that belong to the same business activity. Using sets one
instance is represented as a set, while using graphs one instance is represented as a graph.
Consider the following example:
Example. In the left part of Figure 4.3 concepts bike and money are grouped since
one purchase of a bike entails both the bike and money transfer. Furthermore, also
the concepts order, confirm, send, deliver, and pay are grouped since these messages
together make up one purchase of a bike. Regarding the right part of Figure 4.3, the
value properties and the delivery time properties are grouped.
The results of Step 7 are the following:
•Formalization of model parts that are used in the consistency constraints, and
•Formalization of consistency constraints.
This formalization allows easy implementation as preparation for automatic monitor-
ing of the models at runtime.
60
4.7. PHASE V: MANAGEMENT PHASE
4.7 Phase V: Management phase
In the management phase the aim is to check whether the running system performs as
prescribed in the models. In other words, we check consistency between event logs and
formal models, i.e., the dependency models. To allow for such a comparison between
models and event logs, we analyze event logs and create an event log model that allows
easy comparison in Step 8. The result of this comparison is reflected in the manage-
ment models where inconsistencies are depicted. Furthermore, in Step 9 the management
models allow for causal analysis to find out why certain inconsistencies occur. Using
this analysis, different solutions for handling inconsistencies are identified. However, as
a consequence of applying these solutions new inconsistencies might be introduced. It
is important to identify these consequences because we aim at minimizing the number of
model changes when regaining consistency between models and running system.
4.7.1 Step 8: Log analysis
Goal: Abstract necessary information from the event logs to monitor the models and
their constraints.
Although mining data from event logs does not constitute the focus of this thesis, we
first explain how to abstract necessary information from them. Secondly, we explain how
to compare this information with the dependency models constructed in Step 7.
In inter-organizational models conceptual structures are present that are not visible in
the event logs. To check them for evidence of consistency between models and system
behavior, we need to add this structural information to the event logs. Therefore, we
suggest to reconstruct relations between the different event log entries. For example, for
each entry in the event logs we need to recognize to which instance it belongs, i.e., to
which other entries it is related and it depends on. For example, if a payment is done
and afterwards stored as entry in the event log, it becomes necessary to identify for which
service or product this payment is done.
Identifying these relations is a widely known problem for which different solutions
exist: Many approaches aim at deriving this structural information from the event logs
through mining techniques [3], while other approaches add structural information to the
event logs when they are created [67, 96]. In this thesis, we do not describe data mining
or event log structuring in detail. We discuss which information is necessary for our
approach, rather than how to acquire it.
We illustrate this with a technique where identifiers are used to reconstruct model
structures captured by the event logs. Note, we assume that the structure as it is described
in the models is reflected in both implementation and event logs. Without this assumption
a first step is to mine structure from the event logs [3]. Furthermore, we assume identifiers
are added to an event log entry to provide information on its nature. For example, a
contract number can be used to identify to which transaction an entry belongs, log on
and log offmessages can be used to identify separate transactions, and timestamps (e.g.
“Thu, 17 July 2009 09:23:12”) can be used to identify in which order certain events occur.
61
CHAPTER 4. MADE4IC: AN ABSTRACT METHOD FOR MANAGING MODEL
DEPENDENCIES IN INTER-ORGANIZATIONAL COOPERATIONS
For each inter-organizational cooperation it needs to be decided which identifiers can and
need to be used.
Necessary information abstracted from the event logs is structured using sets. Event
log entries belonging to one transaction are grouped into one set. Each entry is repre-
sented as a tuple. Typically, each tuple contains a timestamp, an issuer, a recipient, a
unique name, and some property information. The resulting model contains all property
information necessary for checking the constraints of the formal models. In other words,
it contains all properties as they are present in the formal models (cf. Section 4.6, Step 7).
In general, the event log model is constructed as follows:
1. Identify which property values should be present in the event log model
using the dependency models.
2. Represent each entry in an event log as tuple containing a timestamp,
issuer, recipient, unique name, and all property values.
3. Group tuples belonging to one transaction into sets using identifiers like
log-on and log-offmessages, and contract numbers.
After creating the event log model by abstracting necessary information from the event
logs, we compare the runtime results with the inter-organizational cooperation models
describing the system. The result from this comparison is represented in management
models. When using sets to represent the formal models, consistency constraints are
checked by matching tuples and sets between event log model and formal model. When
using graphs, tuples and sets of the event log model are matched with vertices and edges
of the graphs. Furthermore, additional consistency constraints are matched by checking
occurrences of tuples, properties of tuples, and occurrences of sets in the event log model.
For example, if a consistency constraint states that the presence of a concept (i.e., tuple)
indicates the presence of another one (i.e., tuple), this relation is checked in the different
sets of the event log model.
Example. In our running example (cf. Section 4.2) the company offers two business
transactions: purchasing mountain bikes and purchasing city bikes. At runtime, we
collect information from the event logs to support the business model of the company.
For example, we expect evidence of selling mountain bikes to customers, represented
as sets of events representing the sale. In addition, we expect evidence of selling city
bikes in a similar manner. Furthermore, in order to sell the bikes, the company needs
to purchase its parts before. This constraint is checked during runtime. We expect
evidence to support the constraint that bike parts are purchased before bikes are sold,
represented as events with different timestamps. More specifically, we expect events,
represented as tuples in the event log model, that represent purchasing bike parts
with earlier timestamps compared to events that represent selling bikes.
Violation of consistency constraints is different for existence dependencies and for
property dependencies. When a constraint describing an existence dependency is violated,
this is a violation where the concept does not exist. For example, a bike needs to be paid
62
4.7. PHASE V: MANAGEMENT PHASE
by the customer if he receives the bike. If there is no evidence of payment in the event
log, this is a complete violation of the constraint. If a constraint describing property
dependency is violated, this violation can come in gradations, depending on the scale of
the value of the concept. For example, if the selling price of a bike is twice the amount
paid for the bike parts, the runtime result in the event log model deviates (but does not
completely violate) if the selling price is only one and a half times the amount paid for
the bike parts.
The results of this step are the following:
•A description of information that needs to be abstracted from the event logs for
monitoring the models and their constraints.
4.7.2 Step 9: Causal analysis
Goal: Identification of causes for constraint violations, and identification of conse-
quences of restoring consistency between models and running system.
The monitoring results containing constraint violations need to be presented in an in-
tuitive way. We suggest to represent monitoring results by showing deviations in color
codings. For example, red indicates violation of an existence dependency constraint or vi-
olation of a property dependency constraint, green indicates compliance of the constraint,
while orange indicates a deviation of a property dependency constraint with not more than
10%. The coloring can be done in the original models as well as in the dependency mod-
els. In this way, both arrows (indicating dependencies) and concepts (containing property
values) are colored. The results are management models that show relations between dif-
ferent concepts, whether these relations are violated or not during runtime, and whether
their property values are accomplished.
When the management models are created, it becomes clear which parts of the running
system comply with the models and which parts do not. Ideally, models and running
system are consistent with each other. If there is a violation the analyst can either evolve
the models so that they properly represent the running system, or adapt the running system
so that it properly reflects the agreed upon models. In this thesis we focus on changing
the models so that they reflect the running system, rather than adapting the system itself.
Violations are often related. A constraint violation in one part of the model often
results in violations of other parts of the model. These causal relations are important
to identify for efficient model management since solving a constraint violation of the
source might solve numerous other violations at the same time. The dependency models
created in Step 7 show all dependencies between concepts. Here, dependencies are used
to go through the management model and to identify sources for violations. For this
causal analysis only asymmetric dependencies are used because in those relations it is
clear which concept influenced the other. In symmetric dependencies you might travel to
the end leafs of the problem instead of identifying the source of the violations.
63
CHAPTER 4. MADE4IC: AN ABSTRACT METHOD FOR MANAGING MODEL
DEPENDENCIES IN INTER-ORGANIZATIONAL COOPERATIONS
Example. If there is an existence constraint violation of concept money in the Value
viewpoint model A (cf. left part Figure 4.3) (i.e., there is no evidence that money has
been paid), the symmetric dependency relations the concept has make it difficult to
determine the cause for this violation. For example, the symmetric relation between
concepts bike and money does not indicate whether the money is not paid because
the bike is not delivered, or the other way around. In other words, determining causes
in symmetric relations is difficult.
By identifying causes, it becomes possible to decide which parts of the models to
change to regain consistency. After choosing these parts, it is important to identify what
the consequences of these changes are. For example, when making a product more ex-
pensive to resolve a lack of income, the number of expected customers might decrease,
leading to even less income. Therefore, besides identifying what the causes for violation
are, it is also important to decide which parts to change.
Every element present in the consistency constraints is able to cause an inconsistency
and is, therefore, also able to regain consistency. Often, there are several different ways
to make a change in one of the models to regain consistency. For example, if the bike
parts are at runtime more expensive from that agreed upon in the models, one solution is
to negotiate a lower price for the parts, while another possibility is to change provider and
purchase the bike parts elsewhere. Although both solutions solve the constraint violation,
the first one is less intrusive for the model than the second one, since the second solution
results in deletion of an offered service.
To distinguish intrusive from less intrusive changes, we suggest to divide possible
model changes into different categories. Each constraint violation is now solved by apply-
ing a subset of these categories. Each category has its own consequences for the models.
•Non-observable changes in a model do not influence the formal model, i.e., the
change does not influence the dependency models. As a consequence, these changes
are outside the parts that influence consistency. For example, in the right part of Fig-
ure 4.3 the partial models describe the mountain bike and its parts. If the payment
method changes, this does not affect these models since payments are not captured.
Therefore, this is a non-observable change in that model.
•Observable structural changes in a model are changes where concepts are removed
or added to the model while preserving a well-formed model. These changes influ-
ence existence dependencies since these dependencies rely on the existence of cer-
tain concepts. By removing or adding a concept, its existence changes. However,
property dependencies are also influenced since the non-existence of a concept will
also imply its property value does not exist. For example, if we remove the concept
bike in the left part of Figure 4.3, this is an observable structural change. It affects
the existence dependencies with concept money of the same viewpoint model, and
with concept delivery of the message viewpoint model B.
•Observable non-structural changes are changes where the property value of a con-
cept is affected, or where the way two concepts are related is affected. For example,
64
4.7. PHASE V: MANAGEMENT PHASE
Example 1
Example 2
Product(price) Customer(number)Profit(amount)
Product(price) Material(price)Profit(amount)
Figure 4.8: Consequence analysis for changing models
when changing the order of two concepts, their relation is affected. These changes
do not affect constraints on existence dependencies since such it does not change
the existence of concepts. However, it does affect constraints on property depen-
dencies since it changes property values. For example, if the value property of
concept bike parts in the right part of Figure 4.3 becomes larger, i.e., the bike parts
become more expensive, then this is an observable non-structural change. It affects
also the value property of concept mountain bike since the price of the mountain
bike depends on its parts.
Explicating for each constraint which changes can be used to regain consistency if
necessary is a step towards more efficient and precise model management. By relating
changes to constraints, it is possible to predict the impact of a change, not only on the
violated constraint, but also on other constraints that are related to this particular change.
With this last step we conclude the analysis of the models and event logs. Now, it
is possible to monitor consistency constraints between models and between models and
the running system, it is possible to identify causes for violations with a causal analysis
through the different dependency relations. Based on the causal analysis, violated con-
straints are selected for inconsistency resolution. Now, we describe the last step where
we use the identified possible changes and the dependency relations to predict the conse-
quences of changes made in the models to regain consistency.
Each suggested change in a concept to regain consistency might affect more than the
violated constraint. By considering the dependency models we identify which constraints
are affected when changing a particular concept. An observable structural change affects
both the existence and property dependencies, while an observable non-structural change
only affects related property dependencies. When the affected dependency is symmetric,
the change also affects the related concept. When the affected dependency is asymmetric,
the change only affects the related concept if the related concept depends on the original
concept, not if the original concept depends on the related concept. Consider Figure 4.8
where both situations are depicted:
65
CHAPTER 4. MADE4IC: AN ABSTRACT METHOD FOR MANAGING MODEL
DEPENDENCIES IN INTER-ORGANIZATIONAL COOPERATIONS
Example. Both Example 1 and Example 2 depict (part of) a property dependency
model where the dependency constraint between product price and amount of profit
is violated. In other words, the event logs show that the depicted property relation
between the product and profit does not hold. The model can be changed in several
ways to solve this inconsistency. The amount of profit can be adjusted, the product
price can be adapted, or the ratio between profit and price can be adjusted.
Assume the developer considers changing the product price. Now, the consequences
for the other dependencies are analyzed. In Example 1, product price and number of
customers are dependent on each other. Therefore, if the product price changes, the
number of customers is also affected, just as their dependency relation. In Example 2,
product price depends on the material price it is made of. Now, changing the product
price does affect their relation, but not the material price. The developer now con-
cludes changing the product price in the second example has limited consequences,
while changing the product price in the first example leads to more adjustments.
Especially with large models and many dependencies it is very useful to enable such
an analysis where changes are related to types of dependencies, and analysis is done for
the consequences of such changes in the rest of the models, but also for constraints it
has with other models. The approach aims at using the constraints, dependencies, and
types of changes to show for a chosen adaptation of the model, which parts are affected
by the specific change. As a result the developer is better able to estimate the amount
of effort needed to adapt the models as well as better able to make a choice between the
different change possibilities. In general, the most suitable change is the one having the
least impact on other constraints.
The results of this step are the following:
•We provide a method for causal analysis of the dependency models created in
Step 7. This analysis identifies possible causes for constraint violations.
•Furthermore, we provide a method to predict consequences model changes
have on consistency constraints. This supports the analyst in identifying the
least intrusive adaptation of the model to regain consistency.
4.8 Summary
In this chapter we introduce a stepwise method towards efficient model management of
inter-organizational cooperations. The approach relies on the identification of different
types of dependencies between the different concepts within and between models. Fur-
thermore, we suggest translating relevant model parts into formal models for easy consis-
tency checking. The same approach as used for these formalizations is used for abstract-
ing useful information from event logs into an event log model such that runtime behavior
of the system can be compared with the models describing the system. Furthermore, an
66
4.8. SUMMARY
additional causal analysis, using identified dependencies, allows identifying causes for in-
consistencies between models and running system. As a last option our MaDe4IC method
provides an approach to check the consequences for consistency constraints when changes
are made to a model. In other words, we analyze what the consequences are for other
consistency constraints when trying to resolve an inconsistency. As a whole, this method
presents a stepwise, structured approach into managing these complex constellations in an
effective and efficient way. In the following chapters two scenarios are discussed where
this method is applied.
67
Part III
SCENARIO 1: BUSINESS &
COORDINATION MODELS
CHAPTER 5
MANAGING DEPENDENCY RELATIONS: BUSINESS
AND COORDINATION MODELS
To illustrate the importance of inter-model consistency, we consider two fundamental per-
spectives which are of high relevance for modelling inter-organizational cooperations: the
business and the process perspective [56, 2]. At business level expectations (e.g., agree-
ments on the number of transferred products) between partners are modelled. At process
level coordination of inter-organizational processes is modelled. Both perspectives de-
scribe necessary transfers between partners although focusing on different aspects (finan-
cial versus coordination). Assume, for example, that a payment is captured in the business
model, while it is omitted in the process model. Then the two models are considered to be
inconsistent with each other. If a system implementation is based on these models, pay-
ment will be expected to occur (due to the business model), while the occurrence of this
payment is not prescribed in the implementation (due to the incomplete process model).
In other words, business and process model do not describe the same system. Since the
two models have a different level of abstraction, use different modelling notations, and
have a different purpose, determining consistency constitutes a big challenge. This chap-
ter illustrates how to apply our MaDe4IC method for identifying dependencies between
business and process models [17, 26].
In complex, inter-organizational cooperations where repetitions within business trans-
actions occur, relations between sets as well as between elements in sets need to be
checked. In this case it should be checked whether certain transfers are executed an equal
number of times (e.g., are as many payments done by the customer as services offered by
the company?). Since the goal of this chapter is to illustrate usability of our method to
business and process models we exclude repetitions for the sake of readability. However,
a formalization of consistency constraints including such repetitions can be found in a
technical report extending this chapter [20].
The remainder of this chapter first discusses basics of the modelling techniques, while
introducing our running example in Section 5.1. In the following sections we discuss the
stepwise application of our MaDe4IC method to this running example (cf. Sections 5.2 -
5.10). We conclude this chapter with a discussion of related work on business and process
modelling in Section 5.11.
CHAPTER 5. MANAGING DEPENDENCY RELATIONS: BUSINESS AND
COORDINATION MODELS
5.1 Basics
We first introduce an illustrating business case. It consists of a copier company which
sells and leases copiers to customer companies. When leasing a copier, it is mandatory
to purchase maintenance on a yearly basis. Before implementing the business case, the
copier company wants to evaluate financial consequences (business perspective) as well
as coordination requirements (process perspective). For this purpose, it develops a value
model denoting value exchanges as well as a coordination model describing how the in-
teraction between the two partners is arranged. To validate its models, information on
interactions with partners is gathered from the event log.
5.1.1 Business perspective
The copier company reasons about value transfers to and from companies to estimate fi-
nancial benefits. The value model (cf. Figure 5.1) depicts estimations on who gets what
from whom and for how much in e3-value notation [57].1The e3-value methodology is
developed to support exploration of innovative e-business ideas using a graphical mod-
elling tool [38].
In our running example, actor copier company has a group of customer companies,
and three kinds of value exchanges take place between them (cf. Figure 5.1): money for
leasing a copier (Lease, Copier L), money for maintaining the copier (Service, Mainte-
nance), and money for purchasing a copier (Purchase, Copier P). Interdependent value
transfers (i.e., transfers exchanged in one business transaction) are connected through
dotted and solid lines in Figure 5.1, representing two possible business transactions. One
is highlighted through a thick line representing the customer need for having a copier,
starting at the customer side. Furthermore, value exchanges that belong to one business
transaction are grouped in a grey box. The XOR-split models that customers have a choice
to either lease or purchase the product. The AND-split, in turn, indicates that for every
lease a maintenance contract is purchased.
To obtain financial estimations, several quantifications are done for a specified time
frame. In Figure 5.1 estimations on the number of customers (=36), the number of cus-
tomer needs (=2), and the purchase-lease ratio (33%-67%) are made. These quantifica-
tions result in an estimation on the number of leases and purchases. Together with an
average value of each transfer, this gives an indication on the income for this business
activity in the specified time frame (one year in our case). Although these quantifications
are part of the value model, for the sake of clarification, we represent them in Table 5.1.
5.1.2 Process perspective
Besides financial validation the copier company needs to agree on how to implement the
business. For example, should the customer pay before receiving the copier, or the other
1Other value-based modelling techniques (e.g. REA [76] and Business Modelling Ontology [92]) can be
used as well. We select e3-value in this thesis due to its graphical notation.
72
5.1. BASICS
AND AND
Lease €
Purchase €
Service €
Maintenance
Copier L
Copier P
Customer (=36) Copier
Company AND
ActorGroup of
Actors
x
Value
Transfer
AND-port XOR-port
XOR
XOR XOR
67%
33%
Start Stop
2
Figure 5.1: Example case: Business model (e3-value notation)
Value Transfer Average Value Occurrences
Lease /Copier L1200 e48
Service /Maintenance 700 e48
Purchase /Copier P 7500 e24
Table 5.1: Estimations value model
way around? The coordination model describes which messages are to be exchanged
between partners and in which order this message exchange shall take place. Such an
inter-organizational process model provides the basis for any implementation. We use the
Business Process Modeling Notation (BPMN) [113] to represent the coordination model
(cf. Figure 5.2).2The customer chooses to purchase or lease a copier (cf. the decision
in the figure). As a consequence of this choice, either the set of message exchanges
associated with purchasing or leasing a copier is initiated. Both business transactions
are indicated with a grey box, grouping messages for purchasing or leasing a copier,
respectively (cf. Figure 5.2). The first message is sent by the customer as a request
message to the copier company. The company, in turn, sends back an offer message with
the contract. Finally, the customer pays and afterwards receives the copier. After this, the
process ends.
5.1.3 Event logs
To evaluate the operational system, data on its execution is gathered. The event log of the
Information System (IS) contains such data. Here, we focus on data exchanged between
actors, and disregard any internal data. Furthermore, timestamps show the order in which
data are exchanged. The event log enables traceability of executed processes during co-
operation. Furthermore, it enables checking whether profitability estimates made in the
2Other modelling techniques like Activity Diagrams and Petri Nets are applicable as well. Here we select
BPMN due to its graphical notation.
73
CHAPTER 5. MANAGING DEPENDENCY RELATIONS: BUSINESS AND
COORDINATION MODELS
Copier
Company
Customer
Lease or
Buy?
Request
Lease
Contract
Offer
Contract with
Maintenance
Receive
Contract Pay
Receive
Payment Provide
Copier
Receive
Copier
Lease
request offer service €
+ lease € copier l
Receive
Copier
Pay
Receive
Invoice
Provide
Copier
Receive
Payment
Offer
Copier
Buy
request offer purchase € copier p
Request
Copier
group message
transfers
start
event end
eventintermediate
message
event based
decision
decision
sequence
flow message
flow
activity
Figure 5.2: Example case: Coordination model (BPMN notation)
Figure 5.3: Example case: Event log (XML notation)
value model are realized. As example take Figure 5.3 in which parts of an XML-based
event log (i.e., one business transaction) are shown. It depicts data exchanged between
customer and copier company of payment for leasing a copier. Each message is annotated
with a timestamp, issuer, recipient, and name. A message contains information on the
value of a transfer (cf. Amount in Figure 5.3), the type of the transfer (cf. Good in Fig-
ure 5.3), and a contract number. Messages with the same contract number belong to one
business transaction, while one specific customer might be involved in multiple business
transactions.
Next, we discuss how to apply our MaDe4IC method for managing model dependen-
cies in inter-organizational cooperations (cf. Chapter 4) to this running example.
74
5.2. STEP 1: MODEL ANALYSIS
Value model Coordination model
Focus viewpoint viewpoint
Perspective bird’s eye single actor
Property type estimations &prescriptions
prescriptions
Time frame time period instance
5.2 Step 1: Model analysis
In Step 1 of the method we analyze the models for their characteristics. Please, recall the
different characteristics from Section 4.3:
(i) Focus: Viewpoint ↔Partial model
(ii) Perspective: Single actor ↔Bird’s eye view
(iii) Property type: Estimation ↔Prescription
(iv) Time frame: Instance-based ↔Period of time
Value model. The value model from Figure 5.1 is a viewpoint model. It models the com-
plete cooperation and focusses on one specific aspect, namely, value exchanges between
actors. The value model is developed with a bird’s eye perspective, i.e., it is developed
for all actors, and captures their value exchanges for a specified period of time. The value
model contains both estimations and prescriptions. For example, the ratio between pur-
chased and leased copiers constitutes an estimated value, while the price of a purchased
copier is fixed. The value model is developed for a period of time, in this case for one
year.
Coordination model. The coordination model constitutes a viewpoint model as well.
It models the complete cooperation while focussing on one aspect, namely, message ex-
changes between actors. The coordination model is developed from a single actor per-
spective (the copier company). This means the coordination model depicts the interaction
of the copier company with its customers. However, the coordination model only depicts
one customer that represents the average behavior of a typical customer. All exchanges
between the actors are prescriptions; messages need to be exchanged in the specified or-
der. The coordination model is instance-based. In the year described in the value model,
the coordination model is expected to execute several times.
5.3 Step 2: Homogenization
In Step 2 we homogenize the models on syntactic, semantic, and pragmatic level so they
can be compared.
75
CHAPTER 5. MANAGING DEPENDENCY RELATIONS: BUSINESS AND
COORDINATION MODELS
Syntactic homogenization. As discussed in Section 4.3, it is not possible to homoge-
nize syntactic differences. However, respective differences and correspondences must be
identified to enable comparison.
•Actor versus Swim lane. Our value model uses actors and groups of actors to depict
partners in the cooperation. This corresponds to swim lanes in the coordination
model.
•XOR versus Decision. The value model uses XOR-splits to indicate choices in busi-
ness transactions. In other words, either the one or the other business transaction is
chosen. This corresponds to the decision (i.e., lease or buy a copier) represented in
the coordination model, where also a choice is made between two business trans-
actions.
•AND. The AND-split in the value model does not have a matching concept in the
coordination model. It indicates grouping of value transfers that are exchanged
in one business transaction between actors. In the given coordination model this
relation is implicitly modelled in the sequence of messages that connects different
messages being exchanged in one business transaction.
•Value transfer versus Message transfer. A value transfer in the value model rep-
resents the transfer of a valuable object from one partner to the other. Each value
transfer corresponds to one or more message transfers in the coordination model
since each value transfer also results in a message transfer in the given scenario.
For example, the physical transfer of money for leasing a copier in the value model
(cf. lease ein Figure 5.1), results in a message transfer confirming this payment
(cf. lease ein Figure 5.2). However, there might be message transfers that do
not have any economical value and, therefore, do not have a correspondence in the
value model.
Semantic homogenization. The models in this chapter are built in such a way that they
are semantically homogeneous by construction. For the interested reader, there exists an
approach, designed by Zlatev et al. [120], to manage semantical differences between value
and coordination models explicitly; Zlatev et al. also discusses granularity differences.
Pragmatic homogenization. Concerning pragmatic homogenization we consider five
different aspects. Some of them are homogenized, while others are identified in the mod-
els (cf. Section 4.3, Step 2).
•Focus. The focus of both value and coordination model is a viewpoint one. There-
fore, the models are homogeneous concerning their focus.
•Perspective. The perspectives of the models are different in the given case. The
value model has a bird’s eye perspective, while the coordination model has a single
actor perspective. This is a difference which we cannot homogenize since it is a
76
5.4. STEP 3: INTER-MODEL RELATION DETECTION
model characteristic. Therefore, we identify the difference in this step and deal with
the heterogeneity in the management phase (cf. Section 5.9). Here, heterogeneity
does not influence consistency in the following steps. For the interested reader,
Bodenstaffet al. [21] discusses several examples where these differences influence
consistency maintenance in value and coordination modelling.
•Granularity. The models are defined at the same level of granularity.
•Time frame. The time frame of the models is different. The value model considers a
period of one year, while the coordination model is instance-based. As discussed in
Section 4.3, this cannot be homogenized. Therefore, we handle this heterogeneity
in later steps by comparing coordination and value models on a business transaction
level (i.e., at an instance level). At runtime, the value model is considered for a
period of time decided upon by the manager when comparing it with the event logs.
•Property type. The estimations modelled in the value model do not have a counter-
part that is prescribed in the coordination model. For example, the estimated ratio
between purchase and lease copiers is not present in the coordination model since
the latter is an instance-based model. Therefore, these differences do not cause any
problems in maintaining consistency, and are simply checked for consistency with
the event log.
The main results of Step 2 are as follows:
•Non-valuable coordination model messages do not have a counterpart in the
value model.
•Differences in perspective are identified.
•To overcome time frame differences, consistency checks between value and
coordination model need to be performed at an instance level.
•Estimations in the value model are checked during runtime with the event log.
5.4 Step 3: Inter-model relation detection
In Steps 1 and 2 we analyze the value and coordination models to prepare them for com-
parison. In Step 3 we start with detecting relations between the given value and coor-
dination model. These relations enable us to define consistency constraints between the
models in Step 4.
To define these constraints for viewpoint models, first, their overlap needs to be iden-
tified. As discussed in Chapter 4 this means we first identify those parts value and coor-
dination models have in common. We focus on the communication between actors and
do not consider internal behavior. Therefore, we identify entities in the real world that
77
CHAPTER 5. MANAGING DEPENDENCY RELATIONS: BUSINESS AND
COORDINATION MODELS
Lease €
Copier L
Service €
Maintenance
Purchase €
Copier P
Request L
Offer L
Service €
Lease €
Copier L
Request P
Offer P
Purchase €
Copier P
Value model
transfers Coordination model
messages
Real life
entities
Figure 5.4: Relations between models
and real-life entities
Lease €
Copier L
Service €
Maintenance
Purchase €
Copier P
Value model
transfers
Request L
Offer L
Service €
Lease €
Copier L
Request P
Offer P
Purchase €
Copier P
Coordination model
messages
Symmetric
existence
dependency
Figure 5.5: Inter-model dependency re-
lations
are exchanged between the actors and that are modelled in both value and coordination
model. Figure 5.4 depicts these entities and shows which value and message transfers
refer to them. For example, the value model depicts the transfer of money paid for leas-
ing a copier, and the coordination model depicts a message transfer representing leasing
a copier as well, i.e., both concepts refer to money paid for a lease. Further, money for
service on the copier, money for purchasing a copier, lease copiers, and purchase copiers
are modelled as concepts in both value and coordination model. Requests and contracts
are only modelled in the coordination model, while maintenance is only modelled in the
value model. Concepts referring to the same entity constitute overlapping parts between
value and coordination models. Consequently, they are not independent.
After identifying the overlap between the two models with respect to the concepts,
we analyze the type of relation they have. In this case, if a dependent concept (e.g. a
lease copier) in the value model exists, the related concept (e.g. a lease copier) in the
coordination model exists as well, and vice versa. There is no property dependency since
concepts in the value model describe the property value, and concepts in the coordination
model do not contain properties. Therefore, the value of a concept in the value model
is not dependent on a message in the coordination model. As a result, overlapping parts
have a symmetric existence dependency as depicted in Figure 5.5.
The main result of Step 3 is as follows:
•Identification of symmetric existence dependencies between transfers in value
and coordination model.
78
5.5. STEP 4: INTER-MODEL CONSISTENCY CONSTRAINTS
5.5 Step 4: Inter-model consistency constraints
In Step 3 we identify inter-model relations. In Step 4, we now use these symmetric
existence dependency relations to define inter-model consistency constraints.
In general, we consider two models as being consistent if they are contradiction-free.
We consider value and coordination models to be consistent if they facilitate the same
business transactions (e.g., one option for purchase and one for leasing a product). Fur-
thermore, each business transaction needs to be facilitated in the same way (e.g., purchase
over the internet versus purchase in a store). Therefore, the consistency constraint defined
between value and coordination models should describe their relation on business trans-
action level and on transfer level.
5.5.1 Transfer level
The result of Step 3 is a set of interrelated concepts having a symmetric existence de-
pendency (cf. Figure 5.5 where these relations are depicted). According to Step 4 of our
method (see Section 4.4.2) every relation is translated into a corresponding constraint:
If concepts in set Xof two or more concepts are symmetric existence de-
pendent on each other, the corresponding constraint states: If x∈Xexists,
all concepts in Xexist.
Here, each dependency is bilateral, i.e., set Xcontains two concepts. For example,
for the symmetric existence dependency Lease ein the value model and Lease ein the
coordination model (cf. Figure 5.5), the consistency constraint is formulated according to
the above definition:
If and only if a concept for a lease payment (i.e., Lease e) exists in the
value model, also a concept for a lease payment (i.e., Lease e) exists in the
coordination model.
Since each of these consistency constraints describes a symmetric existence depen-
dency relation between a concept with a value property in the value model and a concept
describing a message transfer in the coordination model, it becomes possible to general-
ize over these constraints (cf. Step 4, Section 4.4.2). Here, the common denominator is
that for each concept having a value property in the value model there should be some
message transfer in the coordination model. However, not every message transfer in the
coordination model results in a value transfer in the value model. For example, making
a purchase or lease request is not associated with any value. In other words, the real-life
entity to which the message refers (i.e., the email or web form request sent by the cus-
tomer) does not have any monetary value. Therefore, we also state that for every message
transfer in the coordination model that refers to an entity with a value property (i.e., a
valuable message) there should be a value transfer in the value model as well.
79
CHAPTER 5. MANAGING DEPENDENCY RELATIONS: BUSINESS AND
COORDINATION MODELS
5.5.2 Business transaction
There are two possible business transactions in the models, i.e., a copier is purchased or
leased. Both transactions are associated with a set of value and message transfers that
realize the business transaction.
In addition, we check whether the direction in which transfers occur is the same in
both models. For example, if the value model describes money is paid by actor A to
actor B, while the coordination model describes the matching message transfer indicating
money is paid by actor B to actor A instead, these two models are not consistent with each
other. Therefore, an additional constraint on each transfer is that issuer and recipient of
the transfers should match. First, we state when we consider two sets to match:
Definition 1 (Match between value and coordination model).Sets match if
•for each value transfer in the value model there exists a message transfer with
matching issuer and recipient in the coordination model, and
•for each valuable message in the coordination model there exists a value transfer
with matching issuer and recipient in the value model.
We use the definition for matching sets to formulate our general consistency con-
straint:
Constraint 1 (Value and coordination model).(1) Each set of value transfers describing
a business transaction in the value model has exactly one matching set (cf. Definition 1)
of message transfers representing a business transaction in the coordination model, and
(2) vice versa.
The set representing the business transaction of purchasing a copier in the value
model, and the set representing this transaction in the coordination model of our run-
ning example, match. Also the elements in these sets match. For example, value transfer
Purchase matches message transfer Purchase since both have the same issuer, recipient
and name.
Also the set representing the business transaction of leasing a copier in the value
model matches the set representing this transaction in the coordination model. However,
the elements in these two sets do not match. More specifically, value transfer Maintenance
should have a matching message transfer in the coordination model set.
This matching problem occurs due to the different purpose of value and coordination
model. A value model captures everything that is of value for the actors. In this case,
Maintenance (cf. Figure 5.1) is something of value for the customer. However, he only
receives maintenance during execution of the contract, not when the contract is estab-
lished. In the coordination model only the establishment of the lease contract is depicted,
not how the contract is executed. Therefore, the coordination model does not show the
actual maintenance of the copier. As a result, we detect this difference, but do not adapt
the models. Therefore, we consider the value model from Figure 5.1 to be consistent with
the coordination model from Figure 5.2 (i.e., Constraint 1 is met).
80
5.6. STEP 5: INTRA-MODEL RELATION DETECTION
Event Log
Coordination ModelValue Model
Matching sets
Number of occurrences
Average value
Matching sets
Ordering
Matching sets
Figure 5.6: Constraints between models and event log
As discussed at the beginning of this chapter, we do not show how to check consis-
tency for models that contain loops or back edges. Rather, we give a short impression on
how to handle such cyclic structures. An overview is given in Figure 5.6 where consis-
tency relations between value and coordination model are depicted. Aside from checking
matching sets,average values in value models, and order of messages in coordination
models, additional consistency constraints are required. In particular, constraints that
check for matching number of occurrences of transfers, and for co-occurrence of busi-
ness transactions are required. These constraints are checked by comparing models and
event logs (cf. Figure 5.6). For example, when both payment of a product and its delivery
are influenced by the same loop, it can be expected that both transfers occur the same
number of times and this should be facilitated by both value and coordination model.
Furthermore, if it is possible to order and purchase more than one copier in a single or-
der, this results in a co-occurrence of business transactions. This co-occurrence should
be facilitated in both value and coordination model (cf. Figure 5.6, set matching between
value and coordination model). For the interested reader, a complete discussion on how
to formulate such consistency constraints can be found in Bodenstaffet al. [20].
The main results of Step 4 are as follows:
•Definition of a consistency constraint between value and coordination model
(cf. Constraint 1).
•Consistency checking between value and coordination model of our running
example.
5.6 Step 5: Intra-model relation detection
In Step 3 we analyze inter-model relations to create a basis for defining consistency con-
straints between value and coordination model. In Step 5 we now analyze existing intra-
model dependencies between concepts. This enables us to define in Step 6 intra-model
consistency constraints.
81
CHAPTER 5. MANAGING DEPENDENCY RELATIONS: BUSINESS AND
COORDINATION MODELS
value viewpoint message viewpoint
Lease €
Copier L
Service €
Maintenance
Purchase €
Copier P
Request L
Offer L
Service €Lease €
Copier L
Request P
Offer P
Purchase €
Copier P
x
asymmetric
existence
dependency
concept
symmetric
existence
dependency
Figure 5.7: Example case: Intra-model dependencies
5.6.1 Value model
For the value model it holds that the different concepts are connected through dotted and
solid lines (cf. Figure 5.1). Both dotted and solid line depict one business transaction.
Each business transaction involves all connected transfers. The latter means that if one
transfer occurs, all connected transfers should occur as well. This indicates a symmetric
existence dependency between the concepts of each business transaction (cf. left part of
Figure 5.7).
5.6.2 Coordination model
For the coordination model it holds that the different concepts are connected through
sequence and message flows (cf. Figure 5.2). Again, there are two possible business
transactions, depending on whether a customer wants to purchase or lease a copier. Both
business transactions involve interconnected transfers that occur one after the other, i.e.,
there exists an order between them. This indicates an asymmetric existence dependency
between the concepts of each business transaction (cf. right part of Figure 5.7).
The main results of Step 5 are the following:
•Identification of the symmetric existence dependency between transfers in the
value model.
•Identification of the asymmetric existence dependency between transfers in the
coordination model.
5.7 Step 6: Intra-model consistency constraints
In Step 6 we explicate intra-model consistency constraints, using the identified depen-
dency relations from Step 5. These constraints enable consistency checking of the models
with the running system. As discussed in Step 5 of Section 4.5, intra-model consistency
82
5.7. STEP 6: INTRA-MODEL CONSISTENCY CONSTRAINTS
constraints are (1) based on identified intra-model dependency relations, and (2) on model
characteristics. Here, we first discuss consistency constraints on the value model after
which we discuss consistency constraints on the coordination model.
The intra-model consistency constraints ensure the model describes the inter-organizational
cooperation properly. These constraints hold if at runtime the behavior of the system is
the same as the behavior captured in the model. We check this by gathering information
from event logs that describe the behavior of the actors, and compare this with the models.
Therefore, intra-model consistency constraints are defined using event logs. Again, we
consider models on both business transaction and on transfer level.
5.7.1 Value model
We consider a value model to be consistent with the inter-organizational cooperation if the
business transactions described by the value model (e.g. leasing and purchasing a copier)
are used in the cooperation (i.e., customers indeed purchase and lease copiers), and if
each business transaction executed in the cooperation is also described by the value model
(e.g. there are no second hand copiers sold since this is not described in the value model).
Furthermore, each business transaction is facilitated in the same way in the value model
and in real life (e.g. purchase over the internet versus purchase in a store). Therefore, the
consistency constraint defined between model and event log should describe their relation
on both business transaction and transfer level.
Transfer level. In Step 5 we identify that all intra-model dependency relations are sym-
metric existence dependency relations (cf. value viewpoint in Figure 5.7). According to
our method, each of these relations is translated into a consistency constraint (cf. Section
4.4.2):
If concepts in set Xof two or more concepts are symmetric existence de-
pendent on each other, the corresponding constraint states: If x∈Xexists,
all concepts in Xexist.
Here, set Xconsists of the set of concepts for purchasing a copier or of the set of
concepts for leasing one (cf. value viewpoint in Figure 5.7). For example, for purchasing
a copier concepts Purchase eand Copier P have a symmetric existence dependency and
their consistency constraint is formulated according to the above definition:
If and only if a concept for Purchase eexists in the value model, also a
concept for Copier P exists.
Each of these intra-model consistency constraints describes a symmetric existence
dependency. Therefore, it is possible to generalize over these constraints and to define one
general intra-model consistency constraint describing this relation. Through transitivity
we conclude that all value transfers in a business transaction depend on each other for
existence. In other words, if one value transfer of a business transaction occurs, also the
83
CHAPTER 5. MANAGING DEPENDENCY RELATIONS: BUSINESS AND
COORDINATION MODELS
other transfers occur. For example, if the event log shows evidence that lease money is
paid by the customer (i.e., Lease ein Figure 5.7), there should be evidence of service
money paid by the customer (Service e), delivery of a copier by the company (Copier
L), and maintenance performed on the leased copier (Maintenance). As a result of this
transitivity relation between concepts in one business transaction, we generalize these
constraints into one constraint for each business transaction (i.e., one for purchasing and
one for leasing a copier).
Business transaction level. Furthermore, each business transaction in the event log
should match one of these business transactions in the value model (e.g., each business
transaction in the event log needs to be a purchase or lease transaction). In addition, each
business transaction in the value model has to occur at least once in the event log. If, for
example, no purchases are made by the customers, but only lease transactions occur, we
do not consider this to be consistent with the value model.
In addition to the existence of value transfers and business transactions, transfers are
also required to be exchanged between the same actors. For example, when a copier is
purchased, it needs to be purchased by a customer from the copier company. In other
words, issuer and recipient of transfers captured in value model and event log need to
match. First we state when two sets match:
Definition 2 (Match: value model - event log).Sets match if:
•for each value transfer in the value model there exists an entry with matching issuer
and recipient in the event log, and
•for each valuable entry in the event log there exists a value transfer with matching
issuer and recipient in the value model.
Now, we define the general intra-model consistency constraint for the value model:
Constraint 2 (Business transaction, value model).The value model is intra-model con-
sistent if:
1. Each set (representing one business transaction) in the event log matches a set
of value transfers representing a business transaction in the value model for the
specified time frame.
2. Each business transaction in the value model occurs as business transaction in the
event log for the specified time frame.
This constraint is graphically represented in Figure 5.8 where event log entries for one
business transaction of purchasing a copier are depicted. These entries are checked for
consistency with the value model by matching value transfers in the event log with those
of the value model. Here, the two required value transfers (Purchase eand Copier P) are
present in the event log.
In addition to the general consistency constraint, we define model-specific constraints.
Since the value model denotes financial benefits of the cooperation over a specified period
84
5.7. STEP 6: INTRA-MODEL CONSISTENCY CONSTRAINTS
Request purchase copier by customer at t1
Customer pays for purchase copier at t4
Customer receives purchase copier at t3
Offer purchase copier by company at t2
One business transaction in the event log:
Purchase €
Copier P
Request P
Offer P
Purchase €
Copier P
Value transfers
from Figure 5.7 for
purchasing a copier:
Message transfers
from Figure 5.7 for
purchasing a copier:
Constraint 2:
matching value
transfers
Constraint 5:
matching message
transfers
Violation of Constraint 6:
order of messages
Figure 5.8: Example case: Intra-model consistency constraints
of time, we also check whether estimated profits are achieved. This is done by checking
whether the number of transfers and their values are equal to the estimations (cf. Table
5.1).
Constraint 3 (Number of occurrences).For each business transaction in the value model
the estimated number of occurrences is the same as the realized number of business trans-
actions in the event log during the specified time frame.
Constraint 4 (Average value).The estimated average value of the transfers in each busi-
ness transaction of the value model is the same as the realized average value of this
transfer in the event log for the specified time frame.
5.7.2 Coordination model
In analogy to the value model, we consider a coordination model to be consistent with the
inter-organizational cooperation if the business transactions described by the coordination
model are used in the cooperation, and if each business transaction executed in the cooper-
ation is also described in the coordination model. Furthermore, each business transaction
is facilitated in the same way in the coordination model and in real life. Therefore, the
consistency constraint defined between model and event log should describe their relation
on both business transaction and transfer level.
Transfer level. In Step 5 we conclude all intra-model dependency relations are asym-
metric existence dependency relations. Each of these relations is translated into a consis-
tency constraint (cf. Section 4.4.2):
If concept xis asymmetric existence dependent on set Yof one or more
concepts, the constraint states: If xexists, Yexists.
In this coordination model all dependency relations are bilateral, i.e., they exist be-
tween two concepts. One such constraint now states:
85
CHAPTER 5. MANAGING DEPENDENCY RELATIONS: BUSINESS AND
COORDINATION MODELS
If a concept for purchasing a copier exists in the coordination model, a con-
cept for receiving a copier exists as well.
Each intra-model consistency constraint describes an asymmetric existence depen-
dency. Therefore, it is possible to generalize over constraints and to define one general
intra-model constraint. In this case, connected transfers are acyclic, directed graphs (cf.
Figure 5.7 where both business transactions form a tree).
Business transaction level. Furthermore, each business transaction in the event log
should match one of the business transactions in the coordination model and each business
transaction in the coordination model has to occur at least once in the event log.
In addition to the existence of message transfers and business transactions, the trans-
fers are required to be exchanged between the same actors as well. For example, when a
copier is purchased, it needs to be purchased by a customer from the copier company. In
other words, issuer and recipient of transfers need to match. First, we state when two sets
match:
Definition 3 (Match: coordination model - event log).Sets match if
•for each message transfer in the coordination model there exists an entry with
matching issuer and recipient in the event log, and
•for each message in the event log there exists a value transfer with matching issuer
and recipient in the coordination model.
Now, we define the general intra-model consistency constraint using Definition 3 for
the coordination model:
Constraint 5 (Business transaction, coordination model).The coordination model is
intra-model consistent if:
1. Each set (representing one business transaction) in the event log matches a set
of messages representing a business transaction in the coordination model for the
specified time frame.
2. Each business transaction in the coordination model occurs as business transaction
in the event log for the specified time frame.
We illustrate this constraint in Figure 5.8 where event log entries for one business
transaction of purchasing a copier are represented. These entries are checked for consis-
tency with the coordination model by matching message transfers in the event log with
those in the coordination model. Here, the required message transfers are present in the
event log.
In addition to this general consistency constraint, a model-specific constraint is for-
mulated as well. Since the coordination model explicates in which order messages are to
be exchanged, it is checked whether this prescribed order matches the order of entries in
the event log. For example, when purchasing a copier, money is paid before the copier is
86
5.8. STEP 7: DEPENDENCY ANALYSIS
delivered. This strict partial order in the abstraction of the coordination model is checked
in a straightforward manner with the timestamps occurring in event log entries.
Constraint 6 (Ordering).In each business transaction of the event log messages are
ordered as prescribed in the coordination model for the specified time frame.
This constraint is illustrated in Figure 5.8 where event log entries for one business
transaction of purchasing a copier are represented. The order of these entries is checked
for consistency with the predefined order in the coordination model by matching times-
tamps. Here, the event log shows the copier is delivered prior to payment. This is incon-
sistent with the predefined order in the coordination model. In other words, Constraint 6
is violated. Main results of Step 6 are the following:
•Defining intra-model consistency constraints for the value model, and
•Defining intra-model consistency constraints for the coordination model.
5.8 Step 7: Dependency analysis
In the previous steps we identify consistency constraints between models and event log,
i.e., we define inter- and intra-model consistency constraints (cf. Figure 5.6). In this step
we translate all necessary model parts into a language-independent notation to enable
easy checking of consistency constraints.
By representing dependencies in and between the models independent from any for-
malism, we are able to handle different notations used in different models. Here, we use
sets and tuples for representation and refer to these representations as abstractions of the
models. Each business transaction is represented as a set containing tuples, and each tuple
represents a value transfer, message transfer, or event log entry. In addition, the use of sets
and tuples enables us to define more formal constraints for checking consistency. More
specifically, it enables us to redefine constraints from Steps 4 and 6 in matching sets and
tuples. Here, we start with abstracting necessary information in the models into sets and
tuples after which we discuss formalization of different consistency constraints.
5.8.1 Value model abstraction
In the value model we abstract from information that has no overlap with the coordination
model and that is no part of any intra-model consistency constraint. In other words,
we only capture these parts of the value model needed to check intra- and inter-model
consistency constraints. Essential in these consistency constraints are transfers between
actors, properties of these transfers, and inter-transfer relations.
In Figure 5.1 the highlighted grey areas depict the two possible business transactions.
The value transfers are important in the overlap between value model and coordination
87
CHAPTER 5. MANAGING DEPENDENCY RELATIONS: BUSINESS AND
COORDINATION MODELS
model. Furthermore, intra-model consistency constraints check the number of value trans-
fers and their value.
A value transfer in a value model has an issuer,recipient, unique name, estimated
average value, and estimation on the number of occurrences, which we represent as quin-
tuple x=(a,b,c,d,e) where issuer(x)=a,recipient(x)=b name(x)=c,value(x)=d and
occurrences(x)=e. For example, in Table 5.1 value transfer Copier P is expected to
be issued by the copier company (represented as: cc), to be received by the customer
(represented as: c), to have an average value of 7500 e, and to occur 24 times. This is
represented as: Copier P=(cc,c,copierp,7500,24).
These quintuples capture the information for the inter-model consistency constraints,
i.e., they contain the different value transfers. Furthermore, they capture the information
for the intra-model consistency constraints, i.e., they contain both expected number of
occurrences and expected value. As a last part, we group different tuples into sets, where
each set describes one business transaction.
As a result, the abstraction of the value model from Figure 5.1 contains two sets (the
two grey areas) as well as the values and number of occurrences in Table 5.1:
V={(c,cc,lease,1200,48),(cc,c,copierl,1200,48),
(c,cc,service,700,48),(cc,c,maintenance,700,48)},
{(c,cc,purchase,7500,24),(cc,c,copierp,7500,24)}
5.8.2 Coordination model abstraction
The abstraction of the coordination model captures the overlap with the value model (i.e.,
those model parts used for inter-model consistency constraints), and those model parts that
are used for the intra-model consistency constraint. Therefore, the abstraction captures
message transfers between actors, the order in which these transfers occur, and inter-
transfer relations.
We use sets of message transfers performed in a single business transaction to repre-
sent the coordination model (see highlighted grey areas in Figure 5.2). A message transfer
is represented by issuer,recipient, and unique name as triplet x=(issuer,recipient,name).
For example, message transfer copier p in Figure 5.2 is represented as (cc,c,copierp)
with issuer(Copier P)=cc,recipient(Copier P)=c, and name(Copier P)=copierp. Fur-
thermore, a strict partial order ‘<’ is defined between messages based on the order in
which they occur in the coordination model.
The triplets capture the information for the inter-model consistency constraints, i.e.,
they contain the different message transfers. Furthermore, they capture information for the
intra-model consistency constraint, i.e., they contain the order in which messages should
occur. As a last part, we group the different tuples into sets, where each set describes one
business transaction. As a result, the abstraction of the coordination model from Figure
5.2 contains two sets (the two grey areas) as well as a strict partial order:
88
5.8. STEP 7: DEPENDENCY ANALYSIS
W=({(c,cc,request),(cc,c,offer),(c,cc,lease),(cc,c,copierl),
(c,cc,service)},
(c,cc,request)<(cc,c,offer),(cc,c,offer)<(c,cc,lease),
(c,cc,lease)<(cc,c,copierl),(c,cc,service)<(cc,c,copierl)),
({(c,cc,request),(cc,c,offer),(c,cc,purchase),(cc,c,copierp)},
(c,cc,request)<(cc,c,offer),(cc,c,offer)<(c,cc,purchase),
(c,cc,purchase)<(cc,c,copierp))
5.8.3 Formalization of constraints
In Steps 4 and 6 we define intra- and inter-model consistency constraints. These con-
straints are expressed in natural language. In Step 7, so far, we define abstractions of
models and event log based on these constraints. Based on formalization of the models, it
is possible to formalize constraints. We demonstrate this for the inter-model consistency
constraint between value and coordination model. We use the definition of matching sets
(cf. Definition 1 page 80) to formulate this consistency constraint (cf. Constraint 1 page
80). To check whether abstractions of models are semantically equal (i.e, represent the
same sets of transfers) we need to match:
1. business transactions: check whether value and coordination model offer the same
business transactions, i.e., whether the sets in their formal models match, and
2. concepts: check whether the concepts in the business transactions match, i.e.,
whether the elements in the sets representing value and coordination model match
with each other.
For example, we check whether value and coordination model both describe purchas-
ing and leasing a copier, i.e., we check whether the sets representing the models match.
Furthermore, we check whether the transfers that are prescribed by the value model and
coordination model for these business transactions match with each other, i.e., we check
whether elements in the sets of the different models match with each other.
Definition 1 that matches business transactions as well as transfers between the ac-
tors, is formalized in two different definitions. First, a formal definition for matching the
transfers is given. Two concepts (e.g., value and message transfer) match if they have the
same issuer, recipient, and name. In the abstraction, concepts are represented as elements
in sets:
Definition 4 (Matching elements).Let x and y be elements of a set. Then x and y are
matching elements (match(x,y)) iff:
1. issuer(x)=issuer(y),
2. recipient(x)=recipient(y), and
3. name(x)=name(y).
89
CHAPTER 5. MANAGING DEPENDENCY RELATIONS: BUSINESS AND
COORDINATION MODELS
Second, a formal definition for matching business transactions is formulated. Two
business transactions match if they facilitate the same exchanges between actors (i.e., the
elements in the sets match). A business transaction is represented as set in the abstraction:
Definition 5 (Matching sets).Sets M and N match (M uN) iff
1. ∀x∃!y(x∈M∧y∈N∧match(x,y)), and
2. ∀y∃!x(y∈N∧x∈M∧match(x,y)).
In both formal definitions, sets and elements are used to capture the notions of busi-
ness transactions and concepts, respectively. Constraint 1 defined in Step 3 states that
each business transaction in the value model should have a matching business transaction
in the coordination model, and vice versa. To formalize this part of the constraint, we
define mapping business transactions in the value model to business transactions in the
coordination model, and vice versa:
Definition 6 (Mapping).Let set Vand Wbe abstractions of value and coordination
model. Then there exists a mapping ν:V→Wif:
1. ∀M∃!N(M∈V∧N∈W∧NuM), and
2. ∀N∃!M(N∈W∧M∈V∧MuN).
Based on these definitions, we formalize Constraint 1. If there exists a mapping from
one model to the other, the inter-model consistency constraint is satisfied:
Constraint 7 (Value and coordination model - formal -).Let set Vand Wbe abstractions
of value and coordination model. Then these models are inter-model consistent iffthere
exists a mapping ν:V→W.
The main results of Step 7 are the following:
•Formalization of value model parts for checking consistency,
•Formalization of coordination model parts for checking consistency, and
•Formalization of the inter-model consistency constraint.
5.9 Step 8: Log analysis
In the previous steps we analyze the models, define consistency constraints, and formalize
these parts of the models necessary to check consistency. In Step 8 we demonstrate how
we analyze event logs to check consistency constraints at runtime as well.
The event log contains information exchanged between actors in the cooperation. The
abstraction of the event log captures these messages necessary to check intra-model con-
sistency constraints of both value and coordination model. Therefore, the abstraction
90
5.9. STEP 8: LOG ANALYSIS
contains all message transfers needed for coordinating the cooperation and all message
transfers containing some value. In addition, we capture the order of these transfers, their
value, their number of occurrences, and the inter-transfer relations.
Each set in the abstraction contains entries performed in a single business transaction.
Each entry in an event log is represented as timestamp,issuer,recipient, unique name,
and specific value. For example, entry Service in transfer copier payment (cf. Figure 5.3)
is represented as: (3,c,cc,service,700). We use a simplified notation for timestamps;
a higher integer indicates a later point in time. The following example shows the set
abstraction of an event log for one month.
E={(1,c,cc,request,0),(2,cc,c,offer,0),(3,c,cc,lease,1200),
(4,cc,c,copierl,1200),(3,c,cc,service,700)},
{(5,c,cc,request,0),(6,cc,c,offer,0),(7,c,cc,lease,1400),
(8,cc,c,copierl,1400),(7,c,cc,service,700)},
{(9,c,cc,request,0),(10,cc,c,offer,0),(11,c,cc,purchase,6000),
(14,cc,c,copierp,6000)},
{(15,c,cc,request,0),(16,cc,c,offer,0),(17,c,cc,lease,2500),
(20,cc,c,copierl,2500),(17,c,cc,service,1000)},
{(21,c,cc,request,0),(22,cc,c,offer,0),(23,c,cc,purchase,10000),
(24,cc,c,copierp,10000)},
{(25,c,cc,request,0),(26,cc,c,offer,0),(27,c,cc,lease,1000),
(28,cc,c,copierl,1000),(27,c,cc,service,700)}
Aformalization of the intra-model consistency constraints (as discussed in Step 7 for
the inter-model consistency constraint) is described in Bodenstaffet al. [20]. Since the
aim of this thesis is to show applicability of the method for managing inter-organizational
cooperations, describing the formalization of the intra-model consistency constraints is
out of scope.
After formalizing the event log, it is possible to check intra-model consistency con-
straints for both value and coordination model:
Value model. Each business transaction in event log Eis a realization of a business
transaction in value model V(cf. Constraint 2). Each valuable entry in the event log
matches a value transfer in the value model. Again, we disregard value transfer main-
tenance since this is not part of the contract establishment, but of the execution phase.
Furthermore, both business transactions modelled in the value model are present in the
event log. Also, the number of occurrences should be equal to estimations in the value
model (cf. Constraint 3). Estimations in the value model are for one year, while event
log Erepresents activities over one month. Therefore, we divide the estimated num-
ber of occurrences by twelve. For example, the realized number of Purchase transfers
in the event log is 2 and the estimated number of occurrences Purchase in the value
model is 24 1
12 =2. Furthermore, realized average value should be equal to the esti-
mated average value (cf. Constraint 4). For example, realized average value of Purchase
is 6000
2+10000
2=8000 euro and therefore, not equal to estimated average value in the
91
CHAPTER 5. MANAGING DEPENDENCY RELATIONS: BUSINESS AND
COORDINATION MODELS
value model of 7500 euro. Therefore, value model and event log are not consistent at
September 15, 2007.
Coordination model. To check consistency between event log Eand coordination model
W, we check both constraints. Each business transaction in the event log matches a set
in the abstraction of the coordination model (cf. Constraint 5). Each entry in the event
log matches a message transfer in the coordination model. For example, event log entry
{(1,c,cc,request,0),(2,cc,c,offer,0),(3,c,cc,lease,1200),
(4,cc,c,copierl,1200),(3,c,cc,service,700)}matches
{(c,cc,request),(cc,c,offer),(c,cc,lease),(cc,c,copierl),(c,cc,service)}. Fur-
thermore, the order of messages in the coordination model should be equal to the order
in the event log (cf. Constraint 6). The coordination model prescribes payments have to
occur before delivery. This is the case regarding this example. Event log and coordination
model are consistent since both constraints are met.
5.10 Step 9: Causal analysis
In the previous steps we define consistency constraints between models and event log
which we check as well. After checking the consistency constraints, it is now possible
to do causal analysis of reasons for inconsistencies. In Step 9, we prepare actual man-
agement of models through causal analysis. The aim is (1) to find causes for violations
of the consistency constraints, and (2) to predict consequences when adapting models
to regain consistency. By identifying causes we enable adaptation of the models so that
inconsistencies are solved, preferably without introducing new ones.
For this, we first discuss what causes exist for violated constraints. Second, we discuss
possible changes to restore consistency between the models. Third, we link causes for
violations to changes in the models. We indicate which causes can be solved by which
changes in the models. We conclude with some theorems and proofs that demonstrate the
relation between coordination and value model using the causal analysis.
5.10.1 Causes
An intra-model constraint violation of a value or coordination model is an inconsistency
between running system and model (cf. Constraints 2, 3, 4, 5, and 6). A corresponding
categorization of these causes is depicted in Table 5.2. Of course, causes can appear
simultaneously.
Cause 1. There is a set in the event log abstraction that does not match any set in value
or coordination model abstraction. There is a business transaction executed at runtime
and not modelled (cf. Constraint 2, (1) and Constraint 5, (1)). This situation occurs if:
(a) A combination of transfers is missing. For example, consider an event log con-
taining entries of leasing two copiers with only one maintenance contract. These entries
will not match with a set in the value model abstraction where each copier has its own
maintenance contract.
92
5.10. STEP 9: CAUSAL ANALYSIS
Name Cause VM CM
Cause 1Missing set in model x x
Cause 2Missing set in event log x x
Cause 3Mismatch number of occurrences x
Cause 4Mismatch average value x
Cause 5Mismatch message order x
Table 5.2: Causes of intra-model constraint violation
(b) There is a transfer missing in the model, for example, if the event log contains
entries of selling printers while no printer purchase is modelled in the value model.
Cause 2. A set in the model abstraction has no occurrence in the event log. This
means that one business transaction never occurred (cf. Constraint 2, (2) and Constraint
5, (2)). For example, if the event log does not show any entries of selling copiers, this is
inconsistent with Figure 5.1.
Cause 3. The number of estimated occurrences of a value transfer in a specific set is
not the same as the realized number of occurrences of that value transfer in sets of the
event log (cf. Constraint 3). For example, assume the value model estimates 24 copiers
will be purchased. If the event log shows only 20 sold copiers, an inconsistency occurs.
Cause 4. The estimated average value of a value transfer in a specific set is not the
same as the realized average value of transfers in sets of the event log (cf. Constraint 4).
For example, in the value model it is estimated that a purchase copier costs on average
7500 e. If the event log shows an average of only 6000 e, an inconsistency occurs.
Cause 5. The message order in a set in the coordination model abstraction does not
match the message order in a set in the event log (cf. Constraint 6). For example, in
the coordination model a copier is first paid and then delivered. If the event log shows a
delivery before payment, an inconsistency occurs.
5.10.2 Changes
In the previous subsection we identify causes for inconsistencies. In this section we re-
view which changes in the models restore consistency. To maintain consistency between
running system and models, changes might become necessary. For example, if the event
log shows a lower number of sales than expected it makes sense to adapt estimations in
the value model, or to change implementation to enforce more sales. Handling impact
of changes within one model on inter-model relations for complex cooperations is te-
dious work. Each consistency relation a changed model has with other models, must be
reevaluated and, if necessary, be updated.
To enable more efficient and structured checking and maintenance of consistency, we
propose determining upfront effects certain changes have. In this way, a well-informed
decision on the type of change can be made. Furthermore, it is possible to oversee which
other relations are affected. We demonstrate our approach by illustrating how to catego-
93
CHAPTER 5. MANAGING DEPENDENCY RELATIONS: BUSINESS AND
COORDINATION MODELS
XOR
XOR
XOR
AND
AND
AND A:5€
B:3€
250%
50%
50%
50%
2
M2: {{(i,r,A,5,1), (i,r,B,3,1)}, {(i,r,B,3,1)}}
A:5€
B:3€
M1: {{(i,r,A,5,1), (i,r,B,3,1)}, {(i,r,B,3,1)}}
Model 1 Model 2
Issuer (i) Issuer (i)
Figure 5.9: Same class models
AND
Customer, M''
XOR
Customer, M’ A
C
C
D
XOR
AND
Customer, M’’’
C
B
A
T
XOR
AND
Customer, M A
B
C
Figure 5.10: Observable changes
rize changes in value and coordination models (cf. Table 5.3).
Change 1. Non-observable changes in a model do not influence the abstraction of the
model, i.e., the change does not influence the possible business transactions. There exist
two ways for applying non-observable changes:
(i) Typically, there is more than one way to structure a model while preserving the
same possible business transactions. For example, though Model 1 and Model 2 in Figure
5.9 are different, they facilitate the same transactions since abstractions of M1 and M2 are
equal. Since a change from Model 1 to Model 2 does not change the possible business
transactions, we refer to this as non-observable change.
(ii) The other way is to change part of the model with no connection to the abstraction.
For example, changing choice ‘lease or buy?’ in Figure 5.2 into ‘sufficient money or not?’
does not influence the abstraction of the model since it is not a message transfer.
Depending on the type of model, also several categories of observable changes are
identified (cf. Table 5.3):
Change 2. Observable structural changes add or remove (part of) a business trans-
action by adding or removing constructs (e.g. XOR-splits and transfers) while preserving
a valid model. Figure 5.10 depicts three observable structural changes represented as e3-
value model. Model Mwith set {{A,B},{C}} is the original model of our running example.
However, we rename transfers for the sake of simplicity. Models M0,M00,and M000 are
adapted models of Mwhere (sets of) transfers are removed or added.
Other observable changes are model-specific. Changes in the estimated number of oc-
currences (Change 3 in Table 5.3) and in the estimated average value of a transfer (Change
94
5.10. STEP 9: CAUSAL ANALYSIS
Type Subtype Change VM CM
Non-observable Change 1x x
Observable
Structural Change 2x x
#Occurrences Change 3x
Average value Change 4x
Message order Change 5x
Table 5.3: Categorization of model changes
4) are value model-specific. Changes in the order of messages (Change 5) are coordina-
tion model-specific. In general, model-specific changes are related to these parts of the
abstraction which are not captured by observable structural change. By going through the
abstraction and addressing each part not influenced by an observable structural change,
model-specific changes are identified.
Change 3. An observable change in the number of occurrences is achieved by adapt-
ing the last element of a quintuple (i.e., number of occurrences). For example, Model 1
in Figure 5.9 represents a single actor with 2 customer needs. Adapting this from 2 to 4
results in doubling the last element in the quintuple from 1 to 2.
Change 4. An observable change in average value indicates the fourth element of a
quintuple (i.e., the average value) is changed. As opposed to Change 3 the average value
is not the result of other estimations, but of combining information outside the model.
For example, information on production costs determine, partially, the average value of a
product.
Change 5. An observable change in the order reorganizes exchanges when they oc-
cur. Here, the coordination model depicts payment before delivery. The copier company
might decide to deliver prior to payment as service to its customers. Changing this order
does not affect other parts of the abstraction, it only affects the strict partial order.
Based on this categorization of changes, we show that a non-observable change has
different properties compared to an observable change:
We refer to models with the same functionality, i.e., facilitating the same business
transactions, as models that belong to the same class (like Model 1 and Model 2):
Definition 7 (Class).Let sets Vand Wbe value model abstractions. Then these models
belong to the same class if there exists a mapping from Vto Waccording to Constraint
7 page 90.
As opposed to non-observable changes, observable changes change the possible busi-
ness transactions. As a consequence, we state that observable changes change the class of
the model:
Lemma 1 (Observable Structural Change).An observable structural change in a model
changes its class.
Proof: According to Definition 6, there exists a mapping between two abstractions
if their sets match (cf. Definition 5). If there exists a mapping, they belong to the same
95
CHAPTER 5. MANAGING DEPENDENCY RELATIONS: BUSINESS AND
COORDINATION MODELS
class (cf. Definition 7). By adding or deleting a set or part of a set, the new set and
the original one are not consistent with each other (cf. Definition 5). As a consequence,
the new abstraction of the model belongs to a different class than the original one. Also
changes in issuer, recipient or name result in a class change since such change influences
matching tuples (cf. Definition 4).
5.10.3 Causal analysis
The causal analysis consists of two parts.(1) We analyze possible causes for violations.
For this, we apply the cause categorization from Section 5.10.1 and use the asymmetric
intra-model dependencies to find the cause of an inconsistency. (2) Further, we deter-
mine which changes solve the inconsistency and what the consequences are for other
constraints when applying this change.
Causes. As discussed in Step 9 of Chapter 4, a causal analysis can be done for asymmet-
ric dependency relations. The intra-model dependencies in the value model are symmetric
and those of the coordination model are asymmetric (cf. Figure 5.7).
As a consequence, if there is a transfer modelled in the value model that is inconsis-
tent with the coordination model or event log, it is not possible to analyze whether another
transfer caused this problem. The reason for this is that it is not modelled whether one
value transfer causes the existence of another, but merely that several transfers occur in
one transaction (hence the symmetric dependency relation). Furthermore, if a message
transfer in the coordination model is inconsistent with value model or event log, it is
possible to analyze whether there are problems earlier in the chain that causes this incon-
sistency. The reason for this is that the order in which messages are expected to occur is
modelled in the coordination model (hence the asymmetric dependency relation).
Consider the example from Figure 5.11 where one business transaction of the coordi-
nation model is represented (cf. Figure 5.7), and an event log entry that contains messages
purchase and copier P, but apparently misses the original request P and offer P messages.
Using the causal analysis of the asymmetric dependency relation we determine that the
cause of the nonexistence of message offer P is most probably the nonexistence of mes-
sage request P. In other words, a customer bought a copier without a written request and
offer. Solving this inconsistency might be done by either allowing purchase and delivery
of copiers without a written request and offer (i.e., add a business transaction to the coor-
dination model), or by changing the implementation in such a way that sending products
without an official offer is not possible anymore.
Changes. In Section 5.9 an inconsistency between value model and event log is de-
tected. Estimated average value of a copier is 8000 ewhile data in the event log show
7500 e, i.e., a violation of Constraint 4. As discussed, it is not possible to analyze what
caused this violation. However, we provide possible changes to the value model and
predict effects resulting from these changes.
96
5.10. STEP 9: CAUSAL ANALYSIS
Request P
Offer P
Purchase €
Copier P
Event log entry:
{({purchase, copier P}, purchase < copier P)}
Causal analysis:
offer p is missing because
request p is missing
Figure 5.11: Example case: Causal analysis of coordination model
We identify which changes affect which constraints (cf. Figure 5.12). In general, we
determine for each type of model change (cf. Table 5.3) which constraints are affected.
Each change affects a specific part of the abstraction of a model (e.g., changing the esti-
mated average value of a transfer affects the fourth element of the quintuple representing
that transfer in the value model abstraction (cf. Change 4)). This specific part of the ab-
straction appears in one or more consistency constraints. For example, the fourth element
of a value model tuple (i.e., estimated average value) is part of Constraint 4. Figure 5.12
depicts these relations graphically by pointing an arrow from each type of change to the
constraints it affects. Here, we see that in the example case there is one possible type of
model adaptation to solve the inconsistency in Constraint 4, namely type Change 4.
In complex models, constraint violations might be solved by applying multiple types
of changes (e.g. a problem with Constraint 1 can be solved by changing the value model
using type Change 2a or 2b, or by changing the coordination model using type Change
2a or 2c). However, each type of change might affect more than one constraint (e.g. value
model Change 2a and 2b affect Constraints 1 and 2). Visualizing these complex relations
enables the user to determine the most suitable type of change for a specific constraint
violation. The most suitable one is the change having the least negative effects on other
not-violated constraints.
5.10.4 Minimize the number of changes: Theorem and proof
We aim at maintaining consistency while minimizing changes in the models, and without
introducing new inconsistencies. We assume the implementation is based on inter-model
consistent value and coordination models (cf. Constraint 7). We then show the follow-
ing: If the coordination model is intra-model consistent (cf. Constraint 5 and 6), main-
taining intra-model consistency for the value model (cf. Constraint 2, 3, and 4) can be
achieved without structural changes (Change 2) and without introducing new inconsis-
tencies. The advantage is that Changes 3, 4, and 5 each affect only one constraint, and
therefore minimize the number of required changes for introducing new inconsistencies.
97
CHAPTER 5. MANAGING DEPENDENCY RELATIONS: BUSINESS AND
COORDINATION MODELS
Constraint 1/7
Constraint 2
Business Transaction
Constraint 3
Number of Occurrences
Constraint 4
Average Value
Constraint 5
Business Transaction
Constraint 6
Ordering
Value <-> Coordination Model
Value Model <-> Event Log
Coordination Model <-> Event Log
Constraints
Change 1: Non-
observable change
Value Model Changes Coordination
Model Changes
Change 1: Non-
observable change
Change 2: Removing/
adding a business
transaction
Change 2: Removing/
adding a business
transaction
Change 2: Removing/
adding a transfer
Change 3: Changing
number of occurrences
Change 4: Changing
average value
Change 2: Removing/
adding a non-valuable
message transfer
Change 2: Removing/
adding a valuable
message transfer
Change 5: Changing
the message order
Figure 5.12: Relating constraints and changes
We use definitions and categorizations from previous sections.
Lemma 2. Assume the coordination model is intra-model consistent. Assume further
inter-model consistency. Then there is always a mapping between the abstraction of the
event log and the abstraction of the value model.
Proof: If there is no mapping there must either be a set in the event log not present
in the value model (Constraint 2 (1)), or there is a set in the value model not present in
the event log (Constraint 2 (2)).
Violation of (1) means the set in the event log has to be an occurrence of a set in the
coordination model due to intra-model consistency of the coordination model (Constraint
5). This set in the coordination model must have a matching set in the value model because
of inter-model consistency (Constraint 7). However, the set in the coordination model is
an occurrence of this set in the value model ⊥.
Violation of (2) means this set in the value model has to match a set in the coordination
model due to inter-model consistency (cf. Constraint 7). Due to intra-model consistency
of the coordination model this set must have an occurrence in the event log (cf. Constraint
5). If this set has an occurrence in the event log it will be an occurrence of the value model.
However, this contradicts our initial assumption ⊥.
Lemma 3. Assume the coordination model is intra-model consistent. Assume further
inter-model consistency. Then it is always possible to resolve intra-model inconsistency
98
5.11. RELATED WORK ON VALUE AND COORDINATION MODELS
of the value model by adapting the value model with an observable non-structural change
(Change 3 or 4).
Proof: If the coordination model is intra-model consistent, there is a mapping be-
tween event log and value model (cf. Lemma 2). If there is a mapping and an intra-model
inconsistency of the value model, this is due to Cause 3 (i.e., a mismatch in the esti-
mated number of occurrences) or due to Cause 4 (i.e., a mismatch in the average value
of a transfer) (Table 5.2). By transitivity, if the coordination model is intra-model consis-
tent, intra-model inconsistency of the value model can be solved through an observable
non-structural change.
Lemma 4. An observable non-structural change in the value model does not influence
inter-model consistency between value and coordination model.
Proof: If an observable non-structural change had influenced inter-model consis-
tency, it would influence the mapping between the abstractions of value model and coor-
dination model (Constraint 7). To influence this mapping, a non-structural change would
have to add or remove a set from the abstraction of value or coordination model (Con-
straint 6). A non-structural change (cf. Change 3 or Change 4 in Table 5.3) only adapts
values of elements in a quintuple and never influences sets. Therefore, a non-structural
change never influences inter-model consistency.
Using the results from Lemmas 2 - 4 we can now prove Theorem 1.
Theorem 1. Assume that the coordination model is intra-model consistent and that value
and coordination model are inter-model consistent. Then it is possible to solve intra-
model inconsistencies of the value model while preserving inter-model consistency be-
tween value and coordination model.
Proof: If assuming intra-model consistency for the coordination model, and inter-
model consistency, there is always a mapping from the value model to the event log (see
Lemma 2). Intra-model inconsistency of the value model can then be solved through an
observable, non-structural change (e.g., Change 3 or 4) (see Lemma 3). An observable
non-structural change does not influence inter-model consistency (see Lemma 4). By
transitivity: If coordination model is intra-model consistent, intra-model consistency of
the value model can be solved without influencing inter-model consistency.
By constructing such proofs, some possible changes are not considered when at-
tempting to regain consistency. By ruling out necessity of certain changes, the process
of adapting models to regain consistency becomes more efficient. Furthermore, investi-
gating formal properties improves our understanding of relations between value model,
coordination model and event log.
5.11 Related work on value and coordination models
Checking consistency. Several approaches for ensuring consistency between different
models at operational level exist. For example, Business Process Intelligence (BPI) aims
99
CHAPTER 5. MANAGING DEPENDENCY RELATIONS: BUSINESS AND
COORDINATION MODELS
at supporting business and its users in managing process execution quality. Grigori et
al. [59] acknowledge the importance of inter-model alignment. Recently efforts are made
to focus on the analysis of costs related to the use of BPI [84]. Here, Mutschler et al.
introduce two cost models. One model analyzes the Total Cost of Ownership, while the
other one analyzes the impact of BPI on Software Development Efforts. Although in BPI
quantifications are made and data is related to process models, BPI focuses on execution
quality and not on the overall performance of the cooperation. Another example is the
Astro-project [65] where business requirements and business processes are integrated into
one method to enable flexibility. Formal verification of, for example, consistency within
the method can be checked.
A well known approach for assessing business models is using Key Performance In-
dicators (KPIs). In respective approaches, KPIs are chosen as evaluation criteria for busi-
ness models. In Giaglis et al. [54] KPIs are used to overcome the problem of measuring
a priori the benefits of E-Commerce investments. The e-business is assessed by business
process simulation where users can experiment with different configurations. The result-
ing simulated values of the KPIs are compared with the estimated values in the process
models. A business decision is made based on this comparison. In our mechanism, the
profitability evaluation criterium can be considered a KPI.
Another approach is forecast modelling where a prediction on future behavior is made
based on current available data. These models are used for decision making. In Zhao et
al. [119] decisions on cooperative investments are supported using forecasting models.
Here, also simulation models are used for selecting proper forecasting models. However,
these approaches do not provide a business view on the dependencies of measured val-
ues. Furthermore, these approaches do estimations on the future rather than representing
observed behavior.
Another mechanism for adapting models during runtime is the use of reflection. Green-
wood et al. [58], for example, separate representation and enactment domains which re-
lates to our separation of design time and runtime environments. Their approach supports
ongoing transformations between both domains. The use of reflection allows generation
of new programs by another running program. This allows users to add new processes
to a running program. In Edmond et al. [43] reflection is applied for reusing, extend-
ing and customizing current processes. While these reflection-based approaches focus on
evolution of processes, they disregard monitoring the business from a value viewpoint.
Consistency through construction. Besides checking consistency between different
models, there exist constructive approaches guaranteeing consistency of the model de-
rived from another model. For example, in Andersson et al. [6] an approach is proposed
to use an intermediate model as a bridge between a business model and a process model.
The approach is based on identifying tasks needed to accomplish the consumer need and
to derive the interdependencies of these tasks. Andersson et al. [7] propose a chaining
method to derive from a business model a corresponding process model.
Another approach is suggested by Koehler et al. [69] who proposes a pattern based
approach to come from a business process model to a consistent implementation. Model
100
5.12. SUMMARY
checking techniques are used to automatically verify consistency. However, these con-
structive approaches focus mainly on inter-model consistency.
It is a big challenge in process management to support the modelling, monitoring and
maintenance of the relations between the different sub-processes [82, 83]. In this context
M¨
uller et al. consider consistency between data and process structures. Their COREPRO
framework provides mechanisms for maintaining data-driven process structures
In this thesis we discuss checking consistency between value and coordination mod-
els. However, there also exists work on ensuring consistency between value and coor-
dination models. For example, Wieringa et al. [114] describe a method for constructing
physical delivery models that describe the exchanges between partners in the real world.
These delivery models close the gap between value and coordination model and show in
this way how they are related.
Value modelling. Although value modelling for business models is getting more pop-
ular, modelling with a focus on value creation is used in other disciplines as well. For
example, in value based software engineering the focus is on value creation through soft-
ware development. Here, the importance of linking value models and software design is
recognized. Sullivan et al. [106] propose to use real options to link value and software
design. Boehm et al. [28, 27] develop a roadmap to add the concept of value creation to
modelling techniques and decision making related to software development. Furthermore,
they also acknowledge the challenge of relating technical models with value creation.
5.12 Summary
In this chapter we apply our method for managing dependency relations between models
for inter-organizational cooperations (cf. Chapter 4) to value and coordination modelling.
We show how to apply the different steps. Furthermore, we demonstrate that when using
this method it is possible to formalize different consistency constraints so that formal
properties of the models can be identified (cf. Section 5.10.4) and their implementation is
more straightforward. This case is illustrated with the use of a running example. Later,
in Section 10.3 we discuss the lessons learnt from applying our MaDe4IC method for
managing dependencies between inter-organizational models to the given case.
101
CHAPTER 6
PROOF-OF-CONCEPT IMPLEMENTATION: BUSINESS
AND COORDINATION MODEL
In Chapter 5 we illustrate the use of our MaDe4IC method for managing dependency
relations for inter-organizational models. In this chapter, we show how the results of
this analysis are implemented [25]. Here, we provide a mechanism to monitor and adapt
the value model using intra-model consistency constraints and dependencies identified in
Chapter 5.
We demonstrate the implementation by means of a running example which is dis-
cussed in Section 6.1. In Section 6.2 we discuss the formal consistency constraints that
are implemented. In Section 6.3 we discuss how the different parts of consistency con-
straints are implemented. Furthermore, we show in Section 6.4 how the implementation
is used to analyze consistency constraints and how to identify causes for inconsistencies.
We give a description on how monitoring and adaptation results are visualized in the
value model in Section 6.5. We conclude this chapter with an evaluation of the developed
method for managing business and coordination models in Section 6.6.
6.1 The business case
In this chapter we use a running example based on a real case in the health insurance sector
in the Netherlands for illustrating the implementation. We use a different example than
in the previous chapter since the structure of this case is more complex, and, therefore,
better suitable for validation purposes.
An insurance company provides insurance on an annual basis to its customers. Cus-
tomers pay premium on a monthly basis and claim refunds for received treatments. Every
paid refund by the insurance company is compensated by CVZ, a Dutch organization dis-
tributing tax money. CVZ gets its funding from the government. Next, we model this
scenario as value model and part of the scenario as coordination model.
CHAPTER 6. PROOF-OF-CONCEPT IMPLEMENTATION: BUSINESS AND
COORDINATION MODEL
6.1.1 Value model
For evaluating economic profitability of a cooperation, a value model is created. Our
business case, represented as e3-value model [57] (cf. Figure 6.1), is described in detail
in a technical report [22]. In this chapter we restrict to those constructs necessary for
illustrating the implementation.
The example from Figure 6.1 comprises four actors and eight value transfers. For
example, the value object premium is transferred from the customer to the insurance
company. Another value object, the insurance itself, is transferred from the insurance
company to the customer. In Figure 6.1 these two transfers are annotated with an ‘F’. A
combination of value transfers in one transaction is referred to as a value exchange. In
e3-value a distinction is made between different kinds of value objects. A value object is
either a product, service, money, or a ,consumer experience. In this example the premium
is a value object of type money and the insurance provided by the insurance company is
considered a service.
The consumer need is “having a health insurance for one year”. This is represented
by placing the start stimulus at the customer. The set of value objects that is transferred to
fulfill the consumer need, consists of all value transfers connected through the dependency
path in the model. Every month there are two possible sets of value transfers that fulfill the
consumer need. Either the customer claims restitution for treatments he paid for himself,
and he pays the monthly premium, or he only pays the monthly premium. When the
customer claims a restitution, the insurance company claims compensation from CVZ.
CVZ, in turn, gets its funding from the government. Also note that the health insurance
company has multiple customers, represented as market segment in Figure 6.1.
In Figure 6.1, the twelve monthly payments for fulfilling one consumer need are real-
ized by adding an explosion element, annotated with ‘A’ in the figure, associated with ratio
1 : 12. The choice between the two options for fulfilling the consumer need is represented
as OR-port. In e3-value an OR-port is an exclusive OR. After such an OR-port only one of
the dependency paths is selected. If the customer has not received treatments that month,
the path annotated with ‘C’ is chosen. The two resulting value transfers constitute the first
set of transfers that fulfill the consumer need. Otherwise, if the customer receives treat-
ment that month, the path annotated with ‘D’ is chosen. This path further splits through
an AND-split, representing a parallel occurrence of two or more dependency paths. In
an AND-join, in turn, all incoming dependency paths share the continuation of the de-
pendency path. The two value exchanges between customer and insurance company take
place. To enable more than one restitution claim per month another explosion element,
annotated with ‘B’, is added. The insurance company claims restitution from CVZ. These
value transfers constitute the second set of value transfers. Finally, the dependency path
starting within CVZ represents the third set of value transfers.
The quantifications (not shown in Figure 6.1) that are associated with the graphical
representation of the value model, provide estimations. The market segment, for exam-
ple, is quantified by estimating the number of customers. Also ratios on the explosion
elements and the OR-split are set. For every monetary value transfer a quantification is
104
6.1. THE BUSINESS CASE
Figure 6.1: Example case: Business model (e3-value notation)
given in the profitability sheets. The expected revenue for every actor in the model is
calculated.
6.1.2 Coordination model
A coordination model depicts how the transfer of value objects between the parties is
realized. In particular, it describes the order in which messages between parties are ex-
changed. An ordered set of messages is referred to as execution sequence. This ordering
information is omitted in the value model.
Since we do not implement the coordination model, we only depict a small part of
the business case as Petri Net [64] in Figure 6.2. However, [21] provides a detailed de-
scription of the business case as well as the model represented as Petri Net. Figure 6.2
represents coordination of the payment process of a customer to the insurance company
for having insurance for one year. This part of the coordination process is related to the
value exchange of premium and insurance in the value model, annotated with ’F’ in Fig-
ure 6.1. The money value transfer premium is represented as message exchange in the
coordination model. This is not the case for the service value transfer insurance, since
services do not instantiate explicit message exchanges.
Places (indicated as circles) can hold any number of tokens (represented as black
dots), and transitions (indicated as squares) act on input tokens by firing. Message ex-
changes are represented as places, and tasks as transitions in the coordination model.
Places and transitions are connected through arcs. These arcs indicate the ordering of
tasks and message exchanges. In Figure 6.2 the customer first does a payment through
executing task Pay, after which message Premium, place p3 in Figure 6.2, is transferred
from customer to insurance company.
105
CHAPTER 6. PROOF-OF-CONCEPT IMPLEMENTATION: BUSINESS AND
COORDINATION MODEL
12
12
12
12 x = # arcs
p1
Customer
End
Insurance
Company
Start
Transition
Place
x
Initiator
p2
p3: Premium
p5
p4
Pay Process
Terminate
Figure 6.2: Example case: Coordination model (Petri Net notation)
6.2 Consistency constraints
In the proof-of-concept implementation we consider intra-model consistency constraints
for the value model. In Section 5.7.1 we define intra-model consistency constraints for
the value model. These constraints specify when the value model is considered to be
consistent with the running system. We check this by analyzing the event log that captures
essential events of the cooperation. The first constraint is that business transactions in the
model have to be reflected in the event log, and vice versa (cf. Section 5.7.1, Constraint 2
page 84):
Constraint (Business transaction, value model).The value model is intra-model consis-
tent if:
1. Each set (representing one business transaction) in the event log matches a set
of value transfers representing a business transaction in the value model for the
specified time frame.
2. Each business transaction in the value model occurs as a business transaction in
the event log for the specified time frame.
Secondly, the number of occurred value transfers in the event log has to be equal to
the estimated number of occurrences in the value model. If, for example, the estimated
number of treatments is twice as high as the realized number of treatments, model and
event log are not consistent (cf. Section 5.7.1, Constraint 3 page 85):
Constraint (Number of occurrences).For each business transaction in the value model
the estimated number of occurrences is the same as the realized number of business trans-
actions in the event log during the specified time frame.
Furthermore, the average value of transferred messages has to be equal to estimations
in the value model. If, for example, the average value of paid premium is lower than the
106
6.3. IMPLEMENTATION
estimated average premium, model and event log are not consistent with each other (cf.
Section 5.7.1, Constraint 4 page 85):
Constraint (Average value).The estimated average value of the transfers in each busi-
ness transaction of the value model is the same as the realized average value of this
transfer in the event log for the specified time frame.
Constraints for matching number of occurrences and average value of the transfers
are in this chapter more precisely defined for implementation:
Constraint 8. A value model is δconsistent at time t if for all exchanges x in the event
log representing value transfers y in the value model it holds that:
(i) the average number of realized x between time t −δand t (δ > 0) is equal to the
number of estimated occurrences of y, and
(ii) the average value of x between time t −δand t (δ > 0) is equal to the estimated
value of y.
Now, consistency checking is based on calculating averages over period of time δ.
Model and event log are consistent with each other if the average value and the average
number of occurrences are consistent during that period of time.
6.3 Implementation
δ-consistency forms the basis of our approach on relating value model and event log. We
use data from the event log as feedback information for the value model. The value model
is actively adapted during runtime using data perceived from the monitoring process. This
approach provides a mechanism for monitoring the business from a value perspective and
adapting the model accordingly.
Item (ii) of Constraint 8 addresses the average value of each transfer. The average
value of each transfer is represented in the event log. The monitored value of transfers is
compared with estimations made in the value model. This is described in Section 6.3.1.
Sections 6.3.2 and 6.3.3 concern item (i) of Constraint 8. The event log contains
information about messages exchanged between actors. These messages, in turn, hold
information on the number of value transfers that occur between actors. For using this
information in evaluating the value model, a correlation between model and event log and
their constructs is established. When constructing the value model, several estimations
are made regarding behavior of the system like consumer needs and ratios on explosion
elements. The estimated number of value transfer occurrences is based on these estima-
tions. An equation system is derived which comprises formulas for calculating the number
of occurrences based on used constructs in the value model. Data from the event log is
entered into the equation system. When solving the equation system with these values
there may be free variables representing the ratios. These are shown in a Graphical User
Interface.
107
CHAPTER 6. PROOF-OF-CONCEPT IMPLEMENTATION: BUSINESS AND
COORDINATION MODEL
Figure 6.3: Example case: Realized and estimated average value of transfers
After adaptation of the ratios in the e3-value model, these results are graphically rep-
resented together with the result of monitoring value of the transfers. In the following
sections, the different parts of the approach are explained in detail, and illustrated on
behalf of our example business case.
6.3.1 Average value of transfers
The value of transfers is monitored in the event log. Figure 6.3 represents estimations
made on the value of each transfer as well as the monitored average of each value transfer.
We monitor the average value of each transfer by calculating the moving average. Since
we assume for the given example the customer has constant behavior over time, we are
able to use time series. Every quarter the average value of a transfer over the preceding
year is calculated. Using a moving average results in a smoothly changing average over
the time series. Figure 6.3 depicts measurements in quarter Q4 of 2005, quarter Q1 of
2006 and quarter Q2 of 2006, annotated with T1, T2 and T3, respectively. For calculating
the realized average value of a transfer over a year, each quarter average is multiplied by
the number of realized transfers, and the total is divided by the total number of realized
transfers over that year.
6.3.2 Average number of transfers
During runtime, we monitor the process by calculating the moving average as depicted
in Figure 6.4. In the figure, the number of message transfers as observed at different
times during execution is depicted. In our example every quarter the averages over the
preceding year are calculated. Figure 6.4 depicts measurements in quarter Q4 of 2005,
quarter Q1 of 2006 and quarter Q2 of 2006, annotated with T1, T2 and T3, respectively.
These message exchanges are correlated to value transfers in the value model.
6.3.3 The equation system
The equation system enables calculating the number of occurrences through formulas
based on constructs in the value model. The equation system of a value model is de-
108
6.3. IMPLEMENTATION
Figure 6.4: Example case: Realized and estimated average number of transfers
rived with an algorithm. The value model is represented as a graph where vertices rep-
resent constructs and edges represent parts of dependency paths. The equation system
is constructed by assigning variables to each part of the dependency path between the
different constructs of the value model. The equations in the system are related to each
other through these variables. When two constructs are directly connected through a de-
pendency path, the variable used in the equations of both constructs is the same. The
algorithm is as follows:
Assign to each edge an unique variable. For each vertex determine the edges
and associated variables. Represent each vertex as equation based on the
equation system in Table 6.1. Instantiate the unique variables with the as-
signed values.
For each construct in the value model a formula exists in Table 6.1. For example,
in Figure 6.1 there is one dependency path which enters an OR-split whereas two paths
leave this element. For the fulfillment of a consumer need, only one of the outgoing paths
is chosen. In the profitability sheets an estimation is made on the relation between the
number of times each path is chosen. In the table this is indicated by rand s, stating
path yis chosen rtimes, and path zis chosen stimes. The resulting formula states the
estimated number of times path yis chosen is equal to the number of times dependency
path xoccurs times the ratio on the OR-split, namely r
r+s.In e3-value an OR-port is an
exclusive OR.
For the OR-join the number of occurrences of both incoming paths is added up.
For the AND-join as well as for the AND-split, the number of occurrences on each
part of the dependency path is the same. An implosion or explosion element multiplies
the number of occurrences with ratio s
rassociated with the port.
The number of occurrences on outgoing path xof a start-stimulus equals the number
of occurrences of consumer need ytimes the number of actors zin the market segment.
The number of occurrences on stop-stimulus y equals the number of occurrences of
incoming dependency path xtimes the number of actors zin the market segment. When
the market segment consists of a single actor the value of zequals 1.
109
CHAPTER 6. PROOF-OF-CONCEPT IMPLEMENTATION: BUSINESS AND
COORDINATION MODEL
OR-split: Start:
y=r
r+sxx=yz
z=s
r+sx
OR-join: Stop:
y=x+z y =x
z
AND-split: Transfer:
y=x y =sx
z=x z =tx
AND-join: Expl impl:
y=x y =s
rx
y=z
Table 6.1: Implementation: Equation system
Formula Transfer in Table 6.1 states the outgoing number of value transfers yis equal
to the number of occurrences xtimes ratio s, and the incoming number of value transfers
zis equal to the number of occurrences xtimes ratio t. This ratio represents, for example,
several payments for receiving one value object.
We illustrate our implementation by deriving the equation system for the customer.
Figure 6.5 depicts the customer with ratios and introduced variables as used for the equa-
tion system. Since this example is for demonstration purposes only, we consider the
customer to be a single actor and assume there is no ratio on the value interfaces. Next,
the resulting equation system, without pure renaming, is represented. For a synoptic rep-
resentation of the graphical user interface, the ratio on the first explosion element, s
r,is
referred to as fraction f1and the ratios on the OR-split, u
t+uand t
t+u,are referred to as
fractions 1−f2and f2, respectively. The ratio on the second explosion element, n
mis
referred to as fraction f3.
•x1=f1zwith f1=s
r
•x2=(1 −f2)x1with 1−f2=u
t+u
•x3=f2x1with f2=t
t+u
•x5=x3
•x4=x3
•y=x4+x2
110
6.4. MANAGING THE VALUE MODEL
Figure 6.5: Example case: Customer ratios and introduced variables (e3-value notation)
Estimated T1 T2 T3
Numbers
x900 850 800 900
y600 600 550 650
z50 z z z
f112 600
z
550
z
650
z
f23
4
17
12 f3
16
11 f3
18
13 f3
f32f3f3f3
Table 6.2: Implementation: Realized and estimated customer values
•x=f3x5with f3=n
m
6.4 Managing the value model
In the value model estimations are made for the number of consumer needs and differ-
ent ratios of the constructs. Based on these estimations, the estimated number of value
transfers is calculated. In Table 6.2 entries in: ‘Estimated Numbers’-column depict these
estimations and calculations. Information from the event log is correlated with value
transfers, and results in three different times, T1, T2, and T3, depicted in Table 6.2. The
observed average of message exchanges during monitoring might deviate from estima-
tions made in the value model. For example, measurements on the number of value trans-
fers xat time T1, namely 850, deviate from the estimated number of value transfers xin
the value model, namely 900. This result makes value model and event log δinconsistent
according to Constraint 8.
When the value model is not δ-consistent with the event log, one or more of the es-
timated ratios in the value model might be adapted to make regain consistency. Entering
results of the event log into the equation system as derived from the value model while
keeping ratios as free variables, and solving the equation system have two types of solu-
tions.
111
CHAPTER 6. PROOF-OF-CONCEPT IMPLEMENTATION: BUSINESS AND
COORDINATION MODEL
Figure 6.6: Proof-of-concept implementation: Graphical user interface
In the first case the equation system is over-specified and there is no or just one so-
lution to the equation system, in which case there is no necessity for a graphical user
interface. In the second case the equation system is under-specified leaving a possible
infinite number of solutions. In the latter case, representing the options in a graphical user
interface allows the user to dynamically set the different ratios and visualize the effects
on the value model. The visualization is important for evaluating the economical value of
the business during runtime.
An example of this graphical user interface is depicted in Figure 6.6. Here, results of
the event log at time T2 are depicted. If the user chooses a free variable to set, and enters
this value into the user interface, the equation system is reevaluated. The results, possibly
still with free variables, are again represented in the graphical user interface. After setting
all free variables, the ratios are adapted in such a way that value model and event log are
one year consistent.
6.5 Visualization
In this chapter only one actor in a simplified business case is evaluated. Real-life business
constellations, however, are more complex, and potentially consist of many constructs.
Adapting one of the ratios in the value model might influence many other ratios and
estimations in the value model. These effects are visualized by automatically adapting
112
6.5. VISUALIZATION
colors of the constructs according to adaptation of the ratios. The user can directly see
what the effects are of adapting one specific ratio on the entire business constellation.
Here, effects of entered values in the value model, compared to the original estimated
values of the value model, are calculated, classified and represented by an appropriate
color. In the example a construct is colored green if the entered or calculated ratio matches
estimations in the value model. A construct is colored dark green if the ratio deviates less
than 8.5% from the estimated value, and it is colored red if the ratio deviates over 8.5%
from estimations in the value model.
In Figure 6.7 examples of value-model coloring for time series T2 from Figure 6.4 and
Figure 6.3 are given. Figure 6.7 (a) shows the value model after entering results of T2.
The average value of transfer x, a restitution, is in timeseries T2 52.16 (cf. Figure 6.3).
This is more than 8.5% deviation from estimated value 47. Therefore, the lines of value
transfer xare colored red. The average value of transfer yin timeseries T2, premium,
is 131.33. This is less than 8.5% deviation, and, therefore, the lines of value transfer y
are colored dark green. The average number of occurrences of xin T2 is 800, while the
estimation in the value model for xis 900 (cf. Figure 6.4). Deviation between realized
number of value transfers xand the estimated amount is greater than 8.5%, and, therefore,
the interface is colored red. The realized number of yis 550, while the estimated number
is 600. Deviation is less than 8.5%, therefore, the interface is colored dark green. The
remaining variables are still open and, therefore, grey.
Figure 6.7 (b) depicts the situation after setting ratios for f1. f1 denotes the number of
payments each customer makes for having insurance for one year. Since each customer
pays every month its premium, this is a fixed ratio of 12. When choosing which ratios to
adapt in the value model, f1 is not chosen since it is fixed. Therefore, this ratio is first set in
the graphical user interface. After entering value 12 for variable f1, the explosion element
colors green. This indicates the estimated ratio of 1 : 12 is equal to the realized ratio. As
a consequence, the realized number of consumer needs, z, is 45.8. The estimated number
of consumer needs is 50. The deviation is within 8.5%. Therefore, the start stimulus is
colored dark green.
In Figure 6.7 (b) a possible final marking is depicted. If we assume there is additional
information available on the percentage of customers that use the possibility of asking
restitution in a month, ratio f2 can be set. We assume this ratio is 70%. The deviation
between the estimated ratio of 75% and the realized ratio of 70% is lower than 8.5%.
Therefore, the OR-port associated with f2 is colored dark green. As a result, f3 is assigned
a value of approximately 2.1 which is also within the 8.5% deviation. The explosion
element associated with ratio f3 is colored dark green.
The conclusion from these results is that less people ask for a restitution on a monthly
basis, but if a customer asks for a restitution, he asks more restitutions than estimated.
This is indicated by the slightly increased ratio on f3.
113
CHAPTER 6. PROOF-OF-CONCEPT IMPLEMENTATION: BUSINESS AND
COORDINATION MODEL
(a) (b) (c)
Figure 6.7: Proof-of-concept implementation: Coloring the value model
6.6 Evaluation of our developed management approach
For our consistency definitions we make some assumptions that influence the way con-
sistency between models is maintained. These assumptions are fairly strict. For example,
each business transaction in the business model must have a matching business transac-
tion in the coordination model, and vice versa (cf. Constraint 1). This is a strict constraint
because it only considers models to be consistent with each other if they describe the
exact same situation, and nothing in addition. In other words, if model A describes all
business transactions present in model B and an additional business constraint not present
in model B, then these models are not considered to be consistent with each other accord-
ing to Constraint 1. In practice, developers might not consider this an inconsistency since
the models do not actually contradict. Model A simply contains more information than
model B. Another example of strict consistency as defined in this chapter is consistency
of models with the running system (i.e., intra-model consistency, cf. Constraints 3, 4,
and 6). Here, models and running system are considered consistent with each other if and
only if the running system behaves exactly as modelled. Slight deviations in, for example,
selling costs or the order of messages, are considered an inconsistency. In real life, de-
velopers might choose to weaken these strict consistency rules by, for example, allowing
slight deviations in behavior, or by allowing additional business transactions.
In Sections 6.4 and 6.5 we demonstrate the applicability of the developed approach
using our method for managing inter-organizational models. To our knowledge, there
do not exist any comparable approaches for managing business and coordination models.
More particularly, there do not exist approaches that support runtime management of these
models. Therefore, we conclude that our approach to managing business and coordination
models is an improvement to existing related work.
6.7 Summary
In this chapter we show how consistency constraints between a model and running system
are implemented and used to manage the model. More precisely, we show how to imple-
114
6.7. SUMMARY
ment the intra-model consistency constraint of the value model, and how to monitor this
constraint at runtime using the event log. In addition to implementation of the constraints
and monitoring of the model, we also depict how to use this information for managing
the model at runtime. More particularly, we show how to visualize deviations between
estimations in the value model and runtime results in the event log. By adding to this the
intra-model dependencies of the value model, we enable dynamic adaptation of the model
while directly showing consequences of these adaptations for other parts in the model.
115
Part IV
SCENARIO 2: SERVICE LEVEL
AGREEMENTS FOR COMPOSITE
SERVICES
CHAPTER 7
MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
For a business operating in a networked environment it is vital to accurately manage ser-
vices it provides to its customers. This is particularly challenging if a company offers
composite services where interactions with services offered by other providers influence
its performance. The quality of service (QoS) that can be offered to customers is calcu-
lated taking all these dependencies into account [63, 33]. Consider a composite service
which returns combined information from several search engines. In this case, the qual-
ity of service (e.g., response time) that can be offered depends on the quality of service
delivered by the search engines. Together with constraints the customer has regarding the
service, these calculations form the basis for a Service Level Agreement (SLA) between
customer and service provider [66, 100].
Several approaches exist for monitoring the service level during runtime (e.g., Tosic
et al. [109]). Monitoring results are compared with constraints specified in the SLA for
possible violation detection. Since SLAs are typically bilateral agreements, current mon-
itoring approaches (e.g., Sahai et al. [100], Keller et al. [66], Tosic et al. [109]) focus on
identifying violations in bilateral communication. Important research questions in this
area are, for example, how to gather reliable data, how to structure these data, and how to
combine data from different sources. Such monitors are often process-specific, activated
or created if a service is invoked, and terminated if the service is completed.
Most approaches for managing composite services combine the level of quality a com-
pany provides, with monitoring bilateral communication. However, to properly manage
its composite service a company has to reason about causes of SLA violations. For exam-
ple, if the offered response time for a composite service provided by a company depends
on response times of other services this company uses, it is vital to identify and moni-
tor these dependencies. Exactly these dependencies are ignored in bilateral monitoring
approaches. However, combining bilateral monitoring results based on their dependen-
cies is, as we discuss in this chapter, highly challenging. With our MaDe4IC method for
managing dependency relations in inter-organizational models (cf. Chapter 4) we develop
the MoDe4SLA approach (MOnitoring DEpendency relations for SLAs) [23]. With this
approach, we analyze during development phase different types of dependencies between
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
Dependency
analysis Log
analysis
SLAs
Service composition
Dependency
trees
Logs
Performance
trees
Figure 7.1: Overview: MoDe4SLA approach
services, and the impact these services have on each other. Further, it allows to combine
bilateral monitoring results with analyzed dependencies and impact services have on the
composition.
With MoDe4SLA we allow monitoring dependencies between SLAs, enabling de-
cision support when managing composite services. Figure 7.1 gives an overview of
MoDe4SLA. We first analyze dependency relations (cf. Step 3 in Section 7.4). The
relations are used to perform an event log analysis (cf. Step 8 in Section 7.9) to determine
causes for SLA violations in composite services.
The remainder of this chapter first discusses basics of SLAs and introduces our run-
ning example in Section 7.1. In the following sections we discuss every step in applying
our MaDe4IC method to our running example (cf. Sections 7.2-7.10). We conclude this
chapter with a discussion of related work on managing services and SLAs in Section 7.11.
7.1 Basics
In this section we discuss basics on SLAs and on the business case we use to illustrate our
approach.
7.1.1 Service Level Agreements
Our approach aims at supporting a company in managing its composite services by iden-
tifying and monitoring their dependencies to services requested from other providers.
These dependencies are explicitly represented in a dependency model. SLAs describe
constraints on the service. For example, there might be a constraint on response time of
a service. For each of these constraints in the SLA of a composite service, services it
depends on are identified. An SLA typically consists of a set of Service Level Objectives
(SLOs) which contain guaranteed quality constraints [66, 100]. A typical example of such
an SLO is:
In 90% of all cases, invocation of service X will have a response time within
y milliseconds (ms).
Each of these SLOs is measurable, and consists out of one or more metrics. Such
metric may be composite as well, e.g., a composite metrics might be the average response
120
7.1. BASICS
time over all customers in a month. Furthermore, these SLOs typically hold a validity
time constraint, for example, “Mo-Fri 9:00-17:00”.
Offering a composite service to customers implies a company relies on content providers
to offer necessary data. Both customers and content providers have an SLA with the com-
pany. We propose to explicate for each SLO on which other services its overall perfor-
mance depends (cf. Figure 7.1). Different SLOs in one SLA might depend on different
services, or depend on them in different ways. For example, if a company offers informa-
tion with fast response time by querying five providers, and returning information of the
fastest responding one, a cost constraint is influenced by all five services (due to invoca-
tion they all have to be paid), while a response time constraint is only influenced by the
fastest responding service.
Furthermore, we demonstrate how to calculate the impact a service has on a depend-
ing composite service. Assume, for example, the cost constraint on a composite service
depends on service A and service B, where service A costs on average ten times more
than service B. Now, the cost impact of service A on the composite service is ten times
higher than the one of service B. Based on the dependency model we calculate the impact
a service has on the composition. We do this by means of an impact analysis.
Data on messages exchanged between customer and provider are gathered in event
logs. These event logs enable monitoring of SLOs and their dependencies based on these
data. We abstract and structure necessary data from event logs to enable evaluation and
monitoring of SLOs. For decision support in managing composite services, we combine
dependencies, calculated impact factors and bilateral monitoring results into one model
that graphically represents these relations. Next, we show how to accomplish this, using
the MaDe4IC method described in Chapter 4.
7.1.2 Business case
We demonstrate our approach by means of an intuitive example in which a company
offers two composite services to its customers. SubscribedNews is a composite service
where customers automatically receive a news report. This report is created by combin-
ing news items on personal interest (e.g., stock market information) from two different
news providers. Customers pay a flat fee for this service. NewsRequest, in turn, is a
composite service which allows customers to request up-to-date news information on a
specific search query. The NewsRequest service is paid per invocation. For every re-
quest the company invokes two content providers, and sends information from the fastest
responding to the customer.
To offer the SubscribedNews service to its customers, the company automatically re-
ceives data (i.e., news items) from its content providers (i.e., news providers). This data
is stored in a database from which the company retrieves data when composing the news
report for its customers. The company has an SLA with both content providers and cus-
tomers. Furthermore, providing the news report for customers does not trigger a service
invocation by the company to the content providers for data, since up-to-date data is re-
trieved from the database. Therefore, obtaining data from content providers and sending
121
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
SLA SubscribedNews, Company & Customer. January 1, 2008 - June 30, 2008
SLO-cost: Company will deliver SubscribedNews on a monthly average of less than 1
euro per service.
SLO-time: Company will deliver SubscribedNews once a day before 9:00 am, Mo-Fri.
SLA NewsUpdate, Company & CP1. January 1, 2008 - June 30, 2008
SLO-cost: CP1 will deliver NewsUpdate for 0.50 euro per news item, with a maximum
of 50 euro per day.
SLO-time: CP1 will deliver NewsUpdate to Company once a day, 7 days a week before
6:00 am.
SLA NewsUpdate, Company & CP2. January 1, 2008 - June 30, 2008
SLO-cost: CP2 will deliver NewsUpdate for 0.30 euro per news item, with a maximum
of 39 euro per day.
SLO-time: CP2 will deliver NewsUpdate to Company once a day, 7 days a week before
6:00 am.
Table 7.1: SLAs for the SubcribedNews service
reports to customers are different processes (i.e., invocations). However, response time
performance for offering NewsRequest is highly dependent on response time of the ser-
vice provided by the content providers. As a result, SLA violations between the company
and its providers might result in SLA violations in the service provided by the company
to the customer, which cannot be identified using a bilateral monitoring approach. For
example, if the content provider never meets the response time constraint, the company
most likely will also not be able to meet the response time it agreed upon with the cus-
tomer. Therefore, it is highly important for a company to not only monitor SLA violations
for each metric, but also their dependencies on the same metrics in other SLAs to identify
causes for SLA violations.
A composite service depends on one or more other services. In our example, Sub-
scribedNews and NewsRequest both depend on two other services offered by different
content providers. In our approach, we specify on which services the fulfillment of a spe-
cific SLO depends and how it depends on these services. The SLOs for cost and response
time, specified in SLAs of the company with its content providers (CP1 and CP2) and cus-
tomers are depicted in Tables 7.1 and 7.2. Note that we do not provide a specification lan-
guage for SLAs (like WSLA Framework [66] or the SLA language by Sahai et al. [100]).
Instead our approach focusses on conceptual issues, i.e., it is language-independent.
From Monday to Friday before 9:00 am ,the company delivers news items the cus-
tomer is interested in. The price is not higher than 1 euro, and depends mainly on the
number of news items that fit the requirements of the customer. With its content providers
the company agreed to deliver daily all news items for a fixed price per item with a max-
imum of, respectively, 50 and 39 euro per day. These news items are delivered before
6:00 am. Regarding the NewsRequest service the customer can request news on a specific
topic. These requests costs 0.50 euro. If the customer has more than 100 requests per
122
7.2. STEP 1: MODEL ANALYSIS
SLA NewsRequest, Company & Customer. January 1, 2008 - June 30, 2008
SLO-cost: Invocation NewsRequest by Customer will cost the first 100 times in a month
0.50 euro, thereafter 0.40 euro.
SLO-time: Company will respond to NewsRequest invocation by Customer within 5 ms,
99% of the time.
SLA Request,Company & CP1. January 1, 2008 - June 30, 2008
SLO-cost: Invocation Request by Company will cost 0.20 euro.
SLO-time: CP1 will respond to Request invocation by Company within 3 ms, 99.9% of
the time.
SLA Request,Company & CP2. January 1, 2008 - June 30, 2008
SLO-cost: Invocation Request by Company will cost 0.15 euro.
SLO-time: CP2 will respond to Request invocation by Company within 4 ms, 99% of the
time.
Table 7.2: SLAs NewsRequest
month, price per invocation decreases to 0.40 euro. In 99% of all cases a request is re-
sponded to within 5 ms. The company, in turn, invokes services of two content providers
for every NewsRequest, and sends data from the fastest responding provider to its cus-
tomer. Content provider CP1 responds within 3 ms for 0.20 euro to an invocation by the
company in 99.9% of all cases. Content provider CP2 responds within 4 ms for 0.15 euro
to an invocation by the company in 99% of all cases.
We use this business case to illustrate the steps of applying our method to SLAs in the
following sections.
7.2 Step 1: Model analysis
In Step 1 of our modelling method we analyze models for their characteristics. First,
recall the model characteristics identified in this method (cf. Section 4.3):
(i) Focus: Viewpoint ↔Partial model
(ii) Perspective: Single actor ↔Bird’s eye view
(iii) Property type: Estimation ↔Prescription
(iv) Time frame: Instance-based ↔Period of time
By applying this analysis to our business case we obtain the following results. Each
SLA contract constitutes a partial model that has a bird’s eye view. Furthermore, each
contract specifies an agreement on costs and response time which are both prescribed
property values. Each contract describes a period of time, namely January 1, 2008 - June
30, 2008:
123
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
SLAs
Focus partial model
Perspective bird’s eye view
Property type prescription
Time frame period of time
7.3 Step 2: Homogenization
In Step 2 we homogenize the models (i.e., the SLAs) on three levels (syntactic, semantic,
and pragmatic) in order to make them comparable.
Syntactic homogenization. The SLAs are written in natural language and have a simi-
lar structure. Commonly used characteristics are:
•name of the service,
•issuer and recipient of the service,
•period of time, and
•set of SLOs.
Each SLO, in turn, either considers cost or response time, and typically contains the
following characteristics:
•period of time, and
•property value (i.e., costs or response time).
Each SLO connects the considered period of time and the property value using con-
structs like:
•less than,
•maximum of,
•before time, and
•per instance.
Semantic homogenization. The models in this chapter are built in such a way that they
are semantically homogeneous by construction.
Pragmatic homogenization. With pragmatic homogenization we consider five differ-
ent aspects. Some of them are homogenized, while for others heterogeneity is identified
in this step and handled in the following steps (cf. Section 4.3, Step 2).
•Focus. The focus of each SLA is a partial model focus. Therefore, the models are
homogeneous concerning their focus.
124
7.4. STEP 3: INTER-MODEL RELATION DETECTION
•Perspective. Each perspective is a bird’s eye perspective. Therefore, the models are
homogeneous concerning their perspective.
•Granularity. The models are specified on the same level of granularity by construc-
tion.
•Time frame. Each contract is defined for the same period of time, namely, from
January 1, 2008 - June 30, 2008. Furthermore, most time frames within the SLOs
are compatible. For example, in SubscribedNews, each cost SLO is defined per
service. However, the cost SLOs of NewsRequest do not match. More specifically,
the cost SLO for invoking NewsRequest by the customer is defined for the first 100
services, and for every following service separately. Both cost SLOs for invoking
service Request by the company are defined per service. As discussed, such hetero-
geneity cannot be homogenized. Therefore, we handle this by considering average
cost of the service. For example, if 150 NewsRequests are done by the customer,
the average cost of one invocation is as follows: 100×0.50+50×0.40
150 =0.47.
•Property type. Both cost and response time are agreed upon and therefore forced
values. There is no need for homogenization.
The main results of Step 2 are the following:
•Time frame differences between SLOs are solved by considering average costs
of each service invocation,
•All models (i.e., SLAs) are syntactically and semantically homogeneous.
7.4 Step 3: Inter-model relation detection
In Steps 1 and 2 we analyze the models to prepare them for comparison. In Step 3 we de-
tect dependency relations between the different SLAs. These relations allow us to define
consistency constraints between the models in Step 4.
As discussed in Step 3 in Section 4.4.2, the first step in identifying inter-model re-
lations between partial models is to identify their interconnections. Each partial model
describes a different part of the cooperation. For example, there is a relation between
the SLA for SubscribedNews and the two SLAs for NewsUpdate. This common model
describing how the different model parts are related, is in this specific context the service
composition.
The different SLAs are connected through their properties (i.e., SLOs). Each SLA
describes both cost and response time properties. Therefore, relations between SLAs (i.e.,
inter-model relations) are property dependencies. Since the news report created when
invoking SubscribedNews is dependent on both NewsUpdate services while these services
are not dependent on SubscribedNews, there exists an asymmetric property dependency
between the services. The same holds for the NewsRequest service that depends on both
Request services.
125
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
#Construct Explanation
1
A B
Service A depends on service B
2
AND
AND-split/join
3
XOR
XOR-split/join
4
x
Reuse is X times
Table 7.3: Cost dependency model constructs
Next, for cost and response time we analyze separately the dependency relations.
Cost dependency relations. Both examples (i.e., SubscribedNews and NewsRequest)
contain one SLO depicting a cost constraint (cf. Table 7.1 and 7.2). Here, for both exam-
ples we construct the cost model. We introduce a domain-specific modelling language for
expressing cost dependencies that enables depicting all necessary details while keeping
a high level of abstraction. This enhances readability and decreases necessary modelling
effort. Our language uses the constructs depicted in Table 7.3. We model that meeting a
constraint for one service depends on performance of another service (i.e., property de-
pendence). Using the AND-split it is possible to model meeting constraints for one service
depends on two or more different services. Furthermore, by using XOR-splits exclusive
choices are modelled (i.e., the service depends on one out of a set of services) with the
possibility to add a ratio on the likelihood of choosing one of the options. As last mod-
elling construct it is possible to denote reuse of data provided by a service. Such a reuse
construct depicts how often results of one service invocation are reused.
Figure 7.2 shows on which services the cost of SubscribedNews and NewsRequest
depend, and how these dependencies look like. The cost of composite service Subscribed-
News is dependent on the cost of NewsUpdate provided by CP1 and CP2, indicated with
an AND-split (cf. Figure 7.2). Moreover, NewsUpdate data is used more than once (i.e.,
the company sends more than once the same data to different customers). This reuse is
estimated to occur 100 times for data from CP1 and 80 times from CP2 (cf. Figure 7.2).
Note that data from CP1 are more often reused than data from CP2 because the former
are also used in another unrelated service offered by the company.
The cost of composite service NewsRequest is dependent on costs of both Request
services provided by CP1 and CP2. This is again indicated with an AND-split (cf. Figure
7.2). So, even though the customer only receives data from one service provider, he pays
for fast delivery, namely the cost of invoking two content providers. Data for a news
request are not reused.
Response time dependency relations. SubscribedNews and NewsRequest both con-
tain an SLO with a time constraint (cf. Tables 7.1 and 7.2). Next, we introduce the
domain-specific response time model for both examples. Apart from the constructs used
in modelling cost dependencies, also the order in which services are executed is relevant
126
7.4. STEP 3: INTER-MODEL RELATION DETECTION
AND
CP1
CP2
Customer
Company
News
Update Sub
scribed
News
100
80
News
Update
(a) SubscribedNews
AND
CP1
CP2
Customer
Company
Request
News
Request
Request
(b) NewsRequest
Figure 7.2: SubscribedNews and NewsRequest: Dependency cost model
#Construct Explanation
1
A B
Service B depends on service A.
Also: serial execution of services.
2 AND-split: parallel execution.
3 XOR-split.
4
DB
nn
n
Database (DB) with reuse of data.
Table 7.4: Response time dependency constructs
for response time. For example, if services on which the composite service depends are
executed in parallel, response time is faster compared to serialized execution. Workflow
modelling techniques (e.g., YAWL [4]) are highly suitable for modelling response time
dependencies, allowing for the ordering of messages. In this chapter, we use Coloured
Petri Nets (CPN) [64] for defining these models. Table 7.4 depicts the requirements for
Petri Nets. The first (1) construct in the table depicts how serialization is modelled. By
serializing the execution of two services (e.g., service A precedes service B) we express
that service B depends on service A. In other words, service B is only executed after
service A. The second (2) construct depicts how we model parallel execution of two or
more services. The third (3) construct depicts how we model an exclusive choice operator
(XOR-split) using Petri Nets. The fourth (4) construct depicts modelling a database. This
construct allows to store information created when invoking a service. The information is
reused in other services. We illustrate how requirements are modelled. Note that by using
Petri Nets these might be modelled in different ways.
Response time for SubscribedNews is dependent on NewsUpdate services of both
CP1 and CP2 (cf. Figure 7.3). The CPN depicts how CP1 and CP2 send data (iand j,
respectively) that are then stored in the database of the company (kand l, respectively).
Both content providers send their identification (CP id)together with content (i.e., news
items, Cid). The company adds this information to the database while inserting a primary
127
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
i i
[i={CP_id, C_id}]
[j={CP_id, C_id}]
jj
CP2
CP1 Company
Customer
Send
data
Send
data In DB
In DB
k
[k=i U {DB_pk}]
[l=j U {DB_pk}]
l
Request
info DB
[i=S_id]
i
Retrieve
info
i
m
m[n=m U i]
n
nn
Send
info
Receive
info
n
Database
NewsUpdate
NewsUpdate Subscribed
News
Figure 7.3: SubscribedNews: Response time dependency model
CP2
CP1 Company
Customer
Receive
Request Request
Send
first
Receive
info
Send
Receive
Receive
Send Receive
Request
Request
NewsRequest
Figure 7.4: NewsRequest: Response time dependency model
key (DB pk). Independent from filling the database, the company sends daily updates
to customers with specific interests by requesting data from the database (Sid). This
retrieved data is combined with the specific interests of the customer (n = m ∪i). Data
used to compose a news report for the customer are reused for other reports. Therefore,
information requested from the database is also returned (back edge annotated with m).
The resulting report is sent to the customer.
Response time dependencies for NewsRequest are dependent on response times of
Request services invoked by the company to both content providers (cf. Figure 7.4). For
readability purposes we omit coloring the Petri Net. As soon as the company receives
a response from one of the two content providers, it sends out this information to the
customer (Send first). This enables faster response times for the customer.
In Step 3 we identify inter-model dependency relations for the different SLAs of the
composition for both response time and cost.
128
7.5. STEP 4: INTER-MODEL CONSISTENCY CONSTRAINTS
The main results of this step are:
•Identification of asymmetric property dependency between cost SLOs of the
different SLAs, and
•Identification of asymmetric property dependency between response time
SLOs of the different SLAs.
7.5 Step 4: Inter-model consistency constraints
In Step 3 we identify inter-model dependencies of SLAs using the overall composition of
the business case. In Step 4, we now use these asymmetric property dependency relations
to define inter-model consistency constraints.
We start with formulating a consistency constraint for each identified dependency.
According to the description of Step 4 in Section 4.4.2 every relation is translated into a
constraint:
If concept xis asymmetric property dependent on set Yof one or more
concepts, and zis the predicate describing this relation, the corresponding
constraint states: Property value of xrelates to property values of Yaccording
to predicate z.
Cost dependency. Composite service SubscribedNews (x) is cost dependent on set
NewsUpdate services (Y). The AND-construct with reuse describes their relation (z).
Therefore, we now define the consistency constraint concerning cost for the Subscribed-
News service as follows:
Constraint 9 (SubscribedNews cost).The cost property value of SubscribedNews de-
pends on both (i.e., AND-construct) cost properties of the NewsUpdate services, divided
by 100 and 80, respectively (i.e., reuse). The cost property value of SubscribedNews cor-
responds at least to the sum of costs for both NewsUpdate services divided by 100 and
80, respectively.
For the NewsRequest service, we define a similar constraint:
Constraint 10 (NewsRequest cost).The cost property value of NewsRequest depends
on both (i.e., AND-construct) cost properties of the Request services, where its property
value is at least the sum of costs of the Request services.
Response time dependency. Composite service SubscribedNews is response time de-
pendent on both Request services. The response time property of SubscribedNews is at
least the response time property of the slowest NewsUpdate service. Therefore, we define
the consistency constraint as follows:
129
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
Constraint 11 (SubscribedNews time).The response time property value of Subscribed-
News depends on both response time properties of the NewsUpdate services, where the
property value corresponds at least to the value of the slowest NewsUpdate service.
Since composite service NewsRequest responds as soon as the fastest responding Re-
quest service succeeds, its response time dependency is formulated as follows:
Constraint 12 (NewsRequest time).The response time property value of NewsRequest
depends on both response time properties of the Request services, where its property value
corresponds at least to the response time value of the fastest responding Request service.
Next, we generalize over these consistency constraints. This generalization enables
easy consistency checking.
7.5.1 Generalization: Impact factors
As discussed in Step 4 of Section 4.4.2 we generalize over consistency constraints of
partial models that have an asymmetric dependency relation. We do this by building trees
that connect the different services through their dependencies. In this chapter, we refer to
such trees as impact trees. In addition to structural trees, we derive a formula describing
the exact relation between composition and its separate services. This formula shows the
impact each service has on the composition concerning a certain property. We refer to
this as impact analysis.
The dependency model for an SLO expresses on which services a composite service
depends. However, not every service a composite service depends on, has the same im-
pact on this composite service. For example, if costs for a composite service depend on
services A and B, but service A costs on average only ten percent of service B, impact of
service B on the price of the composite service is much higher than impact of service A.
Therefore, our approach enables an impact analysis for every dependency model.
The impact a service has on the composite service is determined by analyzing the
dependency model. Each construct (e.g., AND-split) in the dependency model affects
the impact on the composite service in a different way. For example, an AND-split in a
cost dependency model denotes that costs for a composite service are influenced by both
services it depends on. Opposed to this, an XOR-split indicates the costs for the composite
service are influenced by only one of the two services it depends on (i.e., a service only
has an impact on part of the composite service instances), which decreases the impact
of these services by 50% (i.e., each service only occurs in half of the composite service
instances). This impact factor indicates how likely it is the service influences performance
of the composite service.
To calculate this impact factor, we first go through the models. We start with the
composite service, and then go through all constructs finishing with the services. Second,
we consider the consistency constraints. By considering the effects of each construct on
the impact while going through the model, we calculate the impact of the service. To
analyze the model in a structured way we create an impact tree. For each construct in the
models a vertex with its impact equation is created. This allows analysis of the impact
130
7.5. STEP 4: INTER-MODEL CONSISTENCY CONSTRAINTS
Graph Equation Cost Response Time
A
xy
r
I(A)=xAr
A
A
y=x
AND
x y
z
y=x
AND
All serial
x=zexecutions
XOR
x y
z
r
s
y=rx
XOR
All parallel
z=sxexecutions
DB
xy
y=0 All databases
and storages
RE
xy
y=x
RE
x
Table 7.5: Impact tree vertices
each construct and service has on the composition. Table 7.5 denotes the graph notation
and equation for all constructs of cost and response time models. The total impact of the
services on the composition is always 1.
The impact factor of service A (I(A) for short) on a composite service is equal to factor
xon the incoming edge times the value of service Atimes number of loops r(cf. Table
7.5). Value Ais either the estimated cost or the estimated response time. The number
of loops ris important if one service gets invoked more than once for one composite
service. For example, if for a composite service the company invokes the same service A
of its content provider twice (r=2) with a response time of 3 ms before responding to a
request of its customer. If service Aresults in the invocation of another service (serialism)
the outgoing edge (y) has the same impact factor as the incoming one (x) (cf. Table 7.5).
The second construct is an AND-split where outgoing edges (yand z) have the same
impact factor as the incoming edge (x). The third construct is an XOR-split where es-
timated ratio r:s determines the impact of edges yand z. Assume that for fulfilling a
composite service, a company chooses between two content providers. The first offers
fast, but expensive data, the second offers slow, but cheap data. Depending on the cus-
tomer, the company chooses either of the two. Estimations by the company are that it will
choose 3:1 (r:s) for the fast service.
The fourth construct enables modelling a database or storage. If the results of a
service are stored in a database or, with physical goods, in a storage then the dependency
on response time for the composite service disappears. Therefore, the impact of services
adding information or goods to a database or storage on the composite service regarding
response time is zero.
The last construct in Table 7.5 enables modelling reuse of data acquired when invok-
ing a service. Reuse of information from a service decreases the costs for using, and,
therefore, it decreases the cost impact factor of that service. If information is reused, the
cost for invoking this service is divided among the requesting services. Therefore, the
impact factor for costs is divided by the estimated number of reuses.
131
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
SubscribedNews
AND
NewsUpdate
CP1 NewsUpdate
CP2
80
100
a
e
d
cb
SubscribedNews
AND
NewsUpdate
CP1 NewsUpdate
CP2
a
dc
b
DB
Cost Impact Model Time Impact Model
(a) SubscribedNews
a
cb
Cost Impact Model Time Impact Model
NewsRequest
AND
Request
CP1 Request
CP2
a
cb
NewsRequest
XOR
Request
CP2
Request
CP1
rs
(b) NewsRequest
Figure 7.5: SubscribedNews and NewsRequest: Impact trees
Figure 7.5 depicts impact trees for both response time and cost of the Subscribed-
News service as derived from the SLA constraints. For cost the service depends on both
UpdateNews services with a reuse element in between to mitigate the influence. The
NewsUpdate service from CP1 is expected to be reused 100 times, while the NewsUpdate
service from CP2 is expected to be reused 80 time on average. Figure 7.5 also depicts the
impact trees for response time and cost of the NewsRequest service. The impact factor
for response time is now influenced by the estimated ratio r:s on the XOR-split.
Using the equations in Table 7.5 and both graphs in Figure 7.5, cost and time impact
factors are calculated and depicted in Table 7.6. Note that average costs of NewsUpdate
CP1 cannot directly be derived from the SLO (cf. Table 7.1) since it states 0.50 euro per
item with a maximum price of 50 euro per day. The same holds for NewsUpdateCP2.
Now, the company makes an estimation on the average value based on previous observa-
tions: NewsUpdateCP1 =40 and NewsUpdateCP2 =30.
For the impact on response time for NewsRequest, estimations are made on the XOR-
split ratio r:s. Since RequestCP1 responds on average faster than RequestCP2, ratio r:s
is estimated to be 3:1. Recall that the agreed upon response times by CP1 and CP2 for
Request are 3 and 4 ms, respectively. The impact factor is an absolute value, i.e., if an
impact value of a service is 5 in Model A and 10 in Model B, the impact of that service
on the composite service is twice as big in Model B as in Model A.
The equations of the impact factors must hold for the inter-model consistency con-
straints to succeed. In other words, the equations are general consistency constraints for
132
7.6. STEP 5: INTRA-MODEL RELATION DETECTION
Impact Factor Equation Result
I cost(NewsU pdateCP1) 1
100 40 0.4
I cost(NewsU pdateCP2) 1
80 30 0.375
I time(NewsU pdateCP1) 0 0
I time(NewsU pdateCP2) 0 0
I cost(RequestCP1) 0.20 0.20
I cost(RequestCP2) 0.15 0.15
I time(RequestCP1) 3times 39
I time(RequestCP2) 1times 44
Table 7.6: Supporting services of SubscribedNews and NewsRequest: Impact factors
cost and response time properties of NewsRequest and SubscribedNews.
The main results of this step are the following:
•Definition of impact factor equations that constitute the inter-model consis-
tency constraint for cost and response time properties of both NewsRequest
and SubscribedNews,
•Graphical notation of the impact tree, visualizing influence of each service on
the composition.
7.6 Step 5: Intra-model relation detection
In Step 3 we analyze inter-model relations to create a basis to define consistency con-
straints between SLAs. In this step we analyze existing intra-model dependencies be-
tween the SLOs. This provides the basis for Step 6 in which we define intra-model con-
sistency constraints.
In our business case there exists a clear separation between properties cost and re-
sponse time. For example, if the costs change, this will not have an effect on the response
time. Therefore, in our business case there are no intra-model dependencies between the
different SLOs. In other words, a constraint violation for response time does not affect the
consistency constraint for cost, and vice versa. However, we analyze possible dependen-
cies between SLOs within an SLA. In the remainder of this step, we discuss intra-model
dependencies that are common in real-life SLAs. Consider the following SLA:
Every month, response time will be within 3 ms for at least 99% of the in-
vocations. Costs are 3 euro when the service responds within 2 ms, while a
response time of 2 −3 ms costs 2 euro. If less than 99% of the invocations
have response time within 3 ms, a penalty of 1000 euro will be paid.
133
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
In this SLA, cost directly depends on response time. The challenge is to represent
what this means in respect of the relative contribution to the composition by the cost
performance of the service. For example, to diagnose the cause of an increase in cost for
the service composition, we show the influence of decreasing response times to the costs
(i.e., costs rise to 3 euro).
To solve this, within one SLA dependencies between SLOs are represented by links
between properties. These links are annotated with some contribution function, similar
to the calculations we do for the inter-model dependencies. Our goal is to represent the
causal influence between properties as accurately as necessary for meaningful diagnosis.
For example, in the above example it may be sufficient to represent that a decrease in
response time causes an increase in cost. This leads to a clear step when handling SLAs
with intra-model relations:
Step 5a: Extend the computation of the impact tree and impact values with
dependencies between properties within one SLA.
A second elaboration that occurs in real-life SLAs is the imposition of violation penal-
ties. An example is the above SLA, where 1000 euro are paid in case the response time
requirement is not met. Such penalty constraints are frequently used in SLAs. We could
add this as additional cost, with a dependency on the performance of other attributes.
However, this ignores the special status of penalties. As a consequence, separate penalty
impact trees with dependencies on the SLOs in the SLA need to be created. Therefore, a
second step in handling intra-model dependencies is the following:
Step 5b: Extend the computation of impact tree and impact values with
penalties for SLA violations.
Based on these two intra-model dependencies, it is possible to construct an intra-
model impact tree for each SLA where dependencies between SLOs and penalties are
denoted. Typically, these dependencies are asymmetric property dependencies.
The main results of Step 5 are the following:
•Conclusion that no intra-model dependencies exist in our business case,
•Discussion on possible intra-model dependency relations within SLAs:
–Dependencies between SLO properties like response time and cost,
–Dependency of penalty costs on SLO properties like a penalty for slow
response times.
7.7 Step 6: Intra-model consistency constraints
In Step 6 we explicate intra-model consistency constraints, using dependency relations
identified in Step 5. These constraints enable consistency checking of models with the
134
7.7. STEP 6: INTRA-MODEL CONSISTENCY CONSTRAINTS
running system. As discussed for Step 6 in Section 4.5, intra-model consistency con-
straints are (1) based on identified intra-model dependency relations and (2) on model
characteristics.
The intra-model consistency constraints ensure the model (i.e., the SLA) describes the
inter-organizational cooperation properly (i.e., that the agreement is respected). These
constraints hold if at runtime the behavior of the system is the same as the behavior
captured in the model. We check this by gathering information from event logs that
describe behavior between actors, and compare this realized behavior with the constraints
in the SLAs. Therefore, the intra-model consistency constraints are defined using event
logs.
The business case considered in this chapter does not have intra-model dependencies,
i.e., there are no dependencies between SLOs within one SLA. However, in Step 5 we dis-
cuss that in SLAs from real life there often exist such dependencies. Typically, these are
property dependencies, i.e., dependencies between properties of concepts. Using the con-
straint definition from Section 4.4.2 we formulate the following consistency constraints
for asymmetric and symmetric property dependency relations, respectively:
If an SLO is asymmetric property dependent on another SLO within the
same SLA, where zis the predicate describing this relation, the constraint
states: Property value of the SLO relates to property value of the other SLO
according to predicate z.
Reconsider for example the case from the previous step:
Every month, response time will be within 3 ms for at least 99% of the in-
vocations. Costs are 3 euro if the service responds within 2 ms, while if the
service has a response time of 2 −3 ms, costs are 2 euro. If less than 99%
of the invocations have response time within 3 ms, a penalty of 1000 euro is
paid.
Here, the property cost is asymmetric property dependent on property response time
according to the predicate that costs are 3euro if the service responds within 2ms, while
if the service has a response time of 2−3ms, costs are 2euro. As a result, the consistency
constraint for this SLA is as follows:
For each service composition invocation the event log information is ex-
pected to contain that property cost relates to property response time accord-
ing to the following statement: costs are 3euro if the service responds within
2ms, while if the service has a response time of 2−3ms, costs are 2euro
The consistency constraint for symmetric property dependency relation is as follows:
If two SLOs are symmetric property dependent on each other, and zis the
predicate describing this relation, the constraint states: The property values
of the SLOs are related according to predicate z.
135
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
In addition to the consistency constraints based on intra-model dependencies, there ex-
ist model-specific constraints. Here, model-specific constraints are formulated according
to content of the SLAs. For example, in our business case the SLA for SubscribedNews
depicts constraints on both cost and response time:
Constraint 13 (SubscribedNews 1).Over a one month period, the event log contains
entries that the company delivered SubscribedNews on average for less than 1 euro per
service.
Constraint 14 (SubsecribedNews 2).The event log contains entries that the company
delivered SubscribedNews once a day before 9:00 am, Mo-Fri.
The main results of Step 6 are as follows:
•Defining intra-model consistency constraints for SLAs based on intra-model
dependencies, and
•Defining intra-model consistency constraints for SLAs based on their general
content.
7.8 Step 7: Dependency analysis
In the previous steps we identify consistency constraints between SLAs and event log,
i.e., we define inter- and intra-model consistency constraints. Both model analysis and
consistency constraints are described in an intuitive manner. In Step 7 we formalize these
steps to enable automatic analysis of service compositions. This analysis, in turn, results
in a set of formal models.
We use trees to represent dependencies in and between SLAs, and algorithms to de-
scribe the analysis. Each service composition is represented as composition tree. Next,
per SLO we analyze the tree and construct for each SLO (e.g., for cost and response time)
an expected impact tree (i.e., the impact tree with impact factors from Step 4). We start
with constructing the composition tree, after which we derive expected impact trees.
To illustrate the use of these algorithms and construction of trees, we use a more
complex and abstract service composition. This example is depicted in Figure 7.6 where
the composition consists of an OR-split with discriminative join (ORDISC). Here, 3 out of
4 branches are invoked and the construct succeeds after the fastest two invoked branches
succeed. Each branch indicates the invocation chance compared to its siblings. The first
branch is an AND-split and AND-join where Web services WS 1 and WS 2 are invoked in
parallel. The second branch consists of a single Web service WS 3, and the third branch
is an XOR-split where either WS 4 (chance is 0.4) or WS 5 (chance is 0.6) is invoked.
The fourth branch consists of WS 6. Each service has an agreed upon average response
time and cost attribute described in its SLA.
136
7.8. STEP 7: DEPENDENCY ANALYSIS
COMP
WS 1 WS 2
OR DISC
RT: 2 ms RT: 3 ms
Cost: € 4 Cost: € 3
Composition tree
AND WS 3 XOR WS 6
RT: 5 ms
Cost: € 4 RT: 4 ms
Cost: € 6
RT: 6 ms
Cost: € 2 RT: 4 ms
Cost: € 3
WS 4 WS 5
0.2 0.3 0.4 0.1
0.4 0.6
Figure 7.6: Illustrative service composition
Composition Response Time Cost
AND max(total) sum(total)
ANDDISC max(subset) sum(subset)
OR max(subset) sum(subset)
ORDISC max(subset) sum(subset)
XOR max(one) sum(one)
Loop sum(total∗) sum(total∗)
Sequence sum(total) sum(total)
Table 7.7: Matching composition vertices and vertices for dependency trees
137
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
7.8.1 Composition tree
At design time we analyze dependencies of the composition on its underlying services.
For the construction of service compositions, we consider the most commonly used work-
flow patterns [1] as constructs. Table 7.7 shows the type of relations between services per
SLO (response time and cost) and per construct. The constructs are here discussed infor-
mally, but are in the algorithms described in more detail. Although there are more SLOs
to consider (e.g., availability), Table 7.7 suffices to demonstrate the principles behind our
approach. An AND-split (cf. AND in Table 7.7) succeeds after the slowest respond-
ing service finishes (i.e., the maximum response time of all branches: max(total)). Its
total cost is the sum of all invoked services (i.e., sum(total)). For a parallel AND-split
with discriminative join (ANDDISC), a parallel OR-split with a discriminative join (OR-
DISC), and a parallel OR-split with normal join, the response time is determined by the
slowest invoked service (i.e., the maximum response time of a subset of all invoked ser-
vices: max(subset)). Its costs correspond to the sum of costs of all invoked services
(i.e., sum(subset)). For sequences (Sequence) and for sequences executed more than
once (Loop), both response time and cost are summed up for all invoked services (i.e.,
sum(total) and sum(total∗), where ∗indicates the number of iterations). For an XOR-split
and join the invoked service contributes to both response time and cost (i.e., the response
time and cost of the started service: max(one) and sum(one)).
By considering these constructs and their properties we determine the expected impact
of each service on the overall composition for a specific SLO (i.e., we calculate the func-
tion connecting the SLOs of different services as done informally in Step 4). A service
composition is modelled as a tree where the top vertex represents the service composition
(COMP) and the leafs represent Web services (WS). Connecting vertices and edges depict
the composition structure. This is the same structure as used in Step 4 in the context of
impact trees.
Estimations on the number of invocations are captured by annotating vertices and
edges with estimated or agreed upon values. Vertices representing Web services are an-
notated with the agreed upon SLO values (σ). Vertices representing constructs are an-
notated with estimated behavior, if appropriate (µ). Annotations are (1) the number of
started services (for OR-constructs), (2) the number of discriminative success, i.e., after
how many successful responses the construct succeeds (for DISC-joins), and (3) the num-
ber of iterations (for loop-constructs). Edges are annotated with the probability they are
invoked for each service composition invocation (ρ). For example, two edges leaving an
XOR vertex are annotated with the probability they are chosen (i.e., this is an estimation).
All trees are acyclic.Composition trees are defined as follows:
Definition 8 (Composition tree).Let Vsbe the set of types for service vertices {WS,COMP}
and let Vcbe the set of structural vertices {AND,ANDDIS C,OR,XOR,ORDIS C,LOOP,
S EQ}. A composition tree is a 6-tuple CT (Vc,Vs)=(V,E, ρ, µ, τ, σ), with
•V is a set of vertices,
•E:V→V is a set of directed edges,
138
7.8. STEP 7: DEPENDENCY ANALYSIS
•ρ:E→Rthe probability of invocation compared to its siblings,
•τ:V→ Vc∪ Vsspecifies the vertex type,
•σ:{v∈V|τ(v)∈ Vs} 7→ Rnspecifies the expected SLO values for each SLO,
where n indicates the number of SLOs, 1
•µ:{v∈V|τ(v)∈ Vc} 7→ (ε∪R)3vertices are annotated with (1) number of started
services, (2) number of discriminative success, and (3) number of iterations.
Now, the composition tree of our illustrative example (cf. Figure 7.6) is denoted as
follows:
CT example =(
V:{COMP,ORDISC,AND,XOR,WS 1,WS 2,WS 3,WS 4,WS 5,WS 6},
E:{e1={COMP,ORDISC},e2={ORDIS C,AND},e3={ORDIS C,WS 3},
e4={ORDIS C,XOR},e5={ORDIS C,WS 6},e6={AND,WS 1},
e7={AND,WS 2},e8={XOR,WS 4},e9={XOR,WS 5}},
ρ:{(e1,1),(e2,0.2),(e3,0.3),(e4,0.4),(e5,0.1),(e6,0.2),(e7,0.2),(e8,0.4),(e9,0.6)},
µ:{(ORDIS C,(3,2, ε))},
τ:{(COMP,COMP),(ORDIS C,ORDIS C),(AND,AND),(XOR,XOR),(WS 1,WS ),
(WS2,WS ),(WS 3,WS ),(WS 4,WS ),(WS 5,WS ),(WS 6,WS )},
σ:{(WS1,(2,4)),(WS 2,(3,3)),(WS 3,(5,4)),(WS 4,(6,2)),(WS 5,(4,3)),
(WS6,(4,6))})
Next, we discuss how to calculate expected impact trees.
7.8.2 Expected impact tree
After deriving the composition tree from the Web service composition, we calculate the
expected impact trees. These trees depict expected behavior of the services. Hereby,
the focus is on the expected impact each service has on the composition. This expected
impact is for each SLO calculated separately.
Based on the composition tree, expected runtime behavior is calculated resulting in
an expected impact tree. This expected behavior constitutes the formalization of inter-
SLO consistency constraints where trees are built that show dependency between different
services (cf. Step 4). For an SLO such an expected impact tree depicts the expected impact
of a service per composition invocation, i.e., the impact factor. In addition, every edge
in the tree has a contribution factor that depicts the average number of times a subtree
contributes per invocation.
Definition 9 (Impact factor).Let X →Y be two vertices with a connecting edge of an
impact tree for a specific SLO. If vertex Y is an input service, the impact factor of Y
denotes the average contribution to the composition for the SLO value. The contribution
is defined as percentage of the composition SLO value.
1We assume that all vertices are annotated with the same tuple of SLOs.
139
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
For example, assume the impact factor of a service on the composition is 0.5 for
response time. Then the average contribution of this service to the overall response time
of the composition is 50%.
Definition 10 (Contribution factor).Let X →Y be two vertices with a connecting edge
of an impact tree for a specific SLO. The contribution factor on the edge (→) denotes the
average number of times subtree Y contributes per composition invocation. (Note that
this value is less than or equal to 1 unless the subtree contains a loop structure.)
For example, assume the contribution factor of a service to the composition is 0.5 for
response time. Then the average number of times this service contributes to the composi-
tion is 50% regarding response time.
Recall the semantics of the vertices in Table 7.7, explained at the beginning of Section
7.8.1. Expected impact trees are defined as follows:
Definition 11 (Expected impact tree).Let Vsbe the set of service vertices {WS,COMP}
and let Vibe the set of dependency vertices: {max(total),max(subset),max(one),sum(total),
sum(subset),sum(one),sum(total∗)}. An expected impact tree is a 5-tuple.
EIT (Vi,Vs)=(V,E, ρ, τ, σ), where
•V is a set of vertices,
•E:V→V is a set of directed edges,
•ρ:E→Ris the probability of contribution per composition invocation,
•τ:V→ Vi∪ Vsspecifies the type of the vertex,
•σ:{v∈V|τ(v)=WS } 7→ R×RAnnotations of Web service vertices are in the
first dimension “estimated impact”, and in the second dimension “expected SLO
value”,
•σ:{v∈V|τ(v)=COMP} 7→ {1} × Rannotation of composed services specifies
estimated SLO value based on composition structure. We use Rinstead of {1} × R
for brevity in the remainder of this chapter.
The expected impact tree supports identification of services with high influence on
composition behavior. The type of considered SLO determines the transformation algo-
rithm. For example, consider the example from Figure 7.7 representing a service com-
position where each run invokes two services in parallel: either S1 and S2, or S1 and
S3. Intuitively, expected impact for S1 is 1 ·10ms =10 since it is invoked every invo-
cation (i.e., 1), and responds in 10 ms. S2 has an impact of 0.5·20ms =10, and S3 of
0.5·15 =7.5, assuming both have 50% chance of being chosen per invocation.
However, in practice structure (i.e., expected number of invocations) and performance
(i.e., SLO value) are not sufficient to describe the realized impact. It can be expected
that most times, S1 finishes before the other service (faster response time). Therefore,
S1 usually does not contribute to overall response time since this is done by the longer
140
7.8. STEP 7: DEPENDENCY ANALYSIS
ANDCS S1
S2
10ms
S3 15ms
XOR 20ms
Figure 7.7: Small example: Service composition
running service. In fact, the setting in which the services run (e.g., running parallel with
high response time services) should be taken into account as well. As a consequence,
each invoked service has an impact on composition costs. However, only the slowest
responding service influences composition response time. To make this explicit, we create
an expected impact tree for each monitored SLO (e.g., one for response time and one for
costs). In other words, the structural behavior of response time and cost differ, hence, this
different behavior requires different algorithms.
We only introduce algorithms for response time, and only parts of the algorithm are
provided formally (pseudo code): the remaining parts are described informally since the
formalization is lengthy, and does not contribute to the clarification of our approach. For
example, the calculation code is not shown for OR-split with discriminative join because
the code is longer, and the general principle is shown for the AND case. The goal of the
expected impact tree is threefold:
•Estimate the behavior of the overall composition based on both contracts (SLAs)
with the different service providers and the structure of the composition (i.e., cal-
culate the σ-value).
•Estimate the impact (e.g., on response time) of each subtree on the overall compo-
sition (i.e., calculate the ρ-value for the edges).
•Estimate the impact (e.g., on response time) of each Web service on the overall
composition (i.e., calculate the σ-value for the Web service).
All these estimations are based on contracts with the service providers, and on the
structure of the composition. Both expected QoS and structure determine estimated prob-
ability that a service is invoked. As described, invocation of a service does not necessarily
mean it actually contributes to, for example, the response time (e.g., in branches running
parallel, only the longest running one has an impact). Therefore, Function 1 calc(v) de-
termines the probability a service gets invoked and it actually contributes to the overall
composition.
Function 1 calc(v). Vertices Vand edges Eof the expected impact tree are equal
to vertices Vand edges Eof the composition tree. The structure of both trees is the
141
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
Function 1calc(v)
input :v∈V&Composition Tree CT ={V,E, ρCT , µCT , τCT , σCT }
output : Expected average rt of the composition & Expected Impact Tree
EIT ={V,E, ρ, τ, σ}
switch τCT (v)do1
case COMP2
τ(v)=COMP;3
eout =v→vy∈E;4
ρ(eout)=ρCT (eout);5
σ(v)=calc(vy);6
return σ(v);7
case AND8
τ(v)=max(total);9
rtmax =0;10
vmax =v;11
ein =vy→v∈E;12
foreach eout =v→vy∈Edo13
ρ(eout)=ρ(ein);14
rty=calc(vy);15
if RTy>RTmax then16
RTmax=RTy;17
Vmax =vy;18
foreach v→vy∈E\{v→Vmax}do reassign(vy,0);19
return rtmax;20
case WS21
τ(v)=WS;22
ein =vy→v∈E;23
impact(σ(v)) =ρ(ein)·rt(σCT (v));24
rt(σ(v)) =rt(σCT (v));25
return rt(σCT (v));26
Function 2reassign(v,z)
input :v∈Vand z=ρof incoming edge v
ein =vy→v∈E;1
ρ(ein)=z;2
switch τCT (v)do3
case XOR4
foreach eout =v→vy∈Edo reassign(vy, ρ(ein)·ρCT (eout));5
case AND6
foreach v→vy∈Edo reassign(vy, ρ(ein));7
142
7.8. STEP 7: DEPENDENCY ANALYSIS
same, though annotation and naming of vertices and edges differ. The function traverses
recursively through the composition tree, starting with the composition (COMP) vertex.
Its calculations are divided into five steps.
1. When traversing the tree the name of each vertex (τ-value) is determined by its orig-
inal type (cf. Function 1 calc(v) in Line 3, 9, & 22). For example, a parallel split
is named max(total) in the expected impact tree for response time (cf. Table 7.7).
2. The probability an edge gets invoked (cf. Function 1 calc(vy), ρvalue assignment
in Line 5 & 14) is determined by combining its local probability with the probability
its parent edge gets invoked. Now, each Web service “knows” locally its probability
for each composition invocation to be invoked.
3. Each vertex determines its expected average response time based on the expected
response times of its children (i.e., the expected response times of services invoked
in that subtree). For example, in Lines 13-15 of Function 1 calc(v), an AND vertex
determines its expected response time based on the maximum response time of all
its children.
4. Each vertex determines which children branches have an impact if they are chosen
(i.e., expected contribution). For example, assume an AND vertex has one fast
responding child compared to the other children. This child, most likely, does not
contribute to the composition response time since it finishes before the rest (cf.
calc(v), Lines 16-18). Now, each vertex has global knowledge on the expected
behavior of its children.
5. This global information is propagated through the tree, annotating each branch
with the probability it contributes to the composition per invocation (cf. Function
reassign(vy,n) invoked by calc(v) in Line 19).
As discussed above, we describe the calculation for OR-split with discriminative join
informally. For each subset sof branches from the OR-split, we calculate likelihood of
invocation l, and the expected response time of the subset. Since it is a discriminative
join, expected response time depends on the fastest responding subset s0. For example, if
four out of five branches are started, and three need to finish for the discriminative join
to succeed, the theoretical minimum response time can only be the response time of the
third-quickest service. Comparable calculations are done for the remaining vertex types.
Using this algorithm, the response time impact tree and the cost impact tree are cal-
culated. A graphical representation of the trees of our illustrative example is depicted in
Figure 7.8.
The response time impact tree from Figure 7.8(a) depicts expected average impact of
each service on the response time of the composition. For the OR-split with discriminative
join we calculate the estimated response time of each branch. For each subset of three
branches (recall that three branches out of four are invoked) we calculate the invocation
chance based on the estimated chance to be chosen on the branches. With the average
143
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
response time for each branch and the chance for each subset of branches to be invoked,
we determine which branch, most likely, is the second to finish for each subset. Recall that
the ORDISC-construct succeeds after the second branch responds. Now, we determine
the average response time for the ORDISC based on the expected response time of each
subset of three services and the invocation chance of that subset. For example, the first
and second branch are expected never to be the second responding branch, therefore,
their expected impact is 0. On average, the third branch with the XOR-split is expected to
determine response time in 57% of the composition invocations. Recall from Figure 7.6
that the chance to be invoked for WS 4 and WS 5 is 0.4 and 0.6, respectively. Therefore,
on average, WS 4 contributes 0.4·0.57 =0.23 times to the overall response time when
the composition is invoked. The impact of WS 4 (i.e., the average contribution to the
total response time) is 0.31. This value is calculated using the average response time of
WS 4 (6ms), the average response time of the composition (4.46 ms), and the number of
times the WS is expected to contribute to the response time of the composition (0.23):
6
4.46 ·0.23 =0.31.
The cost impact tree in Figure 7.8(b) depicts the expected average contribution of each
Web service to the composition costs (i.e., the impact factors). Furthermore, it depicts how
often a service is expected to contribute to the costs per composition invocation (i.e., the
values on the branches). For costs it holds that each invoked service is paid. Therefore,
ORDISC results in the summation of costs of a subset of its outgoing branches (in this
case 3) (sum(subset)). For each subset of three branches we calculate the invocation
chance. For each branch we determine the average invocation chance by summing up
the chances of each subset where the service is contained. Results are depicted on the
outgoing branches, and add up to 3 since each invocation of the composition results in the
invocation of 3 branches that all contribute to the cost of the composition. For the XOR-
split in the third branch we calculate the invocation chance for WS 4 and WS 5 (0.4·0.8=
0.32, and 0.6·0.8=0.48, respectively). Therefore, these Web services contribute to
the composition cost. The expected impact factor of each service is again calculated by
dividing average costs of the service (e.g., 4 euro for WS 1) with average composition
costs (e14.47). We multiply this with the chance the service actually contributes (0.73):
4
14.47 ·0.73 =0.20.
The formal notation of the impact trees of our example is as follows:
144
7.8. STEP 7: DEPENDENCY ANALYSIS
COMP
WS 1 WS 2
max(subset)
IF: 0
RT dependency tree
max(total) WS 3 max(one) WS 6
WS 4 WS 5
00 0.57 0.43
0.23 0.34
RT: 4.46 ms
00
1
IF: 0
IF: 0
IF: 0.31 IF: 0.3
IF: 0.39
(a) Response time impact tree
COMP
WS 1 WS 2
sum(subset)
IF: 0.2
Cost dependency tree
sum(total) WS 3 sum(one) WS 6
WS 4 WS 5
0.73 0.77 0.8 0.7
0.32 0.48
Cost: € 14.47
0.73 0.73
1
IF: 0.15
IF: 0.21
IF: 0.04 IF: 0.1
IF: 0.29
(b) Cost impact tree
Figure 7.8: Illustrative example: Estimated impact trees
EIT cost =(
V:{COMP,sum(subset),sum(total),sum(one),WS 1,WS 2,WS 3,WS 4,WS 5,WS 6},
E:{e1={COMP,sum(subset)},e2={sum(subset),sum(total)},
e3={sum(subset),WS 3},e4={sum(subset),sum(one)},e5={sum(subset),WS 6},
e6={sum(total),WS 1},e7={sum(total),WS 2},e8={sum(one),WS 4},
e9={sum(one),WS5}},
ρ:{(e1,1),(e2,0.73),(e3,0.77),(e4,0.8),(e5,0.7),(e6,0.73),(e7,0.73),(e8,0.32),
(e9,0.48)},
τ:{(COMP,COMP),(sum(subset),sum(subset)),(sum(total),sum(total)),
(sum(total),sum(total)),(WS 1,WS ),(WS 2,WS ),(WS 3,WS ),(WS 4,WS ),
(WS5,WS ),(WS 6,WS )},
σ:{(WS1,0.2),(WS 2,0.15),(WS 3,0.21),(WS 4,0.04),(WS 5,0.1),(WS 6,0.29)})
EIT rt=(
V:{COMP,max(subset),max(total),max(one),WS 1,WS 2,WS 3,WS 4,WS 5,WS 6},
E:{e1={COMP,max(subset)},e2={max(subset),max(total)},
e3={max(subset),WS 3},e4={max(subset),max(one)},e5={max(subset),WS 6},
e6={max(total),WS 1},e7={max(total),WS 2},e8={max(one),WS 4},
e9={max(one),WS 5}},
ρ:{(e1,1),(e2,0),(e3,0),(e4,0.57),(e5,0.43),(e6,0),(e7,0),(e8,0.23),(e9,0.34)},
τ:{(COMP,COMP),(max(subset),max(subset)),(max(total),max(total)),
(max(total),max(total)),(WS 1,WS ),(WS 2,WS ),(WS 3,WS ),(WS 4,WS ),
(WS5,WS ),(WS 6,WS )},
σ:{(WS1,0),(WS 2,0),(WS 3,0),(WS 4,0.31),(WS 5,0.3),(WS 6,0.39)})
For this example, we derive that response time of the composition is influenced by WS
4, WS 5, and WS 6. Furthermore, we see that they have comparable impact. Concerning
the composition cost, we derive that WS 4 and WS 5 have a comparable low impact, and
145
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
WS 6 contributes to almost 30% of the cost. Furthermore, we see for response time that
WS 6 contributes in 43% of the invocations, and that WS 4 and WS 5 contribute in 23%
and 34% of the invocations, respectively. For the costs, WS 1, WS 2, WS 3, and WS 6 all
contribute in 70 −80%, and WS 4 and WS 5 only in 30 −50% of the invocations.
The main results of Step 7 are as follows:
•Formalization of the service composition with SLAs,
•Formalization of the expected impact trees for SLOs (i.e., formalization of the
consistency constraints), and
•Algorithm for automatic translation from composition tree into expected im-
pact trees.
7.9 Step 8: Log analysis
In the previous steps we analyze SLAs, define consistency constraints, and formalize SLA
analysis. In Step 8 we demonstrate how we analyze event logs such that we can check
consistency constraints at runtime.
At runtime we gather monitoring data from event logs. These logs contain information
needed to check whether the composition is behaving according to the SLA specifications.
We abstract this information from the event logs, and refer to this as the event log abstrac-
tion. Each Web service invocation is an entry in the event logs, and we need to recognize
to which composition invocation it belongs. For example, if a Web service invocation is
responded to, then this response is stored as entry in the event log. We discuss which
information is necessary to monitor SLAs.
The challenge is to abstract useful information, and to structure it in a meaningful
way. Focus of our monitoring approach is on the different SLOs of a composite service.
Therefore, we capture information concerning the SLO (e.g., timestamps to measure re-
sponse times and payment information for cost calculations). In addition, we capture
data to correlate different messages. We accomplish this correlation by analyzing differ-
ent time stamps on the service invocations in combination with the service composition
structure. To enable abstracting necessary data from the event logs, we need to correlate
the following information:
1. Messages exchanged between provider and customer during invocation of the com-
posite service.
2. Services (and their messages) invoked by the composite service, i.e., the services
a composite service depends on. This is achieved by either matching identifiers
(as available, for example, with a BPEL implementation) or by doing semantic
matching.
146
7.9. STEP 8: LOG ANALYSIS
3. Instances of services belonging to one specific type of service (e.g., all instances of
a premium account).
4. Grouping classes of services belonging to one business activity (e.g., all premium
and normal account instances of service X).
5. Instances of services that are exchanged with the same business partner (e.g., all
instances of services exchanged with content provider A).
6. Composite services that reuse data from the same service. Again this information
is correlated through identifiers or by semantic matching.
To meet the identified correlation criteria we structure our event log abstraction in the
following manner. Each composition invocation is represented as a list of invoked Web
services for that composition instance:
•Issuer of the composite service,
•Type of service issued,
•Costs of the service,
•Set of messages exchanged with the issuer, and
•Set of service instances this composite service depends on.
Each service invoked in the composition is a 4-tuple containing a time stamp (ts), the
name of the invoked Web service (ws), its costs (costs), and its response time (rt). For
brevity, we denote timestamps in relative milliseconds instead of complete date and time
notation.
An example of one instance of NewsRequest by a customer in event log abstraction
notation is as follows.
Composite Service:
CS(id1)=
CustomerX, NewsRequest, 0.50, {M(id2),M(id3)},{S(id4), S(id5)}
Services:
S(id4)=(M(id6), M(id7), 0.20)
S(id5)=(M(id8), M(id9), 0.15)
Messages:
M(id2)=(1.0, CustomerX, Company, ”Dutch politics”)
M(id3)=(5.5, Company, CustomerX, ContentY)
M(id6)=(2.0, Company, CP1, ”Dutch politics”)
M(id7)=(4.2, CP1, Company, ContentY)
M(id8)=(2.1, Company, CP2, ”Dutch politics”)
M(id9)=(5.1, CP2, Company, ContentZ)
147
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
Here, composite service NewsRequest CS(id1) is issued by CustomerX for the price
of 0.50 euro. Between the company and CustomerX, two messages M(id2) and M(id3)
are exchanged, and the two services S(id4) and S(id5) are used by the company to fulfill
the composite service. Both services S(id4) and S(id5) consist of two messages, and cost
0.20 and 0.15 euro, respectively. Each message M(idX) consists of a timestamp, issuer,
recipient, and content of the message. In the given case, the customer wants an update
on Dutch politics. Both CP1 and CP2 deliver news items (ContentY and ContentZ). The
company sends ContentY since this is the first to arrive (4.2 ms <5.1 ms).
7.10 Step 9: Causal analysis
In the previous steps we formalize SLA analysis to identify dependencies, and to use
them to calculate estimated behavior of the service composition. In addition, we abstract
necessary information from the event log. This makes it possible to compare estimated
behavior in the dependency analysis with realized behavior described in the event log.
The comparison allows us to identify SLA violations as well as possible causes for these
violations. Identification of causes for violations allows developing a management strat-
egy that minimizes the number of SLA violations.
For this, we first discuss how to construct realized impact tree that depicts what the
realized service levels for the composition are. Secondly, we discuss how to compare
estimated and realized impact trees, and we create a feedback tree that shows deviations
between the two.
7.10.1 Realized impact tree
We use analysis of dependencies between services during development phase, and analy-
sis of the impact these services have on the composition, in order to support monitoring
composite services at runtime. The event log abstraction, containing results of bilateral
communication, is compared with the SLOs. For example, if the SLO states response
time is on average 3 ms, achieved average response time is easily calculated using times-
tamps. However, opposed to traditional monitoring approaches, we also consider SLO
values of other invoked services in the composition during comparison. As a result, not
only bilateral SLOs are assessed: a complete picture is provided on how the composite
service is performing. The resulting model is referred to as the realized impact tree, and
is defined as follows:
Definition 12 (Realized impact tree).Let Vsbe the set of service vertices {WS,COMP}
and let Vibe the set of dependency vertices {max(total),max(subset),max(one),sum(total),
sum(subset),sum(one),sum(total∗)}. A realized impact tree is a 5-tuple RIT =(Vi,Vs)=
(V,E, ρ, τ, σ), where
•V is a set of vertices,
•E:V→V is a set of directed edges,
•ρ:E→Rthe average contribution per composition invocation,
148
7.10. STEP 9: CAUSAL ANALYSIS
•τ:V→Vi∪ Vsspecifies the vertex type,
•σ:{v∈V|τ(v)=WS } 7→ R×Rannotations of Web service vertices are in the
first dimension: total contributed SLO value, and in the second dimension: total
number of contributions,
•σ:{v∈V|τ(v)=COMP} 7→ R×Rannotations of the composition vertex is in
the first dimension: total realized SLO value, and in the second dimension: total
number of invocations.
The goal of the realized impact tree is threefold:
•Determine realized behavior of the service composition over a specific period of
time (i.e., calculate σ),
•Determine realized impact each subtree has on the overall composition (i.e., ρ-value
of the edges), and
•Determine realized impact of each Web service on the composition (i.e., σof the
Web service vertices).
Algorithm 3: Realized impact. Vertices Vand edges Eof the realized impact tree are
equal to vertices and edges in the composition. In other words, we assume the structure
of the service composition is the same. Algorithm 3 shows implementation for response
time. The code is only depicted for a subset of vertex types.
As argued before, not every Web service invocation contributes to the SLO value of
the composition. Therefore, Algorithm 3 analyzes all entries in the event log abstraction
(Line 3, Algorithm 3). Furthermore, it determines which entries (i.e., which Web service
invocations) impact the composition based on composition structure and other service
performance. For this, recursive Function addWS(v) is invoked in Line 5 of Algorithm 3.
For example, the XOR-split determines which children (cf. Line 20 of Function addWS(v))
contribute to the overall response time (cf. Line 22-26), and returns all contributing Web
service invocations in the subtree (cf. con f irm, Line 27).
These entries are added to the con f irmed list (Line 6, Algorithm 3). Furthermore, all
confirmed entries are used to update total response time and total number of invocations
(i.e., σ-values) of the services (Lines 7-10, Algorithm 3).
As a last step, Algorithm 3 determines for each edge the contribution per composition
invocation (i.e., ρ-value) by invoking recursive Function calcImpact(vcomp) in Line 11.
This function determines the number of contributions per composition invocation for each
edge (i.e., its ρ-value). Web service leafs calculate ρ-value of the incoming edge (cf. Line
16-19 of Function calcImpact) by comparing number of leaf vertex invocations with
total number of composition invocations. For example, if the composition is invoked
6 times, and the leaf vertex contributes 3 times, it contributes on average 0.5 times to
each composition invocation. Each structural vertex combines information of its outgoing
edges, and determines the ρ-value of the incoming edge. For example, in an AND-split
149
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
the overall contribution of the subtree is the summation of ρ-values of its outgoing edges
(cf. Lines 11-14).
As a result, a realized impact tree is created for each SLO, similar to the estimated
impact trees (cf. Figure 7.8).
Algorithm 3: Realized impact
input :Log File Model Land Composition Tree CT =(V,E, ρCT , µCT , τCT , σCT )
output : Realized Impact Tree EIT =(V,E, ρ, τ, σ)
con f irmed =∅;1
vcomp ={v|τCT (v)=COMP};2
foreach l∈Ldo3
initially =l;4
(c f,rt,ts)=addWS(vcomp);5
con f irmed =con f irmed ∪c f ;6
foreach tuple ∈con f irmed do7
v=ws(tuple);8
rt(σ(v)) =rt(σ(v)) +rt(tuple);9
contribution(σ(v)) + +;10
ρ=calcImpact(vcomp);11
7.10.2 Feedback tree
The feedback tree depicts deviations from agreed upon SLA values by comparing es-
timated and realized impact trees. Colors on edges and vertices are used to visualize
these deviations. Currently, red, green, yellow, darkgreen, and colorless are used (i.e., θ-
values), but these colors can be extended or changed in any preferred way. Intuitively, red
and yellow represent negative deviations, while green and darkgreen represent positive
deviations.
The goal of the feedback tree is to support management in identifying causes for badly
performing compositions. We accomplish this by giving feedback on:
1. Deviation between expected and realized behavior of the composition regarding a
particular SLO (i.e., its θ-value),
2. Deviation between expected and realized contribution of each subtree to the SLO
of the composition,
3. Deviation between expected and realized contribution of each Web service in the
composition, and
4. Realized contribution per invocation of Web services (i.e., σ-value) and subtrees
(i.e., ρ-value).
150
7.10. STEP 9: CAUSAL ANALYSIS
Function 4addWS(v)
input :v∈V
output :(con f irm,rt,ts): the set of contributing tuples con f irm, with its overall rt, and the
ts of the first started tuple ∈con f irm
con f irm =∅;1
rt =0;2
ts =Max;3
switch τCT (v)do4
case COMP5
v→vchild ∈E;6
(con f irm0,rt0,ts0)=addWS(vchild);7
rt(σ(v)) =rt(σ(v)) +rt0;8
invoc(σ(v)) + +;9
return (con f irm0,rt0,ts0);10
case AND11
foreach v→vchild ∈Edo12
(con f irm0,rt0,ts0)=addWS(vy);13
if rt0>rt then14
rt=rt0;15
con f irm =con f irm0;16
ts =ts0;17
return (con f irm,rt,ts);18
case XOR19
foreach v→vchild ∈Edo20
(con f irm0,rt0,ts0)=addWS(vy);21
if con f irm0,∅ ∧ ts0<ts then22
if con f irm ,∅then initially =initially ∪con f irm;23
rt =rt0;24
con f irm =con f irm0;25
ts =ts0;26
return (con f irm,rt,ts);27
case WS28
foreach tuple ∈initially,ws(tuple)=vdo29
if ts(tuple)<ts then30
rt=rt(tuple);31
con f irm =tuple;32
ts =ts(tuple);33
if con f irm ,∅then34
initially =initially\con f irm;35
return (con f irm,rt,ts);36
else37
return (∅,0,0);38
151
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
Function 5calcImpact(v)
input :v∈V
vcomp=vx∈V, τCT (vx)=COMP;1
ein =vy→v∈E;2
switch τCT (v)do3
case COMP4
τ(v)=COMP;5
ρ=calcImpact(vchild);6
return ρ;7
case AND8
τ(v)=XOR;9
contribution =0;10
foreach v→vchild ∈Edo11
ρchild =calcImpact(vchild);12
contribution =contribution +ρchild;13
ρ(ein)=contribution;14
return ρ(ein);15
case WS16
τ(v)=WS;17
ρ(ein)=contribution(σ(v))
invoc(σ(vcomp)) ;
18
return ρ(ein);19
152
7.10. STEP 9: CAUSAL ANALYSIS
Algorithm 6: Feedback tree. Vertices Vand edges Eof a feedback tree are equal to
vertices Vand edges Eof estimated and realized impact tree. Algorithm 6 calculates
the feedback tree by computing for each Web service vertex what its composition impact
is (e.g., Line 5, Algorithm 6). This impact depends on the number of contributions per
composition invocation (i.e., ρ-value), and average SLO when invoked (i.e., σ-value).
Assume Web service S1 has an average response time of 10 ms, while the composition
has 20 ms response time. If S1 contributes in fifty percent of the composition invocations
(i.e., ρ=0.50), the impact factor of S1 is 10
20 ·0.50 =0.25. On average S1 determines
25% of the composition response time.
Furthermore, the color of each Web service and composition is determined by invok-
ing color(real, est) in Line 6 and 7 of Algorithm 6. This function determines deviation
between realized and estimated values as depicted in Function 7. Each edge is annotated
with the realized contribution per composition invocation in Line 9, and color (θvalue) is
determined by calculating deviation between expected and realized contribution in Line
10.
Algorithm 6: Feedback tree
input :EIT(V,E, ρE, τE, σE) and RIT(V,E, ρR, τR, σR)
output :FM(V,E, ρ, τ, σ, θ)
vcomp =v∈V, τE(v)=COMP;1
foreach v∈Vdo2
τ(v)=τR(v);3
if τ(v)=WSthen4
σ(v)=rt(σR(v))
rt(σR(vcomp)) ·ρR(ein);
5
θ(v)=color(σ(v),impact(σE(v)));6
if τ(v)=COMP then θ(v)=color( rt(σR(v))
invoc(σR(v)) ,impact(σE(v)));
7
foreach e∈Edo8
ρ(e)=ρR(e);9
θ(e)=color(ρ(e),ρE(e));10
Function 7color(real,est)
input :real: realized value, est: estimated value
output :color: the color of the edge or vertex
deviation =real−est
est ·100;1
if deviation ≥10 then return red;2
if 10 >deviation ≥5then return yellow;3
if 5>deviation ≥ −5then return green;4
if deviation <−5then return darkgreen;5
The cost SLO of our illustrative example is evaluated and graphically represented
in Figure 7.9. Using the event log abstraction, it is calculated that the average cost for
invoking the composition is 14.47e. This is between 5 and 10% under performance, and,
153
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
COMP
WS 1 WS 2
sum(subset)
IF: 0.32
Cost feedback tree
sum(total) WS 3 sum(one) WS 6
WS 4 WS 5
0.7 0.65 0.95 0.7
0.37 0.58
Cost: € 14.47
0.7 0.7
1
IF: 0.22
IF: 0.2
IF: 0.06 IF: 0.2
IF: 0.2
Deviation %
+
-
0
5
-5
10
_
Figure 7.9: Illustrative example: Cost feedback tree
therefore, colored yellow. Furthermore, we see that only WS 6 costs on average less than
expected, i.e., the service is colored darkgreen. The other services all cost on average
more per invocation from that agreed upon (i.e., colored red or yellow). We see that
the branch with WS 3 is invoked less often than expected, i.e., is colored darkgreen, as
opposed to the branch of WS 4 and WS 5 which is invoked more often than expected, i.e.,
they are colored red. WS 4 has a very low impact on the overall cost (IF 0.06), while the
other Web services have an impact between 0.2 and 0.32.
The result of our approach enables users to:
•Identify how well each service is performing,
•Detect whether services are invoked as often as expected, and
•Determine the impact each service has on the composition regarding its SLOs.
In the given case, we derive that the exceeded composition costs are caused by its
underlying services. These services, in turn, exceed their agreed upon invocation costs.
Although WS 4 violates its costs SLO, its impact is low. Furthermore, the expensive
branch (with WS 4 and WS 5) concerning costs is more often invoked than expected.
The cheaper branch (i.e., the branch with WS 3) concerning costs, in turn, is invoked less
often, causing the overall composition to exceed its agreed upon costs.
7.11 Related work on SLAs
7.11.1 SLA models
An important framework for specifying composite services is the WSLA framework by
Keller et al. [66]. We use their structure and requirements on SLA definitions for our
154
7.11. RELATED WORK ON SLAS
approach. Their framework enables the specification of SLAs which enables monitoring
composite services although this is not treated explicitly. Another framework for specify-
ing web services is the WSOL framework by Tosic et al. [109]. Unique in this approach is
offering service monitoring in classes rather than per instance. Tosic et al. also consider
dependencies between different services in [48].
7.11.2 Managing Web services
Menasce [77] presents response time analysis of composed services to identify impact of
slowed down services. The impact on the composition is computed using a Markov chain
model. The result is a measure for the overall slow down depending on statistical like-
lihood of a service not delivering expected response time. As opposed to our approach,
Menasce performs analysis at design-time rather than providing a runtime based analy-
sis. In addition, our work provides a framework to cover structures beyond a fork-join
arrangement.
A different approach with the same goal is the virtual resource manager proposed by
Burchard et al. [31]. It targets a grid environment where a calculation task is distributed
among different grid vertices for individual computation jobs. If a grid vertex fails to
deliver the promised service level, a domain controller first reschedules the job onto a
different vertex within the same domain. If this action fails, the domain controller at-
tempts to query other domain controllers for passing over the computation job. Although
the approach covers runtime, it follows a hierarchical autonomic recovery mechanism.
MoDe4SLA focusses on identifying causes for correction on the level of business opera-
tions rather than on autonomous job scheduling. Further, in critical path analysis (CPA)
for resource management the preferred order of tasks is determined by analyzing the graph
containing all possible paths [115]. However, in CPA each path shows one possible exe-
cution, while in our analysis the complete graph depicts one execution. Furthermore, in
MoDe4SLA we compare estimated with realized behavior which is not done in CPA.
In the COSMA approach Ludwig et al. [72] describe a framework for the life cycle
management of SLAs in composite services. They recognize the problem of managing
dependencies between different SLAs. However, it is difficult to compare their approach
to ours since the framework is described on a high level and no details on the implemen-
tation are given. Furthermore, their COSMAdoc component describes composite specific
dependencies, but does not explicate what type of dependencies are considered.
The SALMon approach by Oriol et al. [91] aims at monitoring and adapting SOA
systems at runtime. Monitoring is done for violations of SLAs. Furthermore, a deci-
sion component performs corrective actions so that SLAs are satisfied. This approach
has similar goals to our management of SLAs for composite services approach. More
specifically, they focus on the analysis and monitoring of SLAs, and based on the results
management decisions are done. However, their approach does not focus on service com-
positions, but rather on runtime adaptability. As a consequence they are not concerned
with dependencies between different SLAs.
In Moser et al. [81] an approach is described for automatically replacing services at
155
CHAPTER 7. MANAGING DEPENDENCY RELATIONS: SERVICE
COMPOSITIONS
runtime without causing any downtime for the overall system. The BPEL processes are
monitored according to their QoS attributes and replacement of services and partners is
offered on various strategies. Although their approach has similarities to ours, their goals
focus on runtime adaptability, and not on service compositions and their SLA dependen-
cies.
7.11.3 Root Cause analysis
Another research community analyzes root causes in services. In responding approaches
dependency models are used to find causes of violations within a company. Here, com-
posite services are not considered, but merely services the company is responsible for on
its own. For example, Agarwall et al. [5] determine the cause of a problem by using de-
pendency graphs. Especially finding the cause of a problem when a service has an SLA
with different metrics is here a challenging topic. Also Caswell et al. [34] use depen-
dency models for managing internet services. Again, focussing on finding internal causes
for problems. In our work we identify causes of violations in other services rather than in-
ternally. Furthermore, our dependencies between different services are on the same level
of abstraction, while in root cause analysis one service is evaluated on different levels of
abstraction.
7.11.4 Service monitoring approaches
Sahai et al. [100] aim at automated SLA monitoring by specifying SLAs and not only
considering provider side guarantees, but focus also on distributed monitoring, taking the
client side into account as well. Barbon et al. [11] enable runtime monitoring while sepa-
rating the business logic from the monitoring functionality. For each instance of a process
a monitor is created. Unique for this approach is the ability to also monitor classes of
instances, enabling abstraction from an instance level. The smart monitoring approach of
Baresi et al. [12] implements the monitor itself as a service. There are three types of mon-
itors available for different aspects of the system. Their approach is developed to monitor
specifically contracts with constraints. In [13] Baresi et al. present an approach to dy-
namically monitor BPEL processes by adding monitoring rules to the different processes.
These rules are executed during runtime. Our approach does not require modifications
to the process descriptions what might suit better to some application areas. An inter-
esting approach in this direction is work by Mahbub et al. [74] who, as en exception, do
consider the whole state of the system in their monitoring approach. They aim at monitor-
ing derivations of behavior of the system. The requirements for monitoring are specified
in event calculus and evaluated with runtime data. Although many of above mentioned
approaches do consider third parties and also allow abstraction of results for composite
services, none of them addresses how to create this abstraction in detail. Problems like
matching messages from different processes as in our SubscribedNews example where
databases are used, are not considered.
156
7.12. SUMMARY
7.11.5 QoS-based service composition
Although our approach assumes the Web service composition is present, the process of
Web service selection based on QoS criteria for the overall composition is closely related
to our problem. More specifically, our approach monitors and manages the selections
done in the service composition. Therefore, it is important to have an overview of widely
used approaches for QoS based service composition. Many service selection approaches
use linear programming methods although also alternative approaches exist.
Zeng et al. [118] propose a global planning approach for optimal service selection
based on their QoS during execution of the composite service. The problem is addressed
as optimization problem which is solved with a linear programming method. Berbner et
al. [14] describe an approach for Web service composition taking QoS constraints into
account where the authors provide a heuristic based approach. The results are computed
by a relaxed integer program. Ardagna and Pernici [9] provide a Web service selection
approach for service compositions using an optimization approach with mixed integer
linear programming. Their approach allows specification of both local constraints on
Web services as well as global constraints for the composition concerning QoS. Canfora
et al. [32] are an exception to the linear programming approaches and describe an ap-
proach for Web service composition taking QoS constraints into account using Genetic
Algorithms. Their claim is that although Genetic Algorithms are slower than integer pro-
gramming approaches, their approach is better scalable. The aim of their approach is to
do late-binding of services at runtime.
7.12 Summary
In this chapter we apply the method for managing dependency relations between models
for inter-organizational cooperations (see Chapter 4) to monitoring SLAs of composite
services. We show how to apply the different steps. Furthermore, we show that with using
this method it becomes possible to formalize the derivation of impact trees and feedback
trees so that automation and implementation become more straightforward. This case
is illustrated with the use of a running example. In Section 10.3 we discuss the lessons
learnt from applying our method for managing dependencies between inter-organizational
models to the given case.
The main result of this chapter is the use of contribution factors, where we describe
the contribution of each subtree to the composition, and the use of impact factors, where
we describe the contribution of each service to a specific SLO of the composition.
The result supports the company in managing its composite services for detection and
coverage of SLA violations. More specifically, decisions on whether or not to change
content provider, whether or not to change certain SLAs, and which SLAs should be
reconsidered are supported by depicting dependencies between services.
157
CHAPTER 8
PROOF-OF-CONCEPT IMPLEMENTATION: SERVICE
COMPOSITIONS
In Chapter 7 we illustrate the use of our MaDe4IC method for managing SLAs of com-
posite services. In this chapter we show how the results of this analysis are implemented
[24]. We provide a mechanism to identify causes for SLA violations of composite ser-
vices. These causes are either due to under performance of services the composition de-
pends on, or due to differences between estimated behavior of the composition and actual
behavior at runtime. For this implementation we use the dependency relations and algo-
rithms identified in Chapter 7. In Chapter 9 we then use our proof-of-concept prototype
to evaluate usefulness of our solution for managing SLAs of composite services.
We demonstrate the implementation by means of an example scenario case as dis-
cussed in Section 8.1. In Section 8.2 we discuss implemented analysis techniques. These
constraints are adopted from Section 7.8. In Section 8.3 we discuss how our MoDe4SLA
simulator works. Furthermore, Section 8.4 shows how our MoDe4SLA simulator is used
to analyze causes for composition SLA violations, and how a service manager uses visu-
alization results from the simulator to identify these causes.
8.1 Example scenario
In the following we use an abstract example to illustrate the implementation of MoDe4SLA.
The use of an abstract example allows us to focus on the approach, and illustrate the com-
plexity of the problem without obscuring it with real-life details. Figure 8.1 depicts the
composition of our example scenario where invocation of the composite service results in
the invocation of a subset of 17 dependent services. Each invocation of the composition
triggers the invocation of WS 1 - WS 7, WS 13, WS 16, and WS 17. In addition, either
WS 8, WS 12, or the Loop-construct is chosen (due to the XOR-construct). Each outgo-
ing edge of the XOR-construct is annotated with the chance to be chosen compared to its
siblings. For example, the chances to be chosen for WS 8, Loop, and WS 12 are 0.72 :
0.15 : 0.13. When the Loop-construct is chosen, WS 9, WS 10, and WS 11 are invoked in
asequence, which is, on average, repeated 3 times. Furthermore, either WS 14 or WS 15
CHAPTER 8. PROOF-OF-CONCEPT IMPLEMENTATION: SERVICE
COMPOSITIONS
CS:
LOOP
sequence 3x
WS17
AND
AND ORDISC 1/2
XOR
WS16
WS15WS14WS13
WS12
WS11WS10WS9
WS8
WS7WS6
WS5WS4WS3WS2WS1
0.72 0.15 0.13
0.89 0.11
Figure 8.1: Example scenario: Service composition
is invoked (ORDISC-construct with ratio 0.89 : 0.11). Except for the services in the Loop
sequence, all services are invoked in parallel.
Each service has an agreed upon QoS level. This QoS level is part of the SLAs be-
tween provider and customer. Figure 8.2 depicts the same composition as Figure 8.1, but
focusses on the agreed upon QoS levels. Each Web service is annotated with a minimum,
mean, and maximum agreed upon cost and response time for each invocation. These val-
ues are also given for the level of service offered to customers invoking the composite
service.
8.2 Implementation
The implementation of the algorithms from Chapter 7 is discussed in this chapter. There-
fore, we describe specificities of the implementation without discussing the different al-
gorithms in detail again. However, we focus on describing how the algorithms are imple-
mented. The algorithms formalize how to calculate estimated impact trees and realized
impact trees using the composition as depicted in Figure 8.1 (with its estimated values
and, at runtime, realized values for each service as monitored in the event logs). These
trees show how the composite service depends on the services implementing it. The cal-
culations used for the analysis are based on the number of times a service is invoked
per service composition, and on the average SLO value the service achieved. Firstly, we
describe contribution factors that depict the chance a branch in the composition tree con-
tributes to the composition. Contributing branches are branches that influence the SLO
value of the composition. Secondly, we describe how invoked Web services in a composi-
tion contribute to the composite service concerning costs and response time. For this we
use average SLO values. Furthermore, we describe how we combine contribution factors
and service contribution to an overall impact measure of each service on the composition,
namely the impact factors.
160
8.2. IMPLEMENTATION
Composition has agreed upon QoS
:
Response Time (min,mean,max): 41.0, 117.02195, 725.0
Costs (min,mean,max): 4415.4473, 8245.411, 22181.707
AND split and join.
|_Subelement:
| Web Service No 1 with QoS:
| Response Time: ( min, mean, max): 10.0, 11.63, 18.0
| Cost: ( min, mean, max): 210.02309, 313.72, 513.5868
|_Subelement:
| Web Service No 2 with QoS:
| Response Time: ( min, mean, max): 33.0, 37.69, 47.0
| Cost: ( min, mean, max): 846.5581, 963.62225, 1339.1849
|_Subelement:
| Web Service No 3 with QoS:
| Response Time: ( min, mean, max): 22.0, 33.45, 34.0
| Cost: ( min, mean, max): 372.75146, 644.95825, 1061.9478
|_Subelement:
| Web Service No 4 with QoS:
| Response Time: ( min, mean, max): 31.0, 43.39, 60.0
| Cost: ( min, mean, max): 736.048, 909.04694, 1338.7078
|_Subelement:
| Web Service No 5 with QoS:
| Response Time: ( min, mean, max): 7.0, 12.19, 18.0
| Cost: ( min, mean, max): 100.35527, 168.35362, 198.89468
|_Subelement:
| AND split and join.
| |_Subelement:
| | Web Service No 6 with QoS:
| | Response Time: ( min, mean, max): 41.0, 59.62, 62.0
| | Cost: ( min, mean, max): 442.9783, 454.52646, 591.99786
| |_Subelement:
| | Web Service No 7 with QoS:
| | Response Time: ( min, mean, max): 36.0, 60.51, 61.0
| | Cost: ( min, mean, max): 201.85391, 318.47342, 325.6623
| |_Subelement:
| | XOR split and XOR join.
| | |_Subelement, [0.72]:
| | | Web Service No 8 with QoS:
| | | Response Time: ( min, mean, max): 32.0, 60.31, 67.0
| | | Cost: ( min, mean, max): 525.27045, 618.8252, 664.4616
| | |_Subelement, [0.15]:
| | | Loop (Estimated: 5 times).
| | | |_Subelement:
| | | | Web Service No 9 with QoS:
| | | | Response Time: ( min, mean, max): 17.0, 31.58, 33.0
| | | | Cost: ( min, mean, max): 804.11975, 1158.6505, 1446.9174
| | | |_Subelement:
| | | | Web Service No 10 with QoS:
| | | | Response Time: ( min, mean, max): 16.0, 28.44, 54.0
| | | | Cost: ( min, mean, max): 35.12873, 53.35737, 71.33427
| | | |_Subelement:
| | | Web Service No 11 with QoS:
| | | Response Time: ( min, mean, max): 31.0, 36.78, 59.0
| | | Cost: ( min, mean, max): 830.5941, 837.7012, 1149.1959
| | |_Subelement, [0.13]:
| | Web Service No 12 with QoS:
| | Response Time: ( min, mean, max): 5.0, 7.69, 11.0
| | Cost: ( min, mean, max): 625.7165, 1118.7761, 1415.0142
| |_Subelement:
| Web Service No 13 with QoS:
| Response Time: ( min, mean, max): 13.0, 19.05, 32.0
| Cost: ( min, mean, max): 694.0153, 1381.3864, 1965.6458
|_Subelement:
| OR split, DISC join, where 1/2 services are started and 1 must finish.
| |_Subelement, [0.89]:
| | Web Service No 14 with QoS:
| | Response Time: ( min, mean, max): 20.0, 22.43, 24.0
| | Cost: ( min, mean, max): 502.37628, 567.51276, 859.6056
| |_Subelement, [0.11]:
| Web Service No 15 with QoS:
| Response Time: ( min, mean, max): 26.0, 50.12, 81.0
| Cost: ( min, mean, max): 6.94027, 9.2576885, 13.704545
|_Subelement:
| Web Service No 16 with QoS:
| Response Time: ( min, mean, max): 4.0, 8.1, 9.0
| Cost: ( min, mean, max): 156.71298, 285.16486, 325.40204
|_Subelement:
Web Service No 17 with QoS:
Response Time: ( min, mean, max): 30.0, 42.86, 58.0
Cost: ( min, mean, max): 121.94054, 171.77739, 323.83493
Figure 8.2: Example scenario: Agreed upon QoS
161
CHAPTER 8. PROOF-OF-CONCEPT IMPLEMENTATION: SERVICE
COMPOSITIONS
Figure 8.3: Example scenario: Estimated impact tree for cost
8.2.1 Contribution factors
The vertices and nodes of each impact tree indicate how the composition depends on the
different services. In addition, certain quantifications are done to indicate how big this
impact is. Here, we discuss quantification of branches in the impact trees. Each branch
in the tree is annotated with a value. For each invocation, this value indicates the number
of times a branch contributes to the composition. For estimated impact trees these values
are estimations based on the composition structure and additional knowledge (e.g., prefer-
ences for invoking a certain service). For the realized impact trees these values are derived
from event logs. Unless Loop-constructs are present in the composition, each value anno-
tated to an edge is less than or equal to 1 since each service contributes at maximum one
time per composition invocation to the composition value. Consider, for example, Figure
8.3 which depicts the estimated impact tree for costs based on the composition structure
and estimations on number of invocations. The third construct in this tree (i.e., the XOR-
construct) has three outgoing edges. Each edge has its own probability to contribute to the
costs of the composition for each invocation. In this case, each composition invocation,
Web service 8 (WS 8) contributes on average 0.72 times to the overall costs. In other
words, the composition manager expects that WS 8 contributes about 7 out of 10 times to
the composition costs.
For costs the chance to contribute to the composition is equal to the chance of being
invoked. More precisely, if a service is invoked it also is paid for. Since estimations on
which services are more likely to be chosen are present in the composition tree (cf. Figure
8.1), the contribution factor for costs is easily calculated. When there are no estimations
162
8.2. IMPLEMENTATION
available on the likelihood to be chosen, each branch is awarded an equal ratio. For
example, if always one out of two services are invoked, and no preference ratio is given,
our implementation assumes these chances to be equal.
For response time the situation is a bit more complex. Not every invoked service also
contributes to the overall response time. For example, in two parallel running branches,
fastest responding branch does not contribute to the response time of the composition
since the composition waits for the slowest responding branch anyway. As a consequence,
the chance to contribute to the response time of the composition does not only depend on
whether a branch is invoked, but also on the performance of branches running in parallel,
i.e., on the behavior of its siblings. In the implementation, the default is that the chance
a service is chosen is equal to the chance a service contributes, except when the parent
construct informs the branch about sibling branches that are more likely to contribute. A
precise description of this algorithm is found in Chapter 7 where Function calc(v) (see
page 142) determines the probability a service gets invoked, and actually contributes to
the overall composition.
8.2.2 Service contribution
For calculating estimated average contribution of a service to the overall response time
or cost of the composition, we use average agreed upon response time and cost in the
SLA. For the realized average contribution, we use average value of these invocations of
services where the invocation actually contributed to the overall cost or response time of
the composition. As a result, not every invoked service is considered in these calcula-
tions. Therefore, our approach does not substitute bilateral monitoring since the aim is to
diagnose causes for violations in the composition.
Average realized service contribution concerning costs is calculated by considering
each invoked service, since invocation of a service means the service is paid for. In other
words, realized average costs for a service are equal to average realized contribution for a
service.
Average realized service contribution concerning response time is again more com-
plex to calculate since not each invocation of a service means the service contributes to
the overall response time. This is, for example, the case in branches that run in parallel.
When only considering branches and services that influence the QoS of the composi-
tion, it also becomes possible to identify outliers. These outliers are services that might
on average function very well (and, therefore, might satisfy its SLAs), but show great
variability concerning their QoS, and, therefore, cause the overall composition to violate
its SLA on a regular basis.
In our proof-of-concept implementation we, therefore, make a distinction between
unconsidered services and rolled back ones. The first category contains services which
are invoked and finished before the overall composition finishes, but which nevertheless
do not contribute to overall response time. These services contribute to the cost since they
are invoked. The second category contains services which are invoked, but did not yet
finish when the overall composition finishes. This situation occurs, for example, when
163
CHAPTER 8. PROOF-OF-CONCEPT IMPLEMENTATION: SERVICE
COMPOSITIONS
only considering the fastest responding service. These services contribute to costs, but
not to overall response time.
8.2.3 Impact factors
In impact trees each service is annotated with an impact factor (cf. IF in Figure 8.3). This
impact factor is a combination of contribution factor and average service contribution.
The value indicates the average contribution percentage to the composition concerning an
SLO.
We calculate the impact factor by multiplying the contribution factor (i.e., the number
of times a service contributes per composition invocation), with the average service con-
tribution (i.e., the average SLO value of a service when it contributes to the composition).
We divide this value with the average SLO value of the composition. Therefore, the im-
pact factor of a service indicates its average contribution. For example, in Figure 8.3 WS
13 has an expected impact factor of 0.1675 for costs. This indicates it is expected that WS
13 contributes on average 16.75% to the overall costs of the composition. As a result, in
the MoDe4SLA analysis, impact factors represent a combination of the structure of the
composition (i.e., the branch value) and the SLO values of the services. Consequently,
impact factors of the services in one composition add up to 1.
8.3 Generation and execution
For the MoDe4SLA approach, we implement a simulator to generate random service
compositions with accompanying SLAs. In addition, this simulator simulates invocations
of the composition where the different SLAs are regularly violated. These invocations
are monitored by logging necessary information, for example, number of invocations,
response times, and costs. Furthermore, our implementation provides necessary analysis
of the compositions and event logs, and it creates the impact and feedback trees. For the
simulation part we adapt and extend SENECA [62], an existing simulation environment
for composite services.
This simulation environment implements (a) a structural model of service composi-
tions and (b) a QoS model for handling QoS attributes of the services in the composition.
The generation of compositions is performed randomly with particular input parameters.
The parameters are the number of services in total and the range of the planned QoS deliv-
ered. By using the standard random number generator of the Java platform, the software
then generates the following two main parts.
Firstly, the structure of the composition is created. At a given point, the generation
software decides between placing a service or a composition structure containing ser-
vices, both with equal probability. Based on this schema, compositions can result in a flat
sequence of services, or contain nested structures forming a more sophisticated execution
plan. There are seven basic executions patterns [62] chosen from the workflow patterns
by Aalst et al. [1]. The number of services incorporated in the composition is determined
by the user.
164
8.4. VISUALIZATION
Secondly, the QoS delivered by the service is created. Originally, this function is
used to perform simulations for optimizing QoS of service compositions [62]. We extend
SENECA with the possibility of SLA violation at runtime by implementing some ran-
domization. The generator builds up a data structure in application memory that allows
the environment to simulate the execution of a service composition.
The discrete event simulation simulates the pass of a second (this is the unit of the
simulated response time SLO), and tracks the progress among the services of the com-
position. If a service is finished, the next service is triggered according to the execution
plan. Each service implements the simulation to either start or finish the work as planned.
In addition, a random function allows to violate the agreed upon QoS by running longer
or charging higher costs. The simulation software generates a log output that contains all
events occurring during execution of the composition. For example, consider Figure 8.4
that depicts part of the event log created at runtime for our example scenario. This log file
shows aggregated information on realized average values of the services, its total number
of invocations, and the average number of times a loop is invoked per composition. Aside
from these aggregated logs, logs with raw data are available as well. Furthermore, we
add to SENECA creation of impact trees using the log after passing the total execution
time for the composition. Calculations and derivations are done according to the different
algorithms presented in Step 7 of Section 7.8. At the end of the simulation the user has
the feedback models and monitoring results available for use.
8.4 Visualization
The goal of MoDe4SLA is to provide information on the composition performance to
service developers through the graphical feedback model as generated by our MoDe4SLA
simulator. This information is used to evolve the composition by tuning the structure or
renegotiating SLAs of the services. The feedback trees (cf. Figure 8.5 and Figure 8.6)
indicate differences between design time estimations based on SLAs, and realized values
monitored in the event log. More particular, the feedback tree shows the cause of an SLA
violation.
The difference between agreed upon and real-life values is depicted using colors for
branches to indicate deviations in real life from estimated contribution factors. Colored
services indicate deviations in real life from agreed upon average service contributions.
As discussed, the impact factors indicate the combination of these two measures show-
ing average contribution to the composition. Every service is annotated with its realized
impact factor.
For color coding we use red to indicate worse performance than expected based on
the SLA, while green indicates proper performance of the service. Yellow indicates the
service is not performing perfectly, but still within the boundaries set by the company, and
dark green indicates a service runs even better than the company anticipated. Uncolored
services indicate the services never contributes to the overall response time in the consid-
ered event log. Therefore, their impact is zero. The edges are colored in the same manner,
165
CHAPTER 8. PROOF-OF-CONCEPT IMPLEMENTATION: SERVICE
COMPOSITIONS
Realized
QoS
of the composition:
Response Time (min,mean,max): 48.0, 174.86957, 1036.0
Costs (min,mean,max): 5590.6934, 8678.282, 25450.111
Total number of invocations: 23
AND split and join.
|_Subelement:
| Web Service No 1 with QoS:
| Response Time: ( min, mean, max): 7.0, 12.565217, 21.0
| Cost: ( min, mean, max): 39.184357, 288.40488, 607.5144
| Total # of invocations: 23
|_Subelement:
| Web Service No 2 with QoS:
| Response Time: ( min, mean, max): 30.0, 40.434784, 63.0
| Cost: ( min, mean, max): 335.96082, 922.88495, 1502.9639
| Total # of invocations: 23
|_Subelement:
| Web Service No 3 with QoS:
| Response Time: ( min, mean, max): 20.0, 37.869564, 54.0
| Cost: ( min, mean, max): 161.43155, 574.28046, 1251.6294
| Total # of invocations: 23
|_Subelement:
| Web Service No 4 with QoS:
| Response Time: ( min, mean, max): 14.0, 40.04348, 69.0
| Cost: ( min, mean, max): 341.64148, 848.5004, 1338.3586
| Total # of invocations: 23
|_Subelement:
| Web Service No 5 with QoS:
| Response Time: ( min, mean, max): 1.0, 13.782609, 21.0
| Cost: ( min, mean, max): 62.765213, 157.46265, 242.28073
| Total # of invocations: 23
|_Subelement:
| AND split and join.
| |_Subelement:
| | Web Service No 6 with QoS:
| | Response Time: ( min, mean, max): 33.0, 61.608696, 92.0
| | Cost: ( min, mean, max): 257.6671, 449.0448, 714.92725
| | Total # of invocations: 23
| |_Subelement:
| | Web Service No 7 with QoS:
| | Response Time: ( min, mean, max): 31.0, 61.304348, 104.0
| | Cost: ( min, mean, max): 172.90501, 330.1317, 451.6234
| | Total # of invocations: 23
| |_Subelement:
| | XOR split and XOR join.
| | Total # of invocations: 23
| | |_Subelement, [0.74]:
| | | Web Service No 8 with QoS:
| | | Response Time: ( min, mean, max): 33.0, 67.588234, 101.0
| | | Cost: ( min, mean, max): 456.34702, 591.18994, 754.9042
| | | Total # of invocations: 17
| | |_Subelement, [0.13]:
| | | Loop (Estimated: 5 times).
| | | On average 7.6666665 iterations per invocation, with;
| | | 7 iterations minimum
| | | 9 iterations maximum
| | | Total # of invocations: 3
| | | Total # of iterations: 23
| | | |_Subelement:
| | | | Web Service No 9 with QoS:
| | | | Response Time: ( min, mean, max): 17.0, 34.391304, 55.0
| | | | Cost: ( min, mean, max): 655.4398, 1162.9155, 1749.987
| | | | Total # of invocations: 23
| | | |_Subelement:
| | | | Web Service No 10 with QoS:
| | | | Response Time: ( min, mean, max): 9.0, 31.782608, 66.0
| | | | Cost: ( min, mean, max): 28.277946, 57.33591, 104.81079
| | | | Total # of invocations: 23
| | | |_Subelement:
| | | Web Service No 11 with QoS:
| | | Response Time: ( min, mean, max): 7.0, 40.04348, 81.0
| | | Cost: ( min, mean, max): 363.83832, 811.3514, 1204.1954
| | | Total # of invocations: 23
| | |_Subelement, [0.13]:
| | Web Service No 12 with QoS:
| | Response Time: ( min, mean, max): 3.0, 7.0, 14.0
| | Cost: ( min, mean, max): 388.61462, 854.22363, 1091.9017
| | Total # of invocations: 3
| |_Subelement:
| Web Service No 13 with QoS:
| Response Time: ( min, mean, max): 10.0, 22.043478, 37.0
| Cost: ( min, mean, max): 203.39478, 1530.2379, 2630.816
| Total # of invocations: 23
|_Subelement:
Figure 8.4: Example scenario: Realized QoS
166
8.4. VISUALIZATION
Figure 8.5: Monitoring example scenario: Cost feedback tree
for example, red indicates the edge contributes more often than expected.
Figure 8.5 depicts the cost feedback tree of our running example. The yellow colored
composition indicates that the SLO for composition cost is not completely met. This lack
of performance is caused by two factors. Performance of service WS 13 is the first factor.
This service is malfunctioning (i.e., violates its SLA, and is, therefore, colored red), and
has an impact factor (IF) of 0.1763. The latter means that almost 18% of the overall costs
are contributed by this service. Structure of the composition is the second factor. Services
WS 9, WS 10, and WS 11 are contributing more often than expected (i.e., red incoming
edges). This increased number of service invocations for each composition invocation
causes elevated overall costs.
In this case, several solutions are possible. For example, badly performing WS 13 can
be replaced or renegotiated. It is also possible to change the structure of the composition
in such a way that WS 9, WS 10, and WS 11 are not invoked that often. Furthermore, we
conclude that although WS 17 is not functioning properly, its impact factor is too low (i.e.,
2%) such that it cannot be the main cause for the composition violation. Furthermore, sev-
eral services are over-performing (i.e., they are dark green). If bad performance problems
are solved, these over-performing services positively influence composition costs.
Figure 8.6 depicts the response time feedback tree of our running example. Response
time wise, the composition is under-performing (i.e., it is colored red). The same holds
for most services it depends on. The three services with highest impact factors (i.e., WS 8,
WS 9, and WS 10) are colored yellow or red. Together, they are responsible for over 50%
of overall response time. Furthermore, the structure of the composition shows deviations
167
CHAPTER 8. PROOF-OF-CONCEPT IMPLEMENTATION: SERVICE
COMPOSITIONS
Figure 8.6: Monitoring example scenario: Response time feedback tree
as well. Several branches are colored red, i.e., these branches are contributing more often
than expected. In addition, these branches point to services that are responding too slowly.
These factors together result in a slow response time of the composition.
In this case, the most obvious solutions are to replace or renegotiate all under per-
forming services, and to adapt the structure of the composition in such a way that certain
branches contribute less frequent to the overall response time. Another solution is to
adapt the offered SLO for response time to customers so that slower response times are
expected. Furthermore, we conclude that many services have no impact on the composi-
tion concerning response time (i.e., they are not colored), and, therefore, are not consid-
ered for a causal analysis of bad performance of the composition. Excluding a subset of
services for causal analysis saves valuable maintenance time. In addition, it is concluded
that these services perform better than necessary. Possibly, their SLOs are renegotiated,
or maybe they are replaced with cheaper (but slower) services.
The impact factors, together with coloring branches and services, ease identification of
badly performing services with high impact. Consequently, management of compositions
consisting of many services becomes more straightforward.
168
8.5. SUMMARY
8.5 Summary
In this chapter we show how our MoDe4SLA simulator for monitoring and analyzing
causes for SLA violations is implemented and used to manage service compositions.
More precisely, we show how to implement the different analysis algorithms introduced
in Chapter 7, and how monitoring and analysis at runtime work. In addition to imple-
mentation of the constraints, and monitoring of the model, we depict how to use this
information for managing the SLAs of the composition. More particularly, we show how
to visualize deviations between estimations in the composition and runtime results in the
event log. Our analysis enables identification of causes for violations that are missed in
traditional bilateral monitoring approaches.
169
CHAPTER 9
EVALUATION OF MODE4SLA: SERVICE
COMPOSITIONS
MoDe4SLA identifies complex dependencies between Service Level Agreements (SLAs)
in a service composition. By explicating these dependencies, causes of SLA violations of
a service might be explained by malfunctioning of the services it depends on. MoDe4SLA
assists managers in identifying such causes. Effectively managing compositions results
in competitive service level offerings to customers with maximum profit for the business.
Furthermore, insights on services run by other providers, helps managers to plan negotia-
tion strategies concerning SLAs.
In this chapter we discuss possibilities for evaluating the MoDe4SLA approach [19].
We discuss effectiveness for the business if maintenance is done using our approach, and
usefulness for managers burdened with actual maintenance of compositions. Effective-
ness is evaluated by comparing runtime results of SLA management using MoDe4SLA
with runtime results of unsupported management. Indicators for effectiveness are cost
reduction, and increase in customer satisfaction. We discuss our evaluation plan in Sec-
tion 9.1, while the evaluation itself constitutes future research. Usefulness is evaluated
by asking experts to manage simulated runs of service compositions using MoDe4SLA.
Their opinion on the approach is an indicator for its usefulness. This part of the evaluation
and its setup are discussed in Section 9.2. Following this, we discuss the course of the
evaluation and evaluation results in Sections 9.3 and 9.4, respectively.
Since we do not have access to real composition monitoring data, we use the imple-
mentation of our MoDe4SLA simulator for running composite services as discussed in
Chapter 8. Experts from both industry and academia are asked to manage these generated
compositions, both with and without using MoDe4SLA.
9.1 Evaluation plan for effectiveness
To evaluate effectiveness of MoDe4SLA, we plan to test performance of compositions
managed by experts using MoDe4SLA. We compare these results with a control group
that does not use MoDe4SLA. The latter applies when bringing actors in the composition
CHAPTER 9. EVALUATION OF MODE4SLA: SERVICE COMPOSITIONS
Simulator
Gather
runtime
data
Generate
feedback
models
Control group Test group
Renegotiate
SLAs Renegotiate
SLAs
Generate
composition
& SLAs
Generate
agent
behavior
Generate
impact
models
Generator
Run & rerun
composition
Analyzer
Figure 9.1: Evaluating effectiveness
closer to their goal, i.e., when the approach points to services causing bad performance of
the composition. The level of customer satisfaction and profits made by the company are
key indicators for evaluating effectiveness:
The MoDe4SLA approach is considered to be effective if managing a service
composition using this approach leads to better results than managing the com-
position without it.
We define better in this case as having better business results. In our opinion, this is
a twofold process, where both customer satisfaction and profit are maximized (cf. Table
9.1). We assume customer satisfaction is high if the number of SLA violations is low,
costs for the customer are low, and response time is low. We assume violations being
associated with high penalties having a more negative impact on customer satisfaction
than low penalties. Therefore, customer satisfaction is measured through three indicators:
payments for violations, average response time, and average costs for the composition (cf.
Table 9.1).
Maximizing profit is achieved through minimizing costs and maximizing income (cf.
Table 9.1). In our case, these costs consist of costs for services and payments for penalties.
Income is generated through payments by customers and payments by providers for SLA
violations. The total payments for services to providers and for SLA violations paid to
customers are subtracted from this income.
To evaluate effectiveness, we plan to extend the implementation so that it becomes
possible to rerun the composition after some management choices have been made by the
172
9.1. EVALUATION PLAN FOR EFFECTIVENESS
Minimize Maximize
violation costs -
Customer Satisfaction average response time -
average costs -
Profits service costs customer payments
violation payments violations paid by providers
Table 9.1: Effectiveness indicators
expert. Figure 9.1 depicts an overview of the effectiveness evaluation approach. Further-
more, we adapt parts of the service behavior, we add a renegotiation of SLAs, and finally
we evaluate effectiveness of the approach.
In real life, services in a composition behave differently than expected. These differ-
ences arise, for example, due to different content of services, and different services are
offered by different providers. The difference in behavior, together with the complexity
of the composition structure, make it difficult to manage the services. In addition, man-
agers can neither influence behavior of services provided by other companies nor can they
predict their behavior other than by relying on SLAs. To simulate this real-life complex-
ity, we implement different types of behavior for services. For example, some simulated
services have low variability in response time, and never violate the SLA, while other ser-
vices have higher variability in response time, and violate the SLA more frequently. Each
simulated service gets assigned a behavior type at design time. Which type of behavior is
assigned to the service, is unknown to the participants in the experiment.
To realize this, we implement agents to steer the different services in a composition.
Each agent gets assigned a behavior type, for example, the reliable behavior type. Behav-
ior of the service depends on both behavior type and agreed upon SLA. For example, if
the agent behavior type is reliable and agreed upon response time is lower than 10 ms, the
simulator will generate a random distribution of response times for the next 100.000 in-
vocations. This distribution is created with the parameters reliable and lower than 10 ms.
During the simulation, with each invocation of the service, a response time is randomly
chosen from this distribution. As a result each service shows different behavior, fitting
its SLA. Some services might violate their SLAs more severely, or more frequently than
other services due to their assigned behavior type.
After running the composition the expert is asked to renegotiate SLAs for a subset of
the services. In practice, determining which SLAs to renegotiate is particulary difficult
for complex compositions, i.e., compositions with many services and constructs. Since
the MoDe4SLA tool graphically pinpoints badly performing services and, moreover, indi-
cates the impact these services have on the composition, it becomes possible to prioritize
SLAs, decreasing management efforts.
As described, services in the simulator have unique behavior: some perform with
only minor deviation in, for example, response time, while others fluctuate more. In a
perfect agreement, the SLA between provider and customer reflects this behavior exactly.
173
CHAPTER 9. EVALUATION OF MODE4SLA: SERVICE COMPOSITIONS
In practice, however, it is necessary to monitor service behavior and to renegotiate the
SLAs for badly performing services. In these negotiations provider and customer have
conflicting interest since both aim at maximizing monetary benefits. To simulate this
in the evaluation, the experts are asked to select a subset of services for renegotiation
after the first run. Each service agent offers three new possible SLAs to the expert. For
example, the original SLA has fast response time, but low violation penalties. A newly
offered SLA by the agent might have slower response time, but high penalties when being
violated. These new SLAs are generated taking the behavior type of the agent as well as
the original SLA into account. Some of the new SLAs will fit better to the service from
the customer perspective and some will fit the service better from a provider perspective.
The challenge for the expert is to make choices beneficial for his company.
We use one test group and one control group for each tested service composition. The
test group uses MoDe4SLA to choose services they want to renegotiate, while the control
group uses log files only. MoDe4SLA is designed to assist the user in making choices on
which services to renegotiate. Furthermore, MoDe4SLA pinpoints to the exact problems
of the service so that choices between newly offered SLAs are easier to make. If the expert
successfully identifies services with high impact on the composition and performing badly
according to their SLAs, renegotiation will have to result in better runtime results of the
test group in comparison to the control group (cf. Table 9.1).
9.2 Evaluating usefulness: Setup
To evaluate usefulness, we interview experts, asking them to make a statement on how
useful they perceive the approach when managing the compositions. We use the following
criterion to evaluate usefulness:
MoDe4SLA is considered as being useful when experts testing it perceive the
feedback given by MoDe4SLA as more useful for managing and maintaining
the composition than when only using bilateral monitoring results.
Common management approaches return bilateral monitoring results to the user. They
do not provide information on the relation between the different services, but merely re-
turn performance of each individual service. For evaluating our MoDe4SLA approach,
the simulator (cf. Section 8.3) is able to perform a discrete event simulation when run-
ning the composition with service candidates. Figure 9.2 depicts an overview of this
simulator’s functionality. SENECA randomly generates a composition structure for a
given number of services. Actually considered structures in the simulator are sequence,
loop, XOR-split/XOR-join, AND-split and OR-split (with either a normal join or a dis-
criminative join). A discriminative join indicates the structure succeeds if a subset of
incoming services succeeds. For example, when only considering the fastest three out of
five responding services, this is a discriminative join.
We extend the implementation of an existing simulator, SENECA [62], with generat-
ing impact models and with an analyzer module (cf. Figure 9.2). This simulator randomly
174
9.2. EVALUATING USEFULNESS: SETUP
Simulator
Gather
runtime
data
Generate
feedback
models
Generate
composition
& SLAs
Generate
impact
models
Generator
Run
composition
Analyzer
1 2
Figure 9.2: Evaluating usefulness
generates a composition structure for a given number of services. To each created service
in the composition a randomly generated SLA is assigned. The impact models are derived
based on the composition structure and SLAs. SENECA simulates invocation of services
according to the composition structure. Accordingly, services might violate their SLAs.
The simulator gathers runtime data and generates the feedback models.
The experts for our evaluation are from both academia and industry. We start each
session with a training period to explain our approach and the simulator. Furthermore,
we provide a presentation, and we explain two complete examples. After the training
period we start the evaluation. For this, we prepare three different types of compositions
with respect to complexity. The complete set of documents handed out to the experts for
evaluation, including the questionnaire, is depicted in Appendix A.2. The first test case
consists of five services with three constructs. The second test case consists of ten services
with one OR-split and one discriminative join. The third test case consists of seventeen
services connected through five constructs.
Each test case is invoked for a random number of times in the simulator. For the first
test case this is 81 times, for the second one 260 times, and for the third case 23 times. For
each case it holds that SLA agreements for the services are violated from time to time.
These runtime results are gathered by the simulator for classical bilateral monitoring as
well as for our instance-based monitoring approach. For each composition we prepare two
documents. The MoDe4SLA document contains the feedback models for both response
time and costs, while the control document contains performance data for each service,
but does not provide information on how they are related. The main goal of our evaluation
is to test the following hypothesis:
175
CHAPTER 9. EVALUATION OF MODE4SLA: SERVICE COMPOSITIONS
The MoDe4SLA document has a clear benefit over the control document for
managing the composition.
We evaluate this hypothesis by conducting a survey among the experts where we find
out how they feel about:
RQ1 Accuracy of identifying malfunctioning services using MoDe4SLA com-
pared to using bilateral monitoring results,
RQ2 Efficiency when identifying malfunctioning services using MoDe4SLA
compared to using bilateral monitoring results, and
RQ3 Confidence the experts have in their answers when using MoDe4SLA
compared to using bilateral monitoring results.
Aside from testing the above mentioned hypothesis, the aim of this evaluation is also
to learn about following items:
RQ4 How complex is the MoDe4SLA approach for users?
RQ5 Which possible improvements for the MoDe4SLA approach do experts
suggest?
RQ6 Is there related work that we overlooked in our literature study which is
suggested by our experts?
For this purpose, we prepare a questionnaire containing 49 questions that experts an-
swer before, during and after the evaluation. Most questions have a typical five-level
Likert item to rate the response of the experts:
1. Strongly disagree
2. Disagree
3. Neither agree nor disagree
4. Agree
5. Strongly agree
9.3 Course of evaluating usefulness
Our evaluation starts at Friday 9 January 2009 with a test run where we do the evaluation
with three colleagues. This test run is intended to find out particular problems or errors
176
9.4. CONCLUSIONS FROM EVALUATING USEFULNESS
in examples, test cases, and questionnaire. The result is the addition of a front sheet that
depicts the composition graphically. The minutes of this evaluation can be found in Ap-
pendix A.1. After this test run, we conduct six more sessions with in total 34 participants
from several universities and companies. In general, such a session consists of three parts:
1. A PowerPoint presentation of at least 15 minutes explaining in detail the goal of
the approach.
2. Discussion of two example cases where the presentation of both bilateral monitor-
ing results and MoDe4SLA feedback model results are explained. This explanation
includes a discussion on how to interpret results.
3. The actual evaluation consists of a sequence of events:
(a) Answer a set of introductional questions.
(b) Study the first test case composition with expected values.
(c) Answer a set of questions about the composition complexity.
(d) Study bilateral monitoring results.
(e) Answer a set of questions about these results.
(f) Study MoDe4SLA feedback models.
(g) Answer questions about these models.
(h) Repeat these steps for the second and third test case.
(i) Conclude with answering some general questions.
9.4 Conclusions from evaluating usefulness
In this section we present the most important results of our evaluation. First, we introduce
some demographics after which we discuss statistics from the answers that relate to the
questions listed in Section 9.2. We conclude with some interesting results when analyz-
ing relations between different outliers in questions. A complete list of statistics on all
questions can be found in Appendix A.3. Please, note that answers to Question 48 are not
included since these are names and email addresses of our participants.
9.4.1 Demographics
Two of our experts come from industry, nine come from both industry and academia,
and 23 experts come from academia. 15% of the experts have experience using tools for
managing composite services, and the same percentage in developing such tools. 60% of
the participants have not worked with composite services, while the remaining 40% have
varying experience from less than a year to over three years. Only 9% of the participants
consider themselves having a high level of expertise in managing composite services,
while 32% are undecided, and 59% consider themselves having a low level of expertise.
177
CHAPTER 9. EVALUATION OF MODE4SLA: SERVICE COMPOSITIONS
0 %
1 0 %
2 0 %
3 0 %
4 0 %
5 0 %
6 0 %
7 0 %
8 0 %
s tro n g ly
d is a g re e d is a g re e n e ith e r
a g re e
n o r
d is a g r e e
a g r e e s tro n g ly
a g re e
C om pos it io n c o m p le x ity
5 s e rvic e s
1 0 s e rvic e s
1 7 s e rvic e s
Figure 9.3: The offered composition appears to be complex.
We conclude that although our participants are familiar with service compositions, on
average, their expertise in managing them is not high. The advantage is that this inexpe-
rience helps us in determining how difficult it is to learn to manage service compositions
with MoDe4SLA. As disadvantage, we cannot expect much feedback on possible other
approaches for managing service compositions our participants are aware off.
9.4.2 Statistics
We start each test case with a question on how complex the participants feel the test case
is (Test Case 1 with 5 services: Question 8, Test Case 2 with 10 services: Question 19,
Test Case 3 with 17 services: Question 30) (cf. Figure 9.3). We add this question since
we assume the more complex the composition, the more useful MoDe4SLA. For exam-
ple, in our opinion, Test Case 1 is relatively easy to manage since it only considers 5
Web services. Although the participants consider the different test cases to be of differ-
ent complexity, and although participants appreciate using MoDe4SLA even more when
considering the complex test case (i.e., Test Case 3), these differences are much lower
than expected. Results are shown when evaluating questions in the following paragraphs.
First we evaluate questions related to the benefits from using MoDe4SLA compared to
not using our monitoring approach (i.e., RQ1, RQ2, and RQ3).
RQ1: Accuracy. We want to know whether participants feel identifying problematic
services is done more accurately with than without MoDe4SLA. We have two questions
giving us an insight on this.
Firstly, we ask participants for each test case, and for both response time and costs
whether they perceive identifying the impact each service has on the composition easier
178
9.4. CONCLUSIONS FROM EVALUATING USEFULNESS
0 %
5 %
1 0 %
1 5 %
2 0 %
2 5 %
3 0 %
3 5 %
4 0 %
4 5 %
5 0 %
d is a g r e e n e ith e r
a g r e e
n o r
d is a g r e e
a g r e e s tr o n g ly
a g r e e
1 0 s e r v ic e s ,
c o s t s
Figure 9.4: Concerning costs: It is easier to determine the impact each service has on the
composition with the analysis than without it.
0 %
10%
20%
30%
40%
50%
60%
s t ro n g ly
d is a g re ed is a g re e n e it h e r
a g re e
n o r
d is a g re e
a g re e s t ro n g ly
a g re e
5 s e r vic e s
1 0 s e r v ic e s
1 7 s e r v ic e s
Figure 9.5: MoDe4SLA approach is helpful when managing this composition with regard
to accurately depicting malfunctioning services.
179
CHAPTER 9. EVALUATION OF MODE4SLA: SERVICE COMPOSITIONS
0 %
10 %
20 %
30 %
40 %
50 %
60 %
dis a g re e n e ith er
ag r e e
n or
d is a g r e e
a g re e s tro n g ly
a gr e e
Ea s y c o s t r e la tio n id e n tific a tio n
1 0 s e r v ic e s ,
c o s t s
Figure 9.6: Concerning costs: It takes less time to see relations between different services
and the composition.
with MoDe4SLA than without MoDe4SLA (for Test Case 1: Questions 15 and 16, for
Test Case 2: Questions 26 and 27, for Test Case 3: Questions 37 and 38). Looking at
results, we derive that, in general, MoDe4SLA is perceived as more useful for response
time than for costs, and as more useful for Test Case 3 than for Test Cases 1 and 2. The
majority perceives the use of MoDe4SLA as very helpful for easier identification. Figure
9.4 depicts the histogram with least positive responses for our approach. It entails over
80% of the participants agreeing or strongly agreeing to the statement. This is Question
26 for costs in Test Case 2.
Secondly, for each test case we ask participants whether they feel MoDe4SLA is help-
ful when managing the composition with regard to accurately depicting malfunctioning
services (for Test Cases 1, 2, and 3, and Questions 18, 29, and 40). Figure 9.5 depicts
results for these questions. We conclude that 75-80% of the participants agree or strongly
agree that MoDe4SLA is helpful to accurately depict these services.
RQ2: Efficiency. We want to know whether participants feel that using MoDe4SLA
for managing service compositions is more efficient than managing such compositions
without our approach. Again, two sets of questions give us insights into this topic.
Firstly, for each test case, and for both response time and cost we ask participants to
respond to the statement that it takes them less time to see relations between the different
services in a composition when using MoDe4SLA. Since MoDe4SLA relies on identi-
fying relations and dependencies between the services, we assume that MoDe4SLA is
helpful when trying to identify these relations in the management phase. The relations
are used to do a causal analysis. Here, depending on the question, 85-100% of the partic-
180
9.4. CONCLUSIONS FROM EVALUATING USEFULNESS
0%
10%
20%
30%
40%
50%
60%
strongly
disagree
disagree neither agree
nor disagree
agree strongly
agree
5 services
10 services
17 services
Figure 9.7: MoDe4SLA approach is helpful when managing this composition with regard
to faster selecting services to renegotiate.
0 %
10%
20%
30%
40%
50%
60%
le s s e q u a l m o r e
5 s e r v i c e s
1 0 s e r v i c e s
1 7 s e r v i c e s
Figure 9.8: After seeing the MoDe4SLA analysis, how is your confidence about the ser-
vice selection for renegotiation you made before?
ipants agree or strongly agree with this statement. In Figure 9.6 we depict the results for
the least positive responses for our approach. This is Question 24 for costs in Test Case 2.
Secondly, for each test case we ask participants whether they feel MoDe4SLA is help-
ful when managing the composition with regard to faster selecting services to renegotiate
(for Test Case 1, 2, and 3, and Questions 18, 29, and 40). Figure 9.7 depicts results
for these questions. We conclude that around 90% of the participants agrees or strongly
agrees that MoDe4SLA is helpful to faster select these services.
RQ3: Confidence. To evaluate how confident participants are when they make a choice
on which services to adapt to get a better performance of the composition, we ask three
questions per test case. Firstly, we ask how confident they are making a choice before
seeing the MoDe4SLA models, secondly, we ask how confident they are about their orig-
inal choice when seeing the MoDe4SLA models, and thirdly, we ask how confident they
are in making a choice when considering the MoDe4SLA models.
The aim of the second question is to find out whether participants feel MoDe4SLA
181
CHAPTER 9. EVALUATION OF MODE4SLA: SERVICE COMPOSITIONS
0 %
5 %
1 0 %
1 5 %
2 0 %
2 5 %
3 0 %
3 5 %
4 0 %
s t r o n g l y
d i s a g r e ed is a g r e e n e it h e r
a g r e e
n o r
d is a g r e e
a g r e e s t ro n g l y
a g r e e
5 s e r v i c e s
1 0 s e r v ic e s
1 7 s e r v ic e s
Figure 9.9: Assume only a subset of services can be renegotiated regarding their SLAs. I
would feel confident in selecting services for renegotiation.
0 %
1 0 %
2 0 %
3 0 %
4 0 %
5 0 %
6 0 %
s t r o n g l y
d i s a g r e ed is a g r e e n e it h e r
a g r e e
n o r
d is a g r e e
a g r e e s t ro n g l y
a g r e e
5 s e r v i c e s
1 0 s e r v ic e s
1 7 s e r v ic e s
Figure 9.10: Assume only a subset of services can be renegotiated regarding their SLAs.
I would feel more confident in selecting services for renegotiation with MoDe4SLA than
without.
182
9.4. CONCLUSIONS FROM EVALUATING USEFULNESS
0%
10%
20%
30%
40%
50%
neither agree
nor disagree agree strongly
agree
Figure 9.11: MoDe4SLA is helpful for managing service compositions.
gives additional support. If they feel more or less confident, MoDe4SLA apparently gives
them additional insights. If they did not change their opinion, MoDe4SLA does not give
additional insights. Furthermore, comparing the answers given to the first question and
the answers given to the third question, gives insights whether participants feel more
confident making choices when using MoDe4SLA than without using the approach. The
change in confidence the experts have (i.e., the second question) is depicted in Figure
9.8. Here, we see that for each test case at least 80% of the participants changes their
confidence level.
The confidence level of participants before considering MoDe4SLA is depicted in
Figure 9.9. Here, we see that first and second test case have reasonable confidence levels,
but there is no confidence in the third test case. In Figure 9.10 we see that the confidence
level goes up for all test cases after participants see the MoDe4SLA files.
From these results we conclude that, on average, participants feel more confident
when making choices on which services to adapt using MoDe4SLA than without it.
In the previous three paragraphs we review evaluation results concerning accuracy,
efficiency and confidence levels. Besides testing usefulness of our approach with these
indicators, we ask participants at the end of the survey to respond to the statement that
using MoDe4SLA is useful when managing composite services. Corresponding results
are depicted in Figure 9.11. We see that none of the participants disagrees or strongly
disagrees with this statement. 94% of the participants agrees or strongly agrees with it.
RQ4: Complexity. Another important consideration is on how difficult MoDe4SLA
is to understand. We strive to develop an intuitive approach that is easy to understand
for users. Of course, the positive evaluation results concerning usefulness of MoDe4SLA
after a short training period, supports our claim that MoDe4SLA has good usability. How-
ever, we also want to know whether participants feel the given presentation on MoDe4SLA
is sufficient to use the models. The presentation takes at most one and a half hour, includ-
ing discussion and questions. In Question 42 we ask participants whether they agree or
not with the statement that the provided presentation gives sufficient information to un-
183
CHAPTER 9. EVALUATION OF MODE4SLA: SERVICE COMPOSITIONS
0%
10%
20%
30%
40%
50%
60%
70%
disagree neither
agree nor
disagree
agree strongly
agree
Figure 9.12: The presentation before the evaluation is sufficient to properly understand
MoDe4SLA approach.
derstand the MoDe4SLA approach. Results are depicted in Figure 9.12 where we see
that most participants (over 85%) agree with this statement. We conclude that for most
participants the presentation is sufficient. But there is a considerable group, around 12%,
that appreciates more explanation.
Furthermore, in Question 45 we ask participants to name weak points of the approach.
Here, there are more indications that MoDe4SLA is less intuitive to some of the partici-
pants. 7 of them (i.e., around 20%) indicate they have problems understanding the values
in the model. With these values, participants sometimes mean impact factors, but usually
contribution ratios turn out to be hard to understand. The magnitude of numbers confuses
some of the participants. 2 of them (i.e., around 6%) state that for them the feedback
models are too complex to comprehend. In conclusion we state that over 25% of the
participants have some difficulties understanding the values in the feedback models.
RQ5: Possible improvements. While discussing these last results, we come to possible
improvements for the MoDe4SLA approach. We ask participants to name things they
feel are most beneficial about the feedback models. Participants like the visualization
part, especially with the coloring. Furthermore, impact factors and the analysis itself are
beneficial for the participants.
In addition, we ask for possible improvements of our approach. From the answers
we conclude some suggestions for further development of the approach. The first possi-
ble improvement is a reduction of the many numbers used in the models. As discussed
in RQ4, for some participants there is simply too much information in the models. Fur-
thermore, participants feel they are able to make proper choices with just coloring and
impact factors. In other words, the additional ratios are often not necessary. Therefore,
we consider filtering this information when the models are presented to users.
Secondly, participants appreciate some interpretation guidelines. For example, “what
does a low impact factor indicate?”, “what does a high ratio mean?”, and “what can I
derive from the combination of an impact factor and a ratio?”. Therefore, we consider
184
9.4. CONCLUSIONS FROM EVALUATING USEFULNESS
extending the presentation to participants with information on these statements.
Thirdly, related to the previous improvement, participants appreciate guidelines for
decision making. It is beneficial if the models indicate which services to consider for
change and why. Currently, models only provide monitoring information without any
suggestions on how to improve performance. Developing such guidelines is part of our
future work.
RQ6: Related work. Although we hope to get some more feedback on this question,
unfortunately, we only received related work indications by two participants. The ap-
proaches mentioned are already known to us. So far, this supports our observations that
there do not exist any approaches similar to MoDe4SLA.
9.4.3 Conclusions
Test cases. Although we introduce three different test cases with different complex-
ity levels, it turns out that MoDe4SLA is already perceived as useful when managing a
composition of only five services. Furthermore, our test case of seventeen services is
considered as highly complex by the participants. However, when considering real-life
constellations, seventeen services is not a lot. As a consequence, a proper management
approach is definitely necessary in those cases.
Furthermore, Test Case 2 is often perceived as less complex than Test Case 1 although
it consists of twice as many services. Reason for this is that dependencies in the structure
of Test Case 1 are more complex since it contains three constructs as opposed to Test Case
2 that only contains one construct.
Cost versus response time. When analyzing the different diagrams, it becomes clear
that most participants struggle more with response time dependencies than with cost de-
pendencies. As a result, MoDe4SLA is especially appreciated in the response time mod-
els, which is also supported by answers given to Question 48 where beneficial parts are
named. The reason for this is that response time of a branch depends on the interaction be-
tween the different services. Whether service A contributes, depends not only on whether
it is invoked, and how fast it runs, but also on how fast its neighbor runs. Although the
ratio of contribution for costs is also dependent on the cost of other services, this depen-
dency is much less strong. Therefore, for property response time it is even more important
to identify dependencies than for costs.
Overall conclusion. To support our hypothesis that MoDe4SLA models have a clear
benefit over an approach that only supports bilateral monitoring (cf. Section 9.2), we
investigate usefulness of our approach as perceived by experts using the models. All
three sub-questions concerning accuracy (RQ1), efficiency (RQ2), and confidence (RQ3)
clearly indicate that participants benefit from the MoDe4SLA models. Although there are
some improvements to consider, as discussed in RQ5, participants are able to properly
185
CHAPTER 9. EVALUATION OF MODE4SLA: SERVICE COMPOSITIONS
understand the MoDe4SLA approach within one and a half hour. These results give us
sufficient support to continue developing our management approach.
So far, we only ask participants for their opinion. There are no good or bad answers.
Of course, we want to know whether the answers our participants give are effective as
well. In other words, we want to know whether their decisions are better when making
them with MoDe4SLA than without our approach. This is considered in our effectiveness
evaluation in future research.
9.5 Summary
This chapter presents our evaluation approach consisting of an effectiveness part and a
usefulness part. Actual evaluation of effectiveness constitutes future research. We con-
duct in several interactive sessions an extensive usefulness evaluation where 34 partic-
ipants each answer 49 questions. The obtained results are so far promising since most
participants consider MoDe4SLA as useful for managing composite services (particu-
larly if they compare the approach to traditional bilateral monitoring). We identify some
possible extensions and improvements for our approach that are incorporated in future
research.
186
Part V
DISCUSSION
CHAPTER 10
DISCUSSION & LESSONS LEARNT
In this thesis we present our MaDe4IC method suitable for managing different models de-
scribing inter-organizational cooperations. Firstly, we demonstrate the need for a method
managing dependency relations between inter-organizational models, and we describe
this method in detail. Furthermore, we evaluate our MaDe4IC method by applying it
to two different scenarios. In this chapter we discuss the major research results of this
thesis. We start in Section 10.1 with discussing whether and how requirements identi-
fied in Section 3.4 are fulfilled by our MaDe4IC method (cf. Chapter 4). Furthermore,
we perform a cross-scenario comparison in Section 10.2. We elaborate on characteristics
of the two different scenarios used to evaluate our method. In Section 10.3 we discuss
the application of our method. We first discuss its application to business and coordi-
nation models. Secondly, we show how our method is applied in the context of service
compositions and related Service Level Agreements. In Section 10.4 we reflect on the
validation of the MoDe4SLA approach that is developed from applying our method to
service compositions. After presenting the main results of this thesis, Section 10.5 con-
tinues with discussing the research questions formulated in Chapter 1. We conclude with
a discussion on future research in Section 10.6.
10.1 Method requirements
In Chapter 3 we identify requirements. In detail, we formulate the following require-
ments:
CHAPTER 10. DISCUSSION & LESSONS LEARNT
•R1 The method should be language-independent.
•R2 The method should be able to handle heterogeneous models, i.e., models
described in different languages.
•R3 The method should ensure consistency through checking rather than
through construction.
•R4 The method should provide guidelines for overcoming model heterogene-
ity.
•R5 The method should provide guidelines for identifying overlap between
models.
•R6 The method should provide guidelines for identifying dependencies be-
tween models.
•R7 The method should provide guidelines for defining consistency constraints
for inter-organizational cooperation models.
•R8 The method should provide guidelines to identify the overlap between event
logs and model.
•R9 The method should provide an approach to log information necessary for
consistency checking.
•R10 The method should provide an approach to analyze an event log to abstract
necessary information for consistency checking.
•R11 The method should provide guidelines for defining consistency constraints
between running system and its underlying models.
•R12 The method should provide an approach to show consequences of model
adaptations on consistency relations.
•R13 The method should provide an approach to provide monitoring results as
feedback.
As we discuss in the following, our MaDe4IC method, as defined in Chapter 4, fulfills
these requirements.
It is (R1) language-independent. It does not make any assumptions on the type of
language used to describe models, aside from the assumption that they are applied to
conceptual models. This is also supported by the two scenarios to which we apply our
method (cf. Chapters 5 and 7). These scenarios describe models in several different
modelling languages.
190
10.1. METHOD REQUIREMENTS
The developed method is (R2) suitable for heterogeneous models. On the one hand,
this is supported by providing homogenization guidelines in Step 2 of the method to
enable model comparison of heterogeneous models. On the other hand, this is supported
by providing a language-independent abstraction of related model parts in Step 7 where
we suggest the use of either graphs or sets. Furthermore, the scenarios to which our
method is applied (cf. Chapters 5 and 7) consist of several heterogeneous models. In both
scenarios our method is successfully applied.
Requirement R3 states that the method should rely on consistency checking rather
than on ensuring consistency through construction. The method also complies to this re-
quirement since it assumes the existence of (possibly inconsistent) models from the start.
These models then form the basis for the management approach. Furthermore, in both
scenarios, the models are checked for consistency rather than that they are constructed
maintaining consistency.
In the fourth requirement (R4) we state the necessity for guidelines to overcome model
heterogeneity. In Step 1 of our method (cf. Figure 4.1), each model is analyzed. The result
is a set of model characteristics. These characteristics support handling heterogeneity
between the models in Step 2. The guidelines in Step 2 provide a structured approach
in identifying heterogeneity between the models. Furthermore, it provides guidelines to
either homogenize the models, or to handle the differences between them in subsequent
steps. In addition, at the end of the analysis phase, the combined dependency analysis
(Step 7) overcomes any other heterogeneity problems by representing relevant model parts
in a language-independent formalism.
Both requirements R5 and R6 are ensured in Step 3 of our method. R5 states the
necessity for inter-model overlap detection, while R6 states the necessity to identify inter-
model relations. The overlap is mainly present in viewpoint models, while relations are
identified between viewpoints and between partial models.
Requirement R7 expresses the need for an approach to define consistency constraints
that support checking and ensuring consistency within and between models. Our method
provides guidelines to define inter-model consistency constraints in Step 4.
Requirements R8, R9, and R10 are covered in Step 8 of our method. Here, we first
specify how to log necessary information (R9), after which we provide an approach to
analyze information from event logs to abstract necessary information for consistency
checking (R10). Finally, we describe how these event logs are related to the different
models, and how they are used to perform monitoring (R8).
Requirement R11 states the necessity for guidelines on how to define consistency
constraints between running system and its underlying models. Our method provides
guidelines to define intra-model consistency constraints in Step 6. These constraints state
which information on the behavior of the system should be present in the event logs for
the models to be considered being consistent with the running system.
Furthermore, in R12 we express the necessity for identifying consequences of model
changes with respect to consistency relations. This part is covered by Step 9 of the method
where we do a causal analysis based on the different relations identified within and be-
tween the models.
191
CHAPTER 10. DISCUSSION & LESSONS LEARNT
Finally, R13 states we should provide an approach to show monitoring results to users
in order to manage the models. For this, our method suggests to use the management
models that result from Step 8. These models show all relations, dependencies, and con-
straints between and within the models. In addition, our method suggests coloring and
annotating parts of the models for easy distinction between good and bad performance.
This is applied in both scenarios where the implementation (cf. Chapter 6 and Chapter 8)
offers graphical feedback to its users based on the different dependencies.
We develop the method in this thesis with the identified solution requirements in mind,
and we conclude that the method indeed complies with these requirements. This is sup-
ported by both scenarios to which we successfully apply our MaDe4IC method.
10.2 Cross-scenario discussion
In Part III of this thesis we evaluate our MaDe4IC method by applying it to business
models and coordination models. More specifically, we use e3-value modelling ontology
for business modelling and Petri Nets for coordination modelling. The value models are
used to discuss profitability of a cooperation among involved actors. The coordination
models are used to discuss the order in which message exchanges are accomplished. The
challenge is to relate these two different models, and to manage them both at design time
and at runtime of the cooperation.
In Part IV of this thesis we extend our evaluation by applying our method to mon-
itoring Service Level Agreements (SLAs) for service compositions. Here, we use SLA
models to describe the quality of each service in the composition. More specifically, we
focus on monitoring response time and costs of the services. The challenge is to relate the
different SLAs, taking the service composition into account. Furthermore, we develop an
approach to manage the SLAs at runtime.
Based on this informal summary of the two evaluated scenarios, it becomes clear
that they differ greatly. For us, it is important to choose scenarios that are as diverse as
possible: (1) To show as much of the functionality of our method as possible, and (2) to
show the applicability of our method to a variety of scenarios and cases. The diversity
of the scenarios becomes clear when considering the different characteristics of inter-
organizational models as identified in Chapter 3:
•Our two scenarios depict their models in different languages. This supports our
claim that our method is language-independent.
•In Section 3.1.3 we describe different types of pragmatic heterogeneity that influ-
ence the approach for managing models of a cooperation:
–We identify a difference between perspectives of a model. We distinguish
bird’s eye view and single actor models. The first scenario, using business and
coordination models, describes models from a bird’s eye perspective, while
our second scenario describes models from a single actor perspective.
192
10.3. APPLYING OUR MADE4IC METHOD
–We discuss the difference with respect to the focus models have. We distin-
guish between viewpoint and partial models. Viewpoint models describe the
complete cooperation with a specific focus, while partial models describe only
a part of the cooperation, but do this in full detail. Our first scenario contains
viewpoint models where the business model describes the complete coopera-
tion with a value focus, while the coordination model describes the complete
cooperation with an ordering focus. Our second scenario describes several
partial models; each SLA model describes part of the service composition,
but does this in detail (i.e., for both costs and response time).
–We discuss the distinction between instance-based models, and models de-
scribing a period of time. In the first scenario, for example, the business
model describes a period of time where value is calculated for the upcom-
ing three months, while the coordination model describes an instance-based
model where the order of messages for each model instance is described. In
other words, the coordination model describes for each business transaction
how to execute it. In our second scenario, the SLAs describe a period of time
where averages of costs and response time are modelled. However, the overall
Web service composition describes the cooperation in an instance-based man-
ner where the model shows the interactions for one Web service invocation.
The two scenarios differ in language, perspective, focus, and time frame. We identify
these characteristics in our problem investigation (cf. Chapter 3) as the main character-
istics of inter-organizational models. More specifically, we did not identify any other
characteristic differences in inter-organizational models. Therefore, incorporating these
differences provides the complexity for building a method that is suitable for coping with
a variety of conceptual models. Our MaDe4IC method is built to handle these different
characteristics. By demonstrating the applicability of our method to this variety of as-
pects, we show its applicability to conceptual models of inter-organizational cooperations
in general.
10.3 Applying our MaDe4IC method
We discuss our experiences in applying our MaDe4IC method for managing dependencies
between inter-organizational models to both scenarios. We discuss the application of each
step in our method. We conclude with a summary of the results in Section 10.3.10.
10.3.1 Step 1: Model analysis
In Step 1, model analysis, we determine focus, perspective, time frame, and property type
of the models. For both Scenario 1 (business and coordination models) and Scenario 2
(Service Level Agreements for service compositions) this is a straightforward exercise.
193
CHAPTER 10. DISCUSSION & LESSONS LEARNT
10.3.2 Step 2: Homogenization
In Step 2 we homogenize the models on three different levels, i.e., on syntactic, semantic,
and pragmatic level.
Syntactic homogenization. Business and coordination models are described in differ-
ent languages (i.e., they are syntactically heterogeneous). We identify differences and cor-
respondences between the two modelling languages (i.e., between e3-value and BPMN).
This constitutes a precise, but straightforward exercise. Although the languages are differ-
ent, they both describe conceptual models for inter-organizational cooperations, and use
similar constructs to build the models. This enables matching the language constructs.
The Service Level Agreements considered in the second scenario, are described in the
same language. Therefore, there is no need for homogenization.
Semantic homogenization. Both scenarios are semantically homogeneous by con-
struction.
Pragmatic homogenization. In both scenarios focus, granularity and property type are
the same for the considered models. In business and coordination models the perspective
of the models differs. The identification of this heterogeneity enables easier identification
of inter-model relations in the following steps. In both scenarios there is a heterogeneity in
time frames. In both scenarios we choose to do instance-based comparisons between the
models. In other words, we shorten the time frame for models describing a longer period
of time. As a result, monitoring is done on an instance level which proves very beneficiary.
Especially in the second scenario, instance-based monitoring supports determining the
impact separate services have on the composition (cf. Section 7.5.1).
10.3.3 Step 3: Inter-model relation detection
Inter-model relations are identified between concepts and properties in different models.
These relations describe dependencies that are symmetric or asymmetric.
Scenario 1: Business and coordination models. The inter-model relations in busi-
ness and coordination models are between concepts. The key is to identify concepts in
the models that describe the same real-world entity. Since the models are viewpoints (i.e.,
they focus on a specific characteristic in the cooperation), they describe different charac-
teristics. Therefore, the concepts in the models describe different properties. In general,
we state that viewpoint models do not have inter-model relations on property level. This
makes inter-model relation detection comparably easy for viewpoint models, since prop-
erty dependencies require formulas describing how properties are related. By contrast, for
concept relations the relation simply describes that they are related.
194
10.3. APPLYING OUR MADE4IC METHOD
Scenario 2: Service Level Agreements for service compositions. The inter-model
relations in SLAs are between properties. We do not only determine which concepts
describe the same entities, but also how these entities are related. For example, the mone-
tary value of a product depends on the monetary value of its parts. Since SLAs are partial
models, they describe a set of characteristics. Each characteristic type relates concepts
from different models. In general, we state that partial models typically have many inter-
model property relations. This makes inter-model relation detection comparably complex
for partial models.
10.3.4 Step 4: Inter-model consistency constraints
We formulate consistency constraints for these relations in Step 4 using the detected inter-
model relations in Step 3.
Scenario 1 (Business and coordination models). For each type of inter-model relation
our method provides a matching consistency constraint. Therefore, formulating the inter-
model consistency constraint for business and coordination models is straightforward.
Scenario 2 (Service Level Agreements for service compositions). Although our
method enables matching consistency constraints for each dependency, formulating such
constraints constitutes a more complex task for property dependencies than for concept
dependencies. This complexity is caused by the formulas describing how the properties
are related. For the SLAs, each property type (e.g., costs) shows up in each SLA. All these
properties are inter-related over the different SLAs. For example, the costs of each service
influences the costs of one or more services in the composition. As a consequence, a for-
mula is created for each property type describing the inter-model consistency constraint.
In general, defining inter-model consistency constraints constitutes a more complex
task when considering partial models than when considering viewpoint models. This
increased complexity is caused by the existence of property dependencies between partial
models.
10.3.5 Step 5: Intra-model relation detection
Intra-model relations are identified between concepts and properties within each model.
Identifying intra-model relations is less complex than identifying inter-model relations.
Intra-model relations are already depicted in the considered models as opposed to inter-
model relations that are constructed between the models. The most challenging part of
this task is to determine what type of dependencies exists. Classifying the different de-
pendencies in concept and property dependencies, and in asymmetric and symmetric de-
pendencies constitutes the most challenging task. Identifying these dependencies in our
scenarios was a comparable effort for business models, for coordination models, and for
SLAs.
195
CHAPTER 10. DISCUSSION & LESSONS LEARNT
10.3.6 Step 6: Intra-model consistency constraints
Scenario 1 (Business and coordination models). Viewpoint models (e.g., business
and coordination models) describe the complete cooperation for one characteristic (e.g.,
for costs). As a consequence, each model contains many concepts that refer to differ-
ent real-world entities. Therefore, the concepts in the models are related, and there exist
many dependencies between them. These relations are either property or existence de-
pendencies. Especially many concepts referring to different entities make intra-model
consistency constraint definition complex. In addition, model-specific constraints are de-
veloped independently from the identified intra-model relations.
Scenario 2 (Service Level Agreements for service compositions). Intra-model rela-
tions in partial models (e.g., SLAs) are typically property dependencies. A partial model
describes one part of the cooperation in detail. Therefore, such models often contain a
small set of concepts with many properties. As a consequence, the intra-model relations
are not complex. In addition, model-specific constraints are developed independently
from the identified intra-model relations.
10.3.7 Step 7: Dependency analysis
In Step 7 we use consistency constraints formulated in Steps 4 and 6 to formalize them.
In addition, we formalize those parts of the models that influence these consistency con-
straints. Formalization enables easy implementation for automatic consistency checking.
In both scenarios we abstract necessary information from the models. In the first scenario
we use sets to represent this information, while we use graphs in the second scenario.
Scenario 1 (Business and coordination models). Formalizing models and consistency
constraints, constitutes a straightforward task for business and coordination models. Steps
1 - 6 provide sufficient preparation to identify what should be formalized, and how this
should be done.
Scenario 2 (Service Level Agreements for service compositions). Formalization of
the Service Level Agreements constitutes a more challenging task. We choose to construct
a model for each characteristic. Therefore, we formalized all inter-model dependency re-
lations, and represent them in one dependency model. As opposed to the first scenario,
where we formalize intra-model dependencies and represent those in one model, all inter-
model property dependencies are described by a formula. Each of these formulas is for-
malized in algorithms for automatic derivation of the dependency models. Especially
constructing the algorithms constitutes a challenging task.
10.3.8 Step 8: Log analysis
The log analysis in Step 8 is comparable in the two scenarios. Although the necessary
information is different, the approach to identify and abstract necessary information is
196
10.3. APPLYING OUR MADE4IC METHOD
comparable. In both scenarios it is important to identify which actors are involved in
a transaction, what the identifier of each transaction is, and what property values are
exchanged.
10.3.9 Step 9: Causal analysis
In both scenarios we use the formalized models from Step 7 and the log analysis from
Step 8 to do a causal analysis at runtime. We compare predictions and agreed upon
values in the models with the realized values in the event logs. In both scenarios we use
intra-model as well as inter-model dependencies to reason over the compared values. For
example, we reason over the question why realized values differ from the agreed upon
values. Furthermore, we use the models and dependencies to predict consequences of
adapting parts of the models. In both scenarios the preparations done in Steps 1 - 8 are
sufficient to do a causal analysis for violations as well as for analyzing consequences of
changes.
10.3.10 Lessons learnt
Although the two considered scenarios are different in many respects, when applying our
method the largest influence is caused by a difference in focus. Managing dependencies
in viewpoint models and those in partial models is very different. Main differences ap-
pear in the inter-model relation detection (Step 3), the inter-model consistency constraint
definition (Step 4), and the dependency analysis (Step 7):
Step 3: Inter-model relation detection. Property dependencies are more complex
than concept dependencies since concept dependencies simply state that the existence
of one concept depends on the other. Property dependencies do not only state they are
existence dependent, but also how this dependency looks like. Since inter-model relations
for partial models are typically on a property level (as opposed to viewpoint models),
describing these relations is more difficult than it is for describing them in viewpoint
models.
Step 4: Inter-model consistency constraint definition. In general, defining inter-
model consistency constraints constitutes a more complex task when considering partial
models than when considering viewpoint models. This increased complexity is caused by
the existence of property dependencies between partial models. These dependencies are
translated into complex consistency constraints containing formulas.
Step 7: Dependency analysis. In the dependency analysis of Step 7 we formalize
those parts of the models that influence the consistency constraints. For every charac-
teristic (e.g., response time) we create a separate formal dependency model. Especially
when there are many property dependencies, creating these formal models constitutes a
challenging task.
197
CHAPTER 10. DISCUSSION & LESSONS LEARNT
10.4 Validating MoDe4SLA
In addition to the proof-of-concept implementation we build for both scenarios, we vali-
date usefulness of the results of the second scenario, and explicate the necessity for val-
idating effectiveness of our solution. We decide to validate usefulness by carrying out
an interactive survey. We start each session with a presentation of our approach, give
examples of our management tool in comparison to traditional bilateral monitoring, and
conclude with the actual survey. In this survey we ask our participants to manage different
compositions both with and without using our management tool. We ask them for their
opinion on the approach. The goal of this validation is fourfold:
1. We want to know whether our participants evaluate the approach as useful,
2. We want to know how complex our approach is to understand for users,
3. We want to find additional related work, and
4. We ask suggestions for possible improvements of our approach.
Participants evaluate MoDe4SLA as being very useful when managing service com-
positions, especially its way of identifying dependencies is appreciated. Furthermore, our
approach is well understandable and usable after proper presentation. There are several
suggestions for possible improvements of which some (i.e., interpretation guidelines, de-
cision guidelines, and less numbers in the models) are considered important future work.
From our interactive survey we learn that most participants feel that managing re-
sponse time benefits more from the dependency analysis than management of composi-
tion costs. This difference is explained by the different influence that response time and
costs have on the performance of a branch. Here, it becomes clear that dependencies
between services influence the impact that response time of a service has on the composi-
tion. However, these dependencies do not influence the impact costs of a service have on
the composition.
The number of constructs influences significantly the perceived complexity level for
managing the cooperation. This influence is more significant than the influence the num-
ber of services has. It appears that the composition itself determines to a large extent the
perceived complexity of a composition.
In conclusion, we state that conducting such interactive survey is very useful for get-
ting additional suggestions for further development of the approach. Furthermore, it pro-
vides valuable confirmation that the development of the approach is useful in general. The
results validate the necessity for dependency analysis, and stimulate us to further develop
the approach, especially in the directions identified by our participants. In addition, we
conclude that necessity of identifying dependencies differs between the different proper-
ties to be monitored. For example, the necessity is bigger for response time than for costs.
Therefore, it is interesting to evaluate this also for other properties (e.g., for availability of
a service composition). Although necessity of the approach in general is already clear in
small service compositions (as identified by our participants), we see a growing complex-
ity for the user with the addition of constructs, rather than with the addition of services.
198
10.5. ANSWERING RESEARCH QUESTIONS
It is interesting to further investigate this correlation. Especially since we aim at apply-
ing this approach to complex service compositions. Therefore, it is useful to identify a
measurement to determine when a service composition is considered complex.
10.5 Answering research questions
In previous sections we discuss the different topics treated in this thesis separately. Here,
we discuss the results of the research questions we formulated in Chapter 1.
Research Question 1: What are solution criteria that a method for checking and
ensuring consistency in inter-organizational cooperations should satisfy?
Q1a: What are characteristics of models and running system in the context of inter-
organizational cooperations?
Q1b: What are criteria for a method that checks and ensures consistency in such
models?
We answer the first question by identifying criteria for our method to manage depen-
dencies between inter-organizational models. For this purpose, we position our work in a
conceptual framework in Chapter 2. In addition, the problem investigation in Chapter 3
identifies typical characteristics of models for inter-organizational cooperations. Based on
these characteristics, we define a set of solution requirements for our method (cf. Section
3.4).
Research Question 2: What is state of the art on maintaining consistency relations
in inter-organizational models?
Q2a: How is consistency checked at design time in existing solutions?
Q2b: How is consistency ensured during runtime in existing solutions?
Q2c: How suitable are current solutions with regard to the criteria defined in question
Q1b?
The second research question concerns state-of-the-art research. We are interested in
how consistency is checked and ensured in existing solutions. In Chapter 2 we answer
this question by considering several existing approaches. We determine that majority of
the approaches focus on one or more specific models for which they develop an approach
to maintain consistency. Although such approach is very useful when managing models
in the specified language, it is not usable when managing models expressed in different
languages. The remaining approaches we identified, are suitable for managing models
in general. However, these approaches are too high level for our purpose. Their guide-
lines provide a starting point for the user. However, no detailed information is provided
199
CHAPTER 10. DISCUSSION & LESSONS LEARNT
on how to actually manage the models. Furthermore, many approaches do not go be-
yond ensuring consistency. In other words, they do not provide an approach to manage
consistency at runtime, but merely provide an approach to deal with respective issues at
design time. We conclude from this review that current state-of-the-art research does not
provide an approach that covers the complete set of solution requirements. Therefore,
there are sufficient grounds to develop a new method for managing inter-organizational
cooperations.
Research Question 3: How can a solution method for checking and ensuring inter-
model consistency be built?
Q3a: How can inter-model consistency be ensured?
–How can inter-model dependencies be detected?
–How can consistency constraints be defined using these inter-model de-
pendencies?
Q3b: How can intra-model consistency be ensured?
–What intra-model dependencies exist?
–How can consistency constraints be defined using these dependencies?
Q3c: How can consistency between a running system and its underlying models be
checked?
Q3d: How can consistency between a running system and its underlying models be
efficiently maintained?
The third research question concerns the development of our method itself. We in-
vestigate how the different aspects of checking and ensuring consistency is accomplished
in Chapter 4, which also presents our MaDe4IC method. We distinguish between inter-
model and intra-model consistency relations which we treat separately in our method (cf.
Figure 4.1). Furthermore, we discuss how to check consistency after defining the different
constraints, and how to maintain consistency of models with a running system. Here, we
use a causal analysis to assist this management process (cf. Figure 4.1).
200
10.6. FUTURE RESEARCH
Research Question 4: How can the solution method be validated?
Q4a: How well applicable is the solution method in different scenarios according to
the criteria identified by answering Research Question 1?
Q4b: How good are the developed solutions when applying the method?
–Validate the solution of both scenarios with a proof-of-concept imple-
mentation.
–Validate the implementation of one of the scenarios through a usability
survey.
In our fourth and last research question we discuss possibilities for validating our cre-
ated method. Firstly, we validate our MaDe4IC method in different scenarios. We use our
method for managing business and coordination models in the first scenario (cf. Chapter
5), and we use our method for managing Service Level Agreements for composite services
in the second scenario (cf. Chapter 7). Especially since the two scenarios differ signifi-
cantly (cf. Section 10.2), they provide proper support for the applicability of our method
in inter-organizational models in general. Secondly, we validate the solutions developed
using our method by means of a proof-of-concept implementation. These evaluations are
described in Chapters 6 and 8, respectively. Furthermore, we perform a usability survey
among 34 participants to evaluate usefulness of the implementation for managing service
compositions in Chapter 9.
10.6 Future research
Although this thesis presents a complete method managing models of inter-organizational
cooperations, there are several topics we intend to investigate in future research.
10.6.1 Our MaDe4IC method for managing dependencies
Although our method proves to be applicable to different scenarios, we plan to validate
it in additional scenarios. Furthermore, it is useful to investigate management efforts for
model developers when using our method. Currently, we do not make predictions on the
complexity of the resulting management models when applying our method. However,
the two scenarios indicate there exist many dependencies between numerous entities, and
the effect of these dependencies differs significantly. For example, dependencies between
entities modelling response time are more complex than the ones between entities mod-
elling costs. Furthermore, the scenarios we consider are relatively small with respect to
the number of dependencies and the number of entities. Based on these facts, we formu-
late the following interesting questions:
1. How are complexity of management models and number of dependencies in and
between models related?
201
CHAPTER 10. DISCUSSION & LESSONS LEARNT
2. How well does our method scale up when it is applied to large scenarios?
3. Does the type of entity influence the complexity of dependencies, and, if so, can we
provide a list of typical properties and their complexity factor?
4. Does the type of dependency relation influence complexity of the management
model, and, if so, can we provide a classification?
10.6.2 Our approach for managing SLAs of composite services: MoDe4SLA
The resulting approach for managing Service Level Agreements (i.e., MoDe4SLA) is
considered promising based on the interactive survey we conducted. Users participating
in the survey are enthusiastic about its potential. Therefore, we pursue this research topic
and extend the approach in several directions [18]:
1. We plan to add more intra-model dependencies since currently we focus on inter-
model dependency relations.
2. We plan to extend the approach with additional properties (e.g., availability).
3. We plan to support managing ranges of property values.
4. We plan to support users with guidelines for interpreting feedback models.
5. We plan to pursue the effectiveness evaluation as discussed in Chapter 9.1.
1. Intra-model dependencies. Currently, we assume attributes are mutually indepen-
dent. However, in real-life SLAs dependencies within SLAs are common. Therefore, we
plan to extend our approach with intra-model dependencies. Consider the following SLA:
Every month, response time will be within 3 ms at least 99% of the invo-
cations. Costs are 3 euro when the service responds within 2 ms, while a
response time of 2 −3 ms costs 2 euro. If less than 99% of the invocations
have response time within 3 ms a penalty of 1000 euro is paid.
In this SLA, cost directly depends on response time. The challenge is to represent
what this means for the relative contribution of component service performance on the
composition cost. For example, to diagnose the cause of an increase in composition cost,
we need to show the influence of decreasing response times to the cost (i.e., costs rise to 3
euro). To solve this, we intend to represent dependencies between models by constructing
links between attributes. These links should be annotated with some contribution func-
tion, similar to causal arrows in causal loop diagrams [104]. Our goal is to represent
causal influence between attributes as accurately as necessary for meaningful diagnosis.
For example, in the above example it may be sufficient to represent that a decrease in
response time causes an increase in cost.
202
10.6. FUTURE RESEARCH
2. Additional properties. We plan to extend the approach with additional properties.
For example, we consider extending the approach with availability.
3. Ranges of property values. So far, we ignore property value ranges, but in real life,
SLAs use these ranges. Consider the following examples:
Response time of service A will be 7 −9 ms with an average of 8 ms.
Response time of service B will be 1 −15 ms with an average of 8 ms.
We currently treat these performance requirements as identical since we consider av-
erages. For a proper diagnosis of SLA violations, we need to reason about value ranges.
Therefore, we will incorporate variance in the impact analysis computation, where the
impact of services with high variance is greater than the impact of a stable service. We
need to experiment with various ways of doing this while keeping complexity of depen-
dency and diagnosis computation low.
4. Interpretation guidelines. The results from the interactive survey show that partici-
pants appreciate additional support on how to interpret the feedback models. Even though
the semantics of the edges, nodes, colors, and values is clear, most participants appreciate
guidelines on how to interpret the model as whole. For example, participants struggle to
prioritize colored nodes and edges. An improvement of our MoDe4SLA implementation
is a set of guidelines on how to interpret these models.
5. Effectiveness evaluation. In our effectiveness evaluation we will not only ask users
for their opinion on our approach, but we will test the benefits of managing compositions
with our approach as well (cf. Section 9.1). For example, we want to know whether better
management decisions are made if our models are used.
203
APPENDIX A
EVALUATION
A.1 Transcript
Friday 9 January 2009 the first group of experts evaluated usefulness of MoDe4SLA. It
was a try out with only three experts. The complete session was around one hour and 45
minutes which is divided in a presentation part, an explanation part with two examples,
and the actual evaluation part with three test cases. A transcript of the exact times is
depicted in Table A.1.
Although each participant is employed in an information technology environment, not
everyone is familiar with service compositions. Therefore, the presentation comprises an
explanation of the problem and what the exact research gap is. The first part of the presen-
tation discusses the necessity of identifying dependencies between different services in a
composition, why identifying these dependencies is not straightforward. The second part
of the presentation is on the MoDe4SLA approach in which is explained how we identify
these dependencies and solve the problem. Since the first group already participated in
previous presentations on MoDe4SLA, the time frame of 15 minutes for the presentation
should be considered a minimum.
In the second part is through two examples explained how the survey will be con-
ducted. Both examples have the same structure as the three test cases. The goal of in-
troducing these examples is to allow the participants to get familiar with the MoDe4SLA
approach. First, the representation of the service composition and its parameters (e.g., av-
erage response times) in the bilateral documents for both the estimations and the realized
values is discussed. Second, the analysis done with MoDe4SLA on the realized values of
the composition is discussed. Together with a legend the participants discuss how to use
both the bilateral and the analysis documents.
The last part is done by the participants separately, without interference of the presen-
ter. First the introductional questions are answered after which the participants go through
the three test cases. After the test cases the concluding questions are answered. Interested
participants receive an evaluation of the three test cases on how to read the analysis done
through MoDe4SLA.
APPENDIX A. EVALUATION
Time Subject Minutes
15:09-15:26 Presentation 15
15:27-15:40 Example 113
15:40-15:58 Example 218
16:00-16:04 Before evaluation: Q1-Q7 4
16:04-16:15 Test Case 1: 5 Services 11
•Q8-Q11 without MoDe4SLA: 4min
•Q12-Q18 with MoDe4SLA: 7min
16:15-16:28 Test Case 2: 10 Services 13
•Q19-Q22 without MoDe4SLA: 5min
•Q23-Q29 with MoDe4SLA: 8min
16:28-16:43 Test Case 3: 17 Services 15
•Q30-Q33 without MoDe4SLA: 8min
•Q34-Q40 with MoDe4SLA: 7min
16:43-16:53 After evaluation: Q41-Q47 10
15:09-16:53 Total time 104
Table A.1: Time Transcript
206
A.2. HAND-OUT
A.2 Hand-out
This Appendix contains the complete hand-out for participants of the evaluation. This
starts with a cover sheet and a legend, after which the two examples and three test cases
are given. The hand-out concludes with the survey itself and some suggested answers to
the presented problems.
207
APPENDIX A. EVALUATION
Deviation %
+
-
0
5
-5
10
Estimations:
[x] = chance to be chosen. All chances
within one construct add up to one.
Realized:
[x] = ratio a branch was chosen. All
chances within one construct add up to
one.
Analysis:
IF: x
x
Red: costs/response time were higher than
agreed upon.
Ratio of service contribution
(= branch value)
No color: did not contribute at all.
Type of dependency relation
X: number of times per composition invocation
that the branch contributed to the overall
costs/response time.
X
Its average costs/response time
_
IF=
Red: branch contributed more often than
expected.
208
A.2. HAND-OUT
CS
Loop sequence 1, 3x
XOR 2
WS1 WS2 WS3 WS4
WS5
CS
AND 1
WS1 ORDISC 2
Sequence 3
WS2 WS3 WS4
WS5
WS6 WS10WS9
WS7 WS8
Example 1
Example 2
209
APPENDIX A. EVALUATION
210
A.2. HAND-OUT
211
APPENDIX A. EVALUATION
Impact Model of Costs
composition
AND 1
(Loop)
XOR 2
3.0
WS 5
IF: 0.5278
3.0
WS 1
IF: 0.0612
0.6977
WS 2
IF: 0.2461
1.4186
WS 3
IF: 0.0438
0.3023
WS 4
IF: 0.1211
0.5814
212
A.2. HAND-OUT
Impact Model of Response Time
composition
AND 1
(Loop)
XOR 2
3.0
WS 5
IF: 0.22
3.0
WS 1
IF: 0.3841
0.6977
WS 2
IF: 0.095
1.4186
WS 3
IF: 0.0347
0.3023
WS 4
IF: 0.2228
0.5814
213
APPENDIX A. EVALUATION
214
A.2. HAND-OUT
215
APPENDIX A. EVALUATION
Impact Model of Costs
composition
AND 1
WS 1
IF: 0.0336
1.0
OR 2
1.0
WS 6
IF: 0.2563
1.0
WS 7
IF: 0.098
1.0
WS 8
IF: 0.2486
1.0
WS 9
IF: 0.0454
1.0
WS 10
IF: 0.1273
1.0
AND 3
(Seq)
0.922
WS 5
IF: 0.0134
0.078
WS 2
IF: 0.0059
0.922
WS 3
IF: 0.1255
0.922
WS 4
IF: 0.0459
0.922
216
A.2. HAND-OUT
Impact Model of Response Time
composition
XOR 1
WS 1
IF: 0.3882
0.4255
XOR 2
0.2482
WS 6
IF: 0.0574
0.0567
WS 7
IF: 0.0
0.0
WS 8
IF: 0.0
0.0
WS 9
IF: 0.3265
0.2695
WS 10
IF: 0.0
0.0
AND 3
(Seq)
0.2482
WS 5
IF: 0.0
0.0
WS 2
IF: 0.0626
0.2482
WS 3
IF: 0.1216
0.2482
WS 4
IF: 0.0367
0.2482
217
APPENDIX A. EVALUATION
218
A.2. HAND-OUT
219
APPENDIX A. EVALUATION
Impact Model of Costs
composition
OR 1
OR 2
0.284
WS 5
IF: 0.1115
0.716
WS 1
IF: 0.21
0.2222
AND 3
(Loop)
0.2593
WS 4
IF: 0.0539
0.0864
WS 2
IF: 0.4298
0.8395
WS 3
IF: 0.1948
0.8395
Impact Model of Response Time
composition
XOR 1
XOR 2
0.284
WS 5
IF: 0.3205
0.716
WS 1
IF: 0.0
0.0
AND 3
(Loop)
0.2593
WS 4
IF: 0.0174
0.0247
WS 2
IF: 0.2825
0.8395
WS 3
IF: 0.3681
0.8395
220
A.2. HAND-OUT
221
APPENDIX A. EVALUATION
222
A.2. HAND-OUT
Impact Model of Costs
composition
OR 1
WS 1
IF: 0.0249
0.0962
WS 2
IF: 0.1733
0.3808
WS 3
IF: 0.202
0.7231
WS 4
IF: 0.0545
0.2462
WS 5
IF: 0.0446
0.6192
WS 6
IF: 0.1145
0.7731
WS 7
IF: 0.0396
0.2808
WS 8
IF: 0.0964
0.7346
WS 9
IF: 0.115
0.4192
WS 10
IF: 0.1351
0.7269
223
APPENDIX A. EVALUATION
Impact Model of Response Time
composition
XOR 1
WS 1
IF: 0.0
0.0
WS 2
IF: 0.1032
0.1038
WS 3
IF: 0.0
0.0
WS 4
IF: 0.0
0.0
WS 5
IF: 0.0359
0.0269
WS 6
IF: 0.4255
0.3808
WS 7
IF: 0.027
0.0346
WS 8
IF: 0.2773
0.3038
WS 9
IF: 0.1293
0.1423
WS 10
IF: 0.0018
0.0077
224
A.2. HAND-OUT
225
APPENDIX A. EVALUATION
226
A.2. HAND-OUT
227
APPENDIX A. EVALUATION
228
A.2. HAND-OUT
Impact Model of Costs
composition
AND 1
WS 1
IF: 0.0332
1.0
WS 2
IF: 0.1063
1.0
WS 3
IF: 0.0662
1.0
WS 4
IF: 0.0978
1.0
WS 5
IF: 0.0181
1.0
AND 2
1.0
OR 5
1.0
WS 16
IF: 0.033
1.0
WS 17
IF: 0.023
1.0
WS 6
IF: 0.0517
1.0
WS 7
IF: 0.038
1.0
XOR 3
1.0
WS 13
IF: 0.1763
1.0
WS 8
IF: 0.0504
0.7391
AND 4
(Loop)
0.1304
WS 12
IF: 0.0128
0.1304
WS 9
IF: 0.134
1.0
WS 10
IF: 0.0066
1.0
WS 11
IF: 0.0935
1.0
WS 14
IF: 0.0589
0.9565
WS 15
IF: 0.0
0.0435
229
APPENDIX A. EVALUATION
Impact Model of Response Time
composition
XOR 1
WS 1
IF: 0.0
0.0
WS 2
IF: 0.0
0.0
WS 3
IF: 0.0
0.0
WS 4
IF: 0.0
0.0
WS 5
IF: 0.0
0.0
XOR 2
0.913
XOR 5
0.0
WS 16
IF: 0.0
0.0
WS 17
IF: 0.0348
0.087
WS 6
IF: 0.0791
0.2174
WS 7
IF: 0.0975
0.2174
XOR 3
0.4783
WS 13
IF: 0.0
0.0
WS 8
IF: 0.1648
0.3478
AND 4
(Loop)
0.1304
WS 12
IF: 0.0
0.0
WS 9
IF: 0.1967
1.0
WS 10
IF: 0.1818
1.0
WS 11
IF: 0.229
1.0
WS 14
IF: 0.0
0.0
WS 15
IF: 0.0
0.0
230
A.2. HAND-OUT
231
APPENDIX A. EVALUATION
232
A.2. HAND-OUT
233
APPENDIX A. EVALUATION
234
A.2. HAND-OUT
235
APPENDIX A. EVALUATION
236
A.2. HAND-OUT
237
APPENDIX A. EVALUATION
238
A.2. HAND-OUT
239
APPENDIX A. EVALUATION
A.3 Survey results
240
A.3. SURVEY RESULTS
241
APPENDIX A. EVALUATION
242
A.3. SURVEY RESULTS
243
APPENDIX A. EVALUATION
244
A.3. SURVEY RESULTS
245
APPENDIX A. EVALUATION
246
A.3. SURVEY RESULTS
247
APPENDIX A. EVALUATION
248
A.3. SURVEY RESULTS
249
APPENDIX A. EVALUATION
250
A.3. SURVEY RESULTS
251
APPENDIX A. EVALUATION
252
A.3. SURVEY RESULTS
253
APPENDIX A. EVALUATION
254
A.3. SURVEY RESULTS
255
APPENDIX A. EVALUATION
256
A.3. SURVEY RESULTS
257
APPENDIX A. EVALUATION
258
APPENDIX B
RELATED PUBLICATIONS BY THE AUTHOR
Lianne Bodenstaff, Roel Wieringa, Andreas Wombacher, Manfred Reichert: Towards
Management of Complex Service Compositions - Position Paper -; In Proceedings IEEE
International Workshop on Services Computing for B2B (SC4B2B), co-located with IEEE
SCC, 2009
Lianne Bodenstaff, Andreas Wombacher, Manfred Reichert, Michael C. Jaeger: Analyz-
ing Impact Factors on Composite Services; In Proceedings IEEE International Confer-
ence on Services Computing (SCC), 2009
Lianne Bodenstaff, Andreas Wombacher, Michael C. Jaeger, Manfred Reichert, Roel
Wieringa: Monitoring Service Compositions in MoDe4SLA: Design of Validation; In
Proceedings 11th International Conference on Enterprise Information Systems (ICEIS),
2009
Lianne Bodenstaff, Paolo Ceravolo, Ernesto Damiani, Cristiano Fugazza, Karl Reed, An-
dreas Wombacher: Representing and Validating Digital Business Processes; In Advances
in Web Semantics I, LNCS 4891, Book Chapter, 2008.
Roel Wieringa, Vincent Pijpers, Lianne Bodenstaff, Jaap Gordijn: Value-Driven Coor-
dination Process Design Using Physical Delivery Models; In Proceedings 27th Interna-
tional Conference on Conceptual Modeling (ER), 2008
Lianne Bodenstaff, Andreas Wombacher, Manfred Reichert, Roel Wieringa: An Ap-
proach for Maintaining Models of an E-Commerce Collaboration; In Proceedings IEEE
International Conference on Enterprise Computing, E-Commerce and E-Services (EEE),
2008
Lianne Bodenstaff, Andreas Wombacher, Manfred Reichert, Michael C. Jaeger: Monitor-
ing Dependencies for SLAs: The MoDe4SLA Approach; In Proceedings IEEE Interna-
tional Conference on Services Computing (SCC), 2008
APPENDIX B. RELATED PUBLICATIONS BY THE AUTHOR
Lianne Bodenstaff, Andreas Wombacher, Manfred Reichert: Formal Consistency Results
between Value and Coordination Models; Technical Report, University of Twente, The
Netherlands, 2007
Lianne Bodenstaff, Paolo Ceravolo, Cristiano Fugazza, Andreas Wombacher: Toward
Semantic-aware Representation of Digital Business Processes; In The Second Knowledge
Management in Organization Conference (KMO), 2007
Lianne Bodenstaff, Manfred Reichert, Roel Wieringa: Towards the Integration of Value
and Coordination Models - Position Paper -; In Proceedings Workshops and Doctoral
Consortium of the 19th International Conference on Advanced Information Systems En-
gineering (CAiSE), 2007
Lianne Bodenstaff, Andreas Wombacher, Manfred Reichert, Roel Wieringa: Monitoring
Collaboration from a Value Perspective; In Proceedings IEEE International Conference
on Digital Ecosystems and Technologies (DEST), 2007
Lianne Bodenstaff, Andreas Wombacher, Manfred Reichert: Dynamic Consistency be-
tween Value and Coordination Models - Research Issues; In Proceedings International
Workshop on Modeling Inter-Organizational Systems (MIOS-CIAO’06), 2006
Lianne Bodenstaff, Andreas Wombacher, Manfred Reichert: Dynamic Consistency be-
tween Value and Coordination Models - Research Issues; Technical Report No. TR-
CTIT-06-50, University of Twente, The Netherlands, 2006
260
BIBLIOGRAPHY
[1] Workflow patterns. http://www.workflowpatterns.com.
[2] W.M.P. van der Aalst. Loosely coupled interorganizational workflows: Model-
ing and analyzing workflows crossing organizational boundaries. Information and
Management, 37(2):67–75, 2000.
[3] W.M.P. van der Aalst, B.F. van Dongen, J. Herbst, L. Maruster, G. Schimm, and
A. Weijters. Workflow mining: A survey of issues and approaches. Data &Knowl-
edge Engineering, 47(2):237–267, 2003.
[4] W.M.P. van der Aalst and A.H.M. ter Hofstede. YAWL: Yet Another Workflow
Language. Information Systems, 30(4):245–275, 2005.
[5] M. K. Agarwal, K. Appleby, M. Gupta, G. Kar, A. Neogi, and A. Sailer. Prob-
lem determination using dependency graphs and run-time behavior models. In
Proceedings of the International Workshop on Distributed Systems: Operations &
Management (DSOM), pages 171–182, 2004.
[6] B. Andersson, M. Bergholtz, A. Edirisuriya, T. Ilayperuma, and P. Johannesson.
A declarative foundation of process models. In Proceedings of the International
Conference on Advanced Information Systems Engineering (CAiSE), pages 233–
247, 2005.
[7] B. Andersson, M. Bergholtz, B. Gr´
egoire, P. Johannesson, M. Schmitt, and
J. Zdravkovic. From business to process models - a chaining methodology. In
Proceedings of the International Conference on Advanced Information Systems
Engineering (CAiSE), pages 211–218, 2006.
[8] J.H. Andrews and Y. Zhang. General test result checking with log file analysis.
IEEE Transactions on Software Engineering, pages 634–648, 2003.
[9] D. Ardagna and B. Pernici. Global and local QoS guarantee in Web service se-
lection. In Proceedings of the International Workshop on Business Processes and
Services (BPS). Springer, 2006.
BIBLIOGRAPHY
[10] E. Astesiano and G. Reggio. An attempt at analysing the consistency problems in
the UML from a classical algebraic viewpoint. In Proceedings of the International
Workshop on Algebraic Development Techniques (WADT), pages 56–81. Springer,
2003.
[11] F. Barbon, P. Traverso, M. Pistore, and M. Trainotti. Run-time monitoring of in-
stances and classes of Web service compositions. In Proceedings of the IEEE
International Conference on Web Services (ICWS), pages 63–71, 2006.
[12] L. Baresi, C. Ghezzi, and S. Guinea. Smart monitors for composed services. In
Proceedings of the International Conference on Service Oriented Computing (IC-
SOC), pages 193–202, 2004.
[13] L. Baresi and S. Guinea. Towards dynamic monitoring of WS-BPEL processes.
In Proceedings of the International Conference on Service Oriented Computing
(ICSOC), pages 269–282, 2005.
[14] R. Berbner, M. Spahn, N. Repp, O. Heckmann, and R. Steinmetz. Heuristics for
QoS-aware Web service composition. In Proceedings of the International Confer-
ence on Web Services (ICWS), pages 72–82, 2006.
[15] Y. Bishr. Overcoming the semantic and other barriers to GIS interoperability. In-
ternational Journal of Geographical Information Science and Systems, 12(4):427,
2006.
[16] P. C. Blumenfeld, R. W. Marx, E. Soloway, and J. Krajcik. Learning with peers:
From small group cooperation to collaborative communities. Educational Re-
searcher, 25(8):37–40, 1996.
[17] L. Bodenstaff, M. Reichert, and R. Wieringa. Towards the integration of value
and coordination models - position paper -. In Proceedings of the Workshop on
Business Process Modeling, Development, and Support (BPMDS), pages 291–298,
2007.
[18] L. Bodenstaff, R. Wieringa, A. Wombacher, and M. Reichert. Towards manage-
ment of complex service compositions - position paper -. In Proceedings of the
International Workshop on Services Computing for B2B (SCB2B), 2009.
[19] L. Bodenstaff, A. Wombacher, M. C. Jaeger, M. Reichert, and R. Wieringa. Mon-
itoring service compositions in MoDe4SLA: Design of validation. In Proceedings
of the International Conference on Enterprise Information Systems (ICEIS), 2009.
[20] L. Bodenstaff, A. Wombacher, and M. Reichert. On formal consistency between
value and coordination models. Technical Report TR-CTIT-07-91, University of
Twente.
262
BIBLIOGRAPHY
[21] L. Bodenstaff, A. Wombacher, and M. Reichert. Dynamic consistency between
value and coordination models - research issues. In Proceedings of the Interna-
tional Workshop on Modeling Inter-Organizational Systems (MIOS-CIAO), 2006.
[22] L. Bodenstaff, A. Wombacher, and M. Reichert. Dynamic consistency between
value and coordination models - research issues. Technical Report 06-50, CTIT:
Centre for Telematics and Information Technology, 2006.
[23] L. Bodenstaff, A. Wombacher, M. Reichert, and M. C. Jaeger. Monitoring depen-
dencies for SLAs: The MoDe4SLA approach. In Proceedings of the International
Conference on Services Computing (SCC), pages 21–29, 2008.
[24] L. Bodenstaff, A. Wombacher, M. Reichert, and M. C. Jaeger. Analyzing impact
factors on composite services. In Proceedings of the International Conference on
Services Computing (SCC), 2009.
[25] L. Bodenstaff, A. Wombacher, M. Reichert, and R. Wieringa. Monitoring collab-
oration from a value perspective. In Proceedings of the Conference on Digital
Ecosystems (DEST), pages 134–140, 2007.
[26] L. Bodenstaff, A. Wombacher, M. Reichert, and R. Wieringa. An approach for
maintaining models of an e-commerce collaboration. In Proceedings of the Con-
ference on Enterprise Computing, E-Commerce, and E-Services (EEE), pages 239–
246, 2008.
[27] B. Boehm. Value-based software engineering: Reinventing. SIGSOFT, 28(2),
2003.
[28] B. Boehm and K. J. Sullivan. Software economics: A roadmap. In Proceedings
of the Conference on The Future of Software Engineering, pages 319–343. ACM,
2000.
[29] H. Bowman, E. Boiten, J. Derrick, and M. Steen. Viewpoint consistency in ODP,
a general interpretation. In Proceedings of the International Workshop on Formal
Methods for Open Object-Based Distributed Systems (FMOODS), pages 189–204,
1996.
[30] H. Bowman, M. Steen, E. Boiten, and J. Derrick. A formal framework for view-
point consistency. Formal Methods in System Design, 21(2):111–166, 2002.
[31] L.-O. Burchard, M. Hovestadt, O. Kao, A. Keller, and B. Linnert. The Virtual
Resource Manager: An architecture for SLA-aware resource management. In Pro-
ceedings of the IEEE Interational Symposium on Cluster Computing and the Grid,
pages 126–133, 2004.
[32] G. Canfora, M. Di Penta, R. Esposito, and M.L. Villani. An approach for QoS-
aware service composition based on genetic algorithms. In Proceedings of the
Conference on Genetic and Evolutionary Computation, 2005.
263
BIBLIOGRAPHY
[33] J. Cardoso, A. Sheth, J. Miller, J. Arnold, and K. Kochut. Quality of service for
workflows and Web service processes. Web Semantics: Science, Services and
Agents on the World Wide Web, 1(3):281–308, 2004.
[34] D. Caswell and S. Ramanathan. Using service models for management of internet
services. IEEE Journal on Selected Areas in Communications, 18(5):686–701,
2000.
[35] K. Chang, J. Jackson, and V. Grover. E-commerce and corporate strategy: An
executive perspective. Information &Management, 40(7):663–675, 2003.
[36] T. K. Das and B.-S. Teng. Between trust and control: Developing confidence in
partner cooperation in alliances. The Academy of Management Review, 23(3):491–
512, 1998.
[37] J. Derrick, E. Boiten, H. Bowman, and M. Steen. Supporting ODP – translating
LOTOS to Z. In Proceedings of the International Conference on Formal Methods
for Open Object-based Distributed Systems (FMOODS), pages 399–406, 1996.
[38] Z. Derzsi, J. Gordijn, K. Kok, H. Akkermans, and Y. Tan. Assessing feasibility of
IT-enabled networked value constellations: A case study in the electricity sector.
In Proceedings of the International Conference on Advanced Information Systems
Engineering (CAiSE), volume 4495. Springer, 2007.
[39] P. Dillenbourg, M. Baker, A. Blaye, and C. O’Malley. The evolution of research on
collaborative learning. Learning in Humans and Machine: Towards an interdisci-
plinary learning science, pages 189–211, 1995.
[40] S. Dustdar. Caramba-A process-aware collaboration system supporting ad hoc
and collaborative processes in virtual teams. Distributed and Parallel Databases,
15:45–66, 2004.
[41] S. Easterbrook and M. Chechik. A framework for multi-valued reasoning over in-
consistent viewpoints. In Proceedings of the International Conference on Software
Engineering (ICSE), pages 411–420, 2001.
[42] S. Easterbrook, A. Finkelstein, J. Kramer, and B. Nuseibeh. Co-ordinating dis-
tributed viewpoints: The anatomy of a consistency check. Technical Report 94/7,
1994.
[43] D. Edmond and M. Papazoglou. Reflection is the essence of cooperation. In Co-
operative Information Systems: Current Trends and Directions, pages 233–262.
Academic Press, 1998.
[44] A. Egyed and N. Medvidovic. A formal approach to heterogeneous software mod-
eling. In Proceedings of the International Conference on Fundamental Approaches
to Software Engineering (FASE), pages 178–192. Springer, 2000.
264
BIBLIOGRAPHY
[45] G. Engels, J. Hausmann, R. Heckel, and S. Sauer. Testing the consistency of dy-
namic UML diagrams. In Proceedings of the International Conference on Inte-
grated Design and Process Technology (IDPT), 2002.
[46] G. Engels, R. Heckel, J. M. K¨
uster, and L. Groenewegen. Consistency-preserving
model evolution through transformations. In Proceedings of the International Con-
ference on Model Engineering, Concepts, and Tools, pages 212–226. Springer,
2002.
[47] G. Engels, J.M. K¨
uster, R. Heckel, and L. Groenewegen. A methodology for spec-
ifying and analyzing consistency of object-oriented behavioral models. SIGSOFT,
26(5):186–195, 2001.
[48] B. Esfandiari and V. Tosic. Towards a Web service composition management
framework. In Proceedings of the IEEE International Conference on Web Services
(ICWS), pages 419–426, 2005.
[49] M.S. Feather. Rapid application of lightweight formal methods for consistency
analyses. IEEE Transactions on Software Engineering, 1998.
[50] A. Finkelstein, D. M. Gabbay, A. Hunter, J. Kramer, and B. Nuseibeh. Inconsis-
tency handling in multi-perspective specifications. In Proceedings of the Interna-
tional Conference on European Software Engineering, pages 84–99, 1993.
[51] A. Finkelstein, J. Kramer, B. Nuseibeh, L. Finkelstein, and M. Goedicke. View-
points: A framework for integrating multiple perspectives in system develop-
ment. International Journal of Software Engineering and Knowledge Engineering,
2(1):31–58, 1992.
[52] P. Fradet, D. Le M´
etayer, and M. P´
erin. Consistency checking for multiple view
software architectures. SIGSOFT, 24(6):410–428, 1999.
[53] U. Frank. Conceptual modelling as the core of the information systems discipline
- perspectives and epistemological challenges. In Proceedings of the Americas
Conference on Information Systems (AMCIS), pages 13–15, 1999.
[54] G. Giaglis, R. Paul, and G. Doukidis. Dynamic modelling to assess the business
value of electronic commerce. In Proceedings of the International Electronic Com-
merce Conference, 1998.
[55] F. Giunchiglia, P. Shvaiko, and M. Yatskevich. S-Match: An algorithm and an
implementation of semantic matching. In Proceedings of the European Semantic
Web Symposium (ESWS), pages 61–75. Springer, 2004.
[56] J. Gordijn, H. Akkermans, and H. van Vliet. Business modelling is not pro-
cess modelling. In Proceedings of the Workshop on Conceptual Modeling for
E-Business and the Web (eCOMO), pages 40–51. Springer, 2000.
265
BIBLIOGRAPHY
[57] J. Gordijn and J. M. Akkermans. Value-based requirements engineering: Exploring
innovative e-commerce ideas. Requirements Engineering, 8(2):114–134, 2003.
[58] R. M. Greenwood, D. Balasubramaniam, G. N. C. Kirby, K. Mayes, R. Morrison,
W. Seet, B. Warboys, and E. Zirintsis. Reflection and reification in process system
evolution: Experience and opportunity. In Proceedings of the European Workshop
on Software Process Technology (EWSPT), pages 27–38. Springer, 2001.
[59] D. Grigori, F. Casati, M. Castellanos, U. Dayal, M. Sayal, and M.-C. Shan. Busi-
ness Process Intelligence. Computers in Industry, 53(3):321–343, 2004.
[60] J. B. Heide. Interorganizational governance in marketing channels. The Journal of
Marketing, 58:71–85, 1994.
[61] A. Hunter and B. Nuseibeh. Managing inconsistent specifications: Reasoning,
analysis, and action. ACM Transactions on Software Engineering and Methodol-
ogy, 7(4):335–367, 1998.
[62] M. C. Jaeger and G. Rojec-Goldmann. SENECA - simulation of algorithms for the
selection of Web services for compositions. In Proceedings of the International
Workshop on Technologies for E-Services (TES), pages 84–97, 2005.
[63] M. C. Jaeger, G. Rojec-Goldmann, and G. Muhl. QoS aggregation in Web service
compositions. In Proceedings of the International Conference on e-Technology,
e-Commerce and e-Service (EEE), pages 181–185, 2005.
[64] K. Jensen. Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical
Use. Springer, 1997. Three Volumes.
[65] R. Kazhamiakin, M. Pistore, and M. Roveri. A framework for integrating business
processes and business requirements. In Proceedings of the Enterprise Distributed
Object Computing Conference (EDOC), pages 9–20, 2004.
[66] A. Keller and H. Ludwig. The WSLA framework: Specifying and monitoring
Service Level Agreements for Web services. Journal of Network and Systems
Management, 11(1):57–81, 2003.
[67] S.T. King and P.M. Chen. Backtracking intrusions. ACM Transactions on Com-
puter Systems, 23(1):76, 2005.
[68] S.C. Kleene. Mathematical Logic. Dover Publications, 2002.
[69] J. Koehler, G. Tirenni, and S. Kumaran. From business process model to consistent
implementation: A case for formal verification methods. In Proceedings of the
Conference on Enterprise Distributed Object Computing (EDOC), 2002.
[70] T. B. Lawrence, C. Hardy, and N. Phillips. Institutional effects of interorganiza-
tional collaboration: The emergence of proto-institutions. The Academy of Man-
agement Journal, 45(1):281–290, 2002.
266
BIBLIOGRAPHY
[71] P. Loucopoulos and R. Zicari. Conceptual modeling, Databases, and CASE: An
Integrated View of Information Systems Development. John Wiley & Sons, 1992.
[72] A. Ludwig and B. Franczyk. Managing dynamics of composite Service Level
Agreements with COSMA. In Proceedings of the International Conference on
Fuzzy Systems and Knowledge Discovery, volume 4, 2008.
[73] I.R. Macneil. The New Social Contract: An Inquiry into Modern Contractual
Relations. Yale University Press, New Haven, 1980.
[74] K. Mahbub and G. Spanoudakis. Run-time monitoring of requirements for systems
composed of Web-services: Initial implementation and evaluation experience. In
Proceedings of the IEEE International Conference on Web Services (ICWS), pages
257–265, 2005.
[75] R.S. Matthews, J.L. Cooper, N. Davidson, and P. Hawkes. Building bridges be-
tween cooperative and collaborative learning. Change, pages 34–40, 1995.
[76] W.E. McCarthy. The REA accounting model: a generalized framework for ac-
counting systems in a shared data environment. In Accounting Review, volume 57,
pages 554–578, 1982.
[77] D. A. Menasc´
e. Response-time analysis of composite Web services. IEEE Internet
Computing, 8(1):90–92, 2004.
[78] T. Mens, R. Van Der Straeten, and J. Simmonds. Maintaining consistency between
UML models with description logic tools. In Proceedings of the Workshop on
Consistency Problems in UML-based Software Development, 2003.
[79] T. Mens, R. Van Der Straeten, and J. Simmonds. A framework for managing con-
sistency of evolving UML models. In Software Evolution with UML and XML,
pages 1–31, 2005.
[80] T.M. Mitchell. Generalization as search. Artificial Intelligence, 18(2):203–226,
1982.
[81] O. Moser, F. Rosenberg, and S. Dustdar. Non-intrusive monitoring and service
adaptation for WS-BPEL. In Proceedings of the International Conference on World
Wide Web (WWW), 2008.
[82] D. M¨
uller, M. Reichert, and J. Herbst. Data-driven modeling and coordination of
large process structures. In Proceedings of the IFCIS Conference on Cooperative
Information Systems (CoopIS), pages 131–149. Springer, 2007.
[83] D. M¨
uller, M. Reichert, and J. Herbst. A new paradigm for the enactment and
dynamic adaptation of data-driven process structures. In Proceedings of the In-
ternational Conference on Advanced Information Systems Engineering (CAiSE),
pages 48–63. Springer, 2008.
267
BIBLIOGRAPHY
[84] B. Mutschler, M. Reichert, and J. Bumiller. An approach to quantify the costs of
Business Process Intelligence. In Proceedings of the International Workshop on
Enterprise Modeling and Information Systems Architectures (EMISA), pages 152–
165, 2005.
[85] C. Nentwich, L. Capra, W. Emmerich, and A. Finkelstein. xlinkit: A consistency
checking and smart link generation service. ACM Transactions on Internet Tech-
nology, 2(2):151–185, 2002.
[86] C. Nentwich, W. Emmerich, and A. Finkelstein. Consistency management with
repair actions. In Proceedings of the International Conference on Software Engi-
neering (ICSE), pages 455–464, 2003.
[87] N.F. Noy and M.A. Musen. Anchor-PROMPT: Using non-local context for se-
mantic matching. In Proceedings of the Workshop on Ontologies and Information
Sharing, pages 63–70, 2001.
[88] B. Nuseibeh, S. Easterbrook, and A. Russo. Leveraging inconsistency in software
development. Computer, 33(4):24–29, 2000.
[89] Association of German Automobile Manufacturers (VDA). VDA Recommenda-
tion 4965 T1: Engineering Change Management (ECM) - Part 1: Engineering
Change Request (ECR) Version 1.1, 2005.
[90] OMG. OMG UML specification, 2009.
http://www.omg.org/technology/documents/formal/uml.htm.
[91] M. Oriol, J. Marco, X. Franch, and D. Ameller. Monitoring adaptable SOA-
systems using SALMon. In Proceedings of the Workshop on Service Monitoring,
Adaptation and Beyond, 2008.
[92] A. Osterwalder and Y. Pigneur. An e-business model ontology for modeling e-
business. In Proceedings of the Bled Electronic Commerce Conference, pages 17–
19, 2002.
[93] M. Paolucci, T. Kawamura, T.R. Payne, and K. Sycara. Semantic matching of Web
services capabilities. In Proceedings of the International Semantic Web Conference
(ISWC), pages 333–347. Springer, 2002.
[94] N. Phillips, T. B. Lawrence, and C. Hardy. Inter-organizational collaboration and
the dynamics of institutional fields. Journal of Management Studies, 37(1), 2000.
[95] S. Pokraev. Model-Driven Semantic Integration of Service-Oriented Applications.
PhD thesis, University of Twente, 2009.
[96] P.A. Porras and P.G. Neumann. EMERALD: Event monitoring enabling responses
to anomalous live disturbances. In Proceedings of the National Information Sys-
tems Security Conference, pages 353–365, 1997.
268
BIBLIOGRAPHY
[97] W. W. Powell. Neither market nor hierarchy: Network forms of organization. Re-
search in Organizational Behavior, 12:295–336, 1990.
[98] S.A. Rosenfeld. Does cooperation enhance competitiveness? Assessing the im-
pacts of inter-firm collaboration. Research Policy, 25(2):247 – 263, 1996.
[99] A. Rozinat and W.M.P. van der Aalst. Conformance checking of processes based
on monitoring real behavior. Information Systems, 33(1):64–95, 2008.
[100] A. Sahai, V. Machiraju, M. Sayal, A. P. A. van Moorsel, and F. Casati. Automated
SLA monitoring for Web services. In Proceedings of the International Workshop
on Distributed Systems: Operations &Management (DSOM), pages 28–41, 2002.
[101] M. Sefika, A. Sane, and R.H. Campbell. Monitoring compliance of a software
system with its high-level design models. In International Conference on Software
Engineering (ICSE), volume 18, pages 387–396, 1996.
[102] R. Smith. Aristotle’s logic. Stanford Encyclopedia of Philosophy, 2007.
[103] G. Spanoudakis and A. Zisman. Inconsistency management in software engineer-
ing: Survey and open research issues. In Handbook of Software Engineering and
Knowledge Engineering, volume 1, pages 24–29, 2001.
[104] J.D. Sterman. Business Dynamics: Systems Thinking and Modeling for a Complex
World. McGraw-Hill, 2000.
[105] L. Stoimenov and S. Djordjevi´
c-Kajan. Realization of GIS semantic interoperabil-
ity in local community environment. Proceedings of the AGILE Conference on
Geographic Information Science, pages 73–80, 2003.
[106] K.J. Sullivan, P. Chalasani, S. Jha, and V. Sazawal. Software design as an invest-
ment activity: A real options perspective. Real Options and Business Strategy:
Applications to Decision Making, pages 215–261, 1999.
[107] T.J. Teorey, D. Yang, and J.P. Fry. A logical design methodology for relational
databases using the extended Entity-Relationship model. ACM Computing Surveys,
18(2):197–222, 1986.
[108] P. Timmers. Business models for electronic markets. Electronic Markets, 8:3–8,
1998.
[109] V. Tosic, B. Pagurek, K. Patel, B. Esfandiari, and W. Ma. Management applications
of the Web Service Offerings Language (WSOL). Information Systems, 30(7):564–
586, 2005.
[110] S. Uchitel and M. Chechik. Merging partial behavioural models. SIGSOFT,
29(6):43–52, 2004.
269
BIBLIOGRAPHY
[111] D. Varr´
o and A. Pataricza. VPM: A visual, precise and multilevel metamodeling
framework for describing mathematical domains and UML. Journal of Software
and Systems Modelling, 2(3):187–210, 2003.
[112] Y. Wand and R. Weber. Research commentary: Information systems and concep-
tual modeling - a research agenda. Information Systems Research, 13(4):363–376,
2002.
[113] S.A. White. Business Process Modelling Notation (BPMN).
http://www.bpmn.org/Documents/BPMNVisited: November 2, 2009.
[114] R. Wieringa, V. Pijpers, L. Bodenstaff, and J. Gordijn. Value-driven coordination
process design using physical delivery models. In Proceedings of the International
Conference on Conceptual Modeling (ER), pages 216–231, 2008.
[115] R.J. Willis. Critical path-analysis and resource constrained project scheduling -
theory and practice. European Journal of Operational Research, 21(2):149–155,
1985.
[116] C. Wymbs. How e-commerce is transforming and internationalizing service indus-
tries. Journal of Services Marketing, 14(6):463–477, 2000.
[117] Y.Y. Yao. Granular computing. Computer Science, 31:1–5, 2004.
[118] L. Zeng, B. Benatallah, M. Dumas, J. Kalagnanam, and Q.Z. Sheng. Quality driven
Web services composition. In Proceedings of the International Conference on
World Wide Web, pages 411–421, 2003.
[119] X. Zhao, J. Xie, and J. Leung. The impact of forecasting model selection on the
value of information sharing in a supply chain. European Journal of Operational
Research, 142:321–344, 2002.
[120] Z. Zlatev and A. Wombacher. Consistency between e3-value models and activity
diagrams in a multi-perspective development method. In Proceedings of IFCIS
Conference on Cooperative Information Systems (CoopIS), pages 520–538, 2005.
270
SAMENVATTING
Het gebruik van meerdere modellen waarbij ieder model een specifiek aspect of deel
van het software systeem beschrijft, komt veelvuldig voor in onderzoeksgebieden zoals
software development, information systems development en e-business development. In
dit proefschrift richten wij ons op modelgebaseerde methoden die het beschrijven van
de samenwerking tussen verschillende bedrijven ondersteunen. Deze samenwerkingsver-
banden zijn gewoonlijk complex wat betreft co¨
ordinatie, overeenkomsten en waardecre-
atie voor de betrokken partijen. In de ontwerpfase moet we ervoor zorgen dat de ver-
schillende modellen consistent zijn met elkaar, dat wil zeggen dat ze hetzelfde systeem
beschrijven. In de uitvoeringsfase moeten we er daarnaast rekening mee houden dat het
software systeem zich anders kan gedragen dan oorspronkelijk overeengekomen is. Dit
afwijkende gedrag kan bijvoorbeeld veroorzaakt worden doordat partijen zich niet aan de
overeenkomst houden. Daarom behoren het verzekeren van consistentie in de ontwerp-
fase en het monitoren van het systeem in de uitvoeringsfase zodat inconsistenties met de
modellen gedetecteerd worden, tot de grootste uitdagingen van dit onderzoek.
Tijdens het managen van complexe samenwerkingsverbanden is het daarnaast ook
van belang om de modellen die de samenwerking beschrijven te onderhouden zodat het
succes van de samenwerking in de gaten gehouden kan worden. Het aanpassen van ´
e´
en
model om de consistentie met het lopende systeem te behouden, kan leiden tot nieuwe
inconsistenties tussen de verschillende modellen. De consequentie hiervan is dat de on-
derhoudsfase van de modellen tijdrovend is en groeit in complexiteit wanneer het aantal
modellen toeneemt.
In dit proefschrift wordt een methode beschreven die het verzekeren en onderhouden
van consistentie tussen het lopende systeem en onderliggende modellen voor samenwerk-
ingsverbanden ondersteunt. We presenteren een gestructureerde en modelonafhankelijke
methode voor het checken en onderhouden van consistentie. Daarbij ligt de focus op het
identificeren en onderhouden van relaties tussen de verschillende modellen.
We valideren onze methode door middel van twee case studies in twee verschillende
onderzoeksgebieden. Het eerste scenario gebruikt business- en co¨
ordinatiemodellen, ter-
wijl het tweede scenario over Web service composities gaat. Verder worden beide sce-
nario’s ge¨
ımplementeerd als proof-of-concept evaluatie. We sluiten af met een empirische
BIBLIOGRAPHY
validatie van het Web service compositie scenario door middel van een uitgebreid en in-
teractief onderzoek onder 34 deelnemers. Dit onderzoek bevestigt de geschiktheid van
onze managementoplossing voor praktisch gebruik.
272
SIKS Dissertatiereeks
====
1998
====
1998-1 Johan van den Akker (CWI)
DEGAS - An Active, Temporal Database of Autonomous Objects
1998-2 Floris Wiesman (UM)
Information Retrieval by Graphically Browsing Meta-Information
1998-3 Ans Steuten (TUD)
A Contribution to the Linguistic Analysis of Business Conversations
within the Language/Action Perspective
1998-4 Dennis Breuker (UM)
Memory versus Search in Games
1998-5 E.W.Oskamp (RUL)
Computerondersteuning bij Straftoemeting
====
1999
====
1999-1 Mark Sloof (VU)
Physiology of Quality Change Modelling;
Automated modelling of Quality Change of Agricultural Products
1999-2 Rob Potharst (EUR)
Classification using decision trees and neural nets
1999-3 Don Beal (UM)
The Nature of Minimax Search
1999-4 Jacques Penders (UM)
The practical Art of Moving Physical Objects
1999-5 Aldo de Moor (KUB)
Empowering Communities: A Method for the Legitimate User-Driven
Specification of Network Information Systems
1999-6 Niek J.E. Wijngaards (VU)
Re-design of compositional systems
1999-7 David Spelt (UT)
Verification support for object database design
1999-8 Jacques H.J. Lenting (UM)
Informed Gambling: Conception and Analysis of a Multi-Agent
Mechanism for Discrete Reallocation.
====
2000
====
2000-1 Frank Niessink (VU)
Perspectives on Improving Software Maintenance
2000-2 Koen Holtman (TUE)
Prototyping of CMS Storage Management
2000-3 Carolien M.T. Metselaar (UVA)
Sociaal-organisatorische gevolgen van kennistechnologie;
een procesbenadering en actorperspectief.
2000-4 Geert de Haan (VU)
ETAG, A Formal Model of Competence Knowledge for User Interface Design
2000-5 Ruud van der Pol (UM)
Knowledge-based Query Formulation in Information Retrieval.
2000-6 Rogier van Eijk (UU)
Programming Languages for Agent Communication
2000-7 Niels Peek (UU)
Decision-theoretic Planning of Clinical Patient Management
2000-8 Veerle Coup (EUR)
Sensitivity Analyis of Decision-Theoretic Networks
2000-9 Florian Waas (CWI)
Principles of Probabilistic Query Optimization
2000-10 Niels Nes (CWI)
Image Database Management System Design Considerations,
Algorithms and Architecture
2000-11 Jonas Karlsson (CWI)
Scalable Distributed Data Structures for Database Management
====
2001
====
2001-1 Silja Renooij (UU)
Qualitative Approaches to Quantifying Probabilistic Networks
2001-2 Koen Hindriks (UU)
Agent Programming Languages: Programming with Mental Models
2001-3 Maarten van Someren (UvA)
Learning as problem solving
2001-4 Evgueni Smirnov (UM)
Conjunctive and Disjunctive Version Spaces with
Instance-Based Boundary Sets
2001-5 Jacco van Ossenbruggen (VU)
Processing Structured Hypermedia: A Matter of Style
2001-6 Martijn van Welie (VU)
Task-based User Interface Design
2001-7 Bastiaan Schonhage (VU)
Diva: Architectural Perspectives on Information Visualization
2001-8 Pascal van Eck (VU)
A Compositional Semantic Structure for Multi-Agent Systems Dynamics.
2001-9 Pieter Jan ’t Hoen (RUL)
Towards Distributed Development of Large Object-Oriented Models,
Views of Packages as Classes
2001-10 Maarten Sierhuis (UvA)
Modeling and Simulating Work Practice
BRAHMS: a multiagent modeling and simulation language
for work practice analysis and design
2001-11 Tom M. van Engers (VUA)
Knowledge Management:
The Role of Mental Models in Business Systems Design
====
2002
====
2002-01 Nico Lassing (VU)
Architecture-Level Modifiability Analysis
2002-02 Roelof van Zwol (UT)
Modelling and searching web-based document collections
2002-03 Henk Ernst Blok (UT)
Database Optimization Aspects for Information Retrieval
2002-04 Juan Roberto Castelo Valdueza (UU)
The Discrete Acyclic Digraph Markov Model in Data Mining
2002-05 Radu Serban (VU)
The Private Cyberspace Modeling Electronic Environments
inhabited by Privacy-concerned Agents
2002-06 Laurens Mommers (UL)
Applied legal epistemology;
Building a knowledge-based ontology of the legal domain
2002-07 Peter Boncz (CWI)
Monet: A Next-Generation DBMS Kernel For Query-Intensive Applications
2002-08 Jaap Gordijn (VU)
Value Based Requirements Engineering: Exploring Innovative
E-Commerce Ideas
2002-09 Willem-Jan van den Heuvel(KUB)
Integrating Modern Business Applications with Objectified Legacy Systems
2002-10 Brian Sheppard (UM)
Towards Perfect Play of Scrabble
2002-11 Wouter C.A. Wijngaards (VU)
Agent Based Modelling of Dynamics: Biological and Organisational Applications
2002-12 Albrecht Schmidt (Uva)
Processing XML in Database Systems
2002-13 Hongjing Wu (TUE)
A Reference Architecture for Adaptive Hypermedia Applications
2002-14 Wieke de Vries (UU)
Agent Interaction: Abstract Approaches to Modelling, Programming and
Verifying Multi-Agent Systems
2002-15 Rik Eshuis (UT)
Semantics and Verification of UML Activity Diagrams for Workflow Modelling
2002-16 Pieter van Langen (VU)
The Anatomy of Design: Foundations, Models and Applications
2002-17 Stefan Manegold (UVA)
Understanding, Modeling, and Improving Main-Memory Database Performance
====
2003
====
2003-01 Heiner Stuckenschmidt (VU)
Ontology-Based Information Sharing in Weakly Structured Environments
2003-02 Jan Broersen (VU)
Modal Action Logics for Reasoning About Reactive Systems
2003-03 Martijn Schuemie (TUD)
Human-Computer Interaction and Presence in Virtual Reality Exposure Therapy
2003-04 Milan Petkovic (UT)
Content-Based Video Retrieval Supported by Database Technology
2003-05 Jos Lehmann (UVA)
Causation in Artificial Intelligence and Law - A modelling approach
2003-06 Boris van Schooten (UT)
Development and specification of virtual environments
2003-07 Machiel Jansen (UvA)
Formal Explorations of Knowledge Intensive Tasks
2003-08 Yongping Ran (UM)
Repair Based Scheduling
2003-09 Rens Kortmann (UM)
The resolution of visually guided behaviour
2003-10 Andreas Lincke (UvT)
Electronic Business Negotiation: Some experimental studies on the interaction
between medium, innovation context and culture
2003-11 Simon Keizer (UT)
Reasoning under Uncertainty in Natural Language Dialogue using Bayesian Networks
2003-12 Roeland Ordelman (UT)
Dutch speech recognition in multimedia information retrieval
2003-13 Jeroen Donkers (UM)
Nosce Hostem - Searching with Opponent Models
2003-14 Stijn Hoppenbrouwers (KUN)
Freezing Language: Conceptualisation Processes across ICT-Supported Organisations
2003-15 Mathijs de Weerdt (TUD)
Plan Merging in Multi-Agent Systems
2003-16 Menzo Windhouwer (CWI)
Feature Grammar Systems - Incremental Maintenance of Indexes to
Digital Media Warehouses
2003-17 David Jansen (UT)
Extensions of Statecharts with Probability, Time, and Stochastic Timing
2003-18 Levente Kocsis (UM)
Learning Search Decisions
====
2004
====
2004-01 Virginia Dignum (UU)
A Model for Organizational Interaction: Based on Agents, Founded in Logic
2004-02 Lai Xu (UvT)
Monitoring Multi-party Contracts for E-business
2004-03 Perry Groot (VU)
A Theoretical and Empirical Analysis of Approximation in Symbolic Problem Solving
2004-04 Chris van Aart (UVA)
Organizational Principles for Multi-Agent Architectures
2004-05 Viara Popova (EUR)
Knowledge discovery and monotonicity
2004-06 Bart-Jan Hommes (TUD)
The Evaluation of Business Process Modeling Techniques
2004-07 Elise Boltjes (UM)
Voorbeeldig onderwijs; voorbeeldgestuurd onderwijs, een opstap naar
abstract denken, vooral voor meisjes
2004-08 Joop Verbeek(UM)
Politie en de Nieuwe Internationale Informatiemarkt, Grensregionale
politi¨
ele gegevensuitwisseling en digitale expertise
2004-09 Martin Caminada (VU)
For the Sake of the Argument; explorations into argument-based reasoning
2004-10 Suzanne Kabel (UVA)
Knowledge-rich indexing of learning-objects
2004-11 Michel Klein (VU)
Change Management for Distributed Ontologies
2004-12 The Duy Bui (UT)
Creating emotions and facial expressions for embodied agents
2004-13 Wojciech Jamroga (UT)
Using Multiple Models of Reality: On Agents who Know how to Play
2004-14 Paul Harrenstein (UU)
Logic in Conflict. Logical Explorations in Strategic Equilibrium
2004-15 Arno Knobbe (UU)
Multi-Relational Data Mining
2004-16 Federico Divina (VU)
Hybrid Genetic Relational Search for Inductive Learning
2004-17 Mark Winands (UM)
Informed Search in Complex Games
2004-18 Vania Bessa Machado (UvA)
Supporting the Construction of Qualitative Knowledge Models
2004-19 Thijs Westerveld (UT)
Using generative probabilistic models for multimedia retrieval
2004-20 Madelon Evers (Nyenrode)
Learning from Design: facilitating multidisciplinary design teams
====
2005
====
2005-01 Floor Verdenius (UVA)
Methodological Aspects of Designing Induction-Based Applications
2005-02 Erik van der Werf (UM))
AI techniques for the game of Go
2005-03 Franc Grootjen (RUN)
A Pragmatic Approach to the Conceptualisation of Language
2005-04 Nirvana Meratnia (UT)
Towards Database Support for Moving Object data
2005-05 Gabriel Infante-Lopez (UVA)
Two-Level Probabilistic Grammars for Natural Language Parsing
2005-06 Pieter Spronck (UM)
Adaptive Game AI
2005-07 Flavius Frasincar (TUE)
Hypermedia Presentation Generation for Semantic Web Information Systems
2005-08 Richard Vdovjak (TUE)
A Model-driven Approach for Building Distributed Ontology-based Web Applications
2005-09 Jeen Broekstra (VU)
Storage, Querying and Inferencing for Semantic Web Languages
2005-10 Anders Bouwer (UVA)
Explaining Behaviour: Using Qualitative Simulation in Interactive Learning Environments
2005-11 Elth Ogston (VU)
Agent Based Matchmaking and Clustering - A Decentralized Approach to Search
2005-12 Csaba Boer (EUR)
Distributed Simulation in Industry
2005-13 Fred Hamburg (UL)
Een Computermodel voor het Ondersteunen van Euthanasiebeslissingen
2005-14 Borys Omelayenko (VU)
Web-Service configuration on the Semantic Web; Exploring how semantics meets pragmatics
2005-15 Tibor Bosse (VU)
Analysis of the Dynamics of Cognitive Processes
2005-16 Joris Graaumans (UU)
Usability of XML Query Languages
2005-17 Boris Shishkov (TUD)
Software Specification Based on Re-usable Business Components
2005-18 Danielle Sent (UU)
Test-selection strategies for probabilistic networks
2005-19 Michel van Dartel (UM)
Situated Representation
2005-20 Cristina Coteanu (UL)
Cyber Consumer Law, State of the Art and Perspectives
2005-21 Wijnand Derks (UT)
Improving Concurrency and Recovery in Database Systems by
Exploiting Application Semantics
====
2006
====
2006-01 Samuil Angelov (TUE)
Foundations of B2B Electronic Contracting
2006-02 Cristina Chisalita (VU)
Contextual issues in the design and use of information technology in organizations
2006-03 Noor Christoph (UVA)
The role of metacognitive skills in learning to solve problems
2006-04 Marta Sabou (VU)
Building Web Service Ontologies
2006-05 Cees Pierik (UU)
Validation Techniques for Object-Oriented Proof Outlines
2006-06 Ziv Baida (VU)
Software-aided Service Bundling - Intelligent Methods & Tools
for Graphical Service Modeling
2006-07 Marko Smiljanic (UT)
XML schema matching – balancing efficiency and effectiveness by means of clustering
2006-08 Eelco Herder (UT)
Forward, Back and Home Again - Analyzing User Behavior on the Web
2006-09 Mohamed Wahdan (UM)
Automatic Formulation of the Auditor’s Opinion
2006-10 Ronny Siebes (VU)
Semantic Routing in Peer-to-Peer Systems
2006-11 Joeri van Ruth (UT)
Flattening Queries over Nested Data Types
2006-12 Bert Bongers (VU)
Interactivation - Towards an e-cology of people, our technological environment, and the arts
2006-13 Henk-Jan Lebbink (UU)
Dialogue and Decision Games for Information Exchanging Agents
2006-14 Johan Hoorn (VU)
Software Requirements: Update, Upgrade, Redesign - towards a Theory of Requirements Change
2006-15 Rainer Malik (UU)
CONAN: Text Mining in the Biomedical Domain
2006-16 Carsten Riggelsen (UU)
Approximation Methods for Efficient Learning of Bayesian Networks
2006-17 Stacey Nagata (UU)
User Assistance for Multitasking with Interruptions on a Mobile Device
2006-18 Valentin Zhizhkun (UVA)
Graph transformation for Natural Language Processing
2006-19 Birna van Riemsdijk (UU)
Cognitive Agent Programming: A Semantic Approach
2006-20 Marina Velikova (UvT)
Monotone models for prediction in data mining
2006-21 Bas van Gils (RUN)
Aptness on the Web
2006-22 Paul de Vrieze (RUN)
Fundaments of Adaptive Personalisation
2006-23 Ion Juvina (UU)
Development of Cognitive Model for Navigating on the Web
2006-24 Laura Hollink (VU)
Semantic Annotation for Retrieval of Visual Resources
2006-25 Madalina Drugan (UU)
Conditional log-likelihood MDL and Evolutionary MCMC
2006-26 Vojkan Mihajlovic (UT)
Score Region Algebra: A Flexible Framework for Structured Information Retrieval
2006-27 Stefano Bocconi (CWI)
Vox Populi: generating video documentaries from semantically annotated media repositories
2006-28 Borkur Sigurbjornsson (UVA)
Focused Information Access using XML Element Retrieval
====
2007
====
2007-01 Kees Leune (UvT)
Access Control and Service-Oriented Architectures
2007-02 Wouter Teepe (RUG)
Reconciling Information Exchange and Confidentiality: A Formal Approach
2007-03 Peter Mika (VU)
Social Networks and the Semantic Web
2007-04 Jurriaan van Diggelen (UU)
Achieving Semantic Interoperability in Multi-agent Systems: a dialogue-based approach
2007-05 Bart Schermer (UL)
Software Agents, Surveillance, and the Right to Privacy: a Legislative Framework for Agent-enabled Surveillance
2007-06 Gilad Mishne (UVA)
Applied Text Analytics for Blogs
2007-07 Natasa Jovanovic’ (UT)
To Whom It May Concern - Addressee Identification in Face-to-Face Meetings
2007-08 Mark Hoogendoorn (VU)
Modeling of Change in Multi-Agent Organizations
2007-09 David Mobach (VU)
Agent-Based Mediated Service Negotiation
2007-10 Huib Aldewereld (UU)
Autonomy vs. Conformity: an Institutional Perspective on Norms and Protocols
2007-11 Natalia Stash (TUE)
Incorporating Cognitive/Learning Styles in a General-Purpose Adaptive Hypermedia System
2007-12 Marcel van Gerven (RUN)
Bayesian Networks for Clinical Decision Support: A Rational Approach to Dynamic Decision-Making under Uncertainty
2007-13 Rutger Rienks (UT)
Meetings in Smart Environments; Implications of Progressing Technology
2007-14 Niek Bergboer (UM)
Context-Based Image Analysis
2007-15 Joyca Lacroix (UM)
NIM: a Situated Computational Memory Model
2007-16 Davide Grossi (UU)
Designing Invisible Handcuffs. Formal investigations in Institutions and Organizations for Multi-agent Systems
2007-17 Theodore Charitos (UU)
Reasoning with Dynamic Networks in Practice
2007-18 Bart Orriens (UvT)
On the development an management of adaptive business collaborations
2007-19 David Levy (UM)
Intimate relationships with artificial partners
2007-20 Slinger Jansen (UU)
Customer Configuration Updating in a Software Supply Network
2007-21 Karianne Vermaas (UU)
Fast diffusion and broadening use: A research on residential adoption and usage of broadband internet in the Netherlands between 2001 and 2005
2007-22 Zlatko Zlatev (UT)
Goal-oriented design of value and process models from patterns
2007-23 Peter Barna (TUE)
Specification of Application Logic in Web Information Systems
2007-24 Georgina Ramrez Camps (CWI)
Structural Features in XML Retrieval
2007-25 Joost Schalken (VU)
Empirical Investigations in Software Process Improvement
====
2008
====
2008-01 Katalin Boer-Sorbn (EUR)
Agent-Based Simulation of Financial Markets: A modular,continuous-time approach
2008-02 Alexei Sharpanskykh (VU)
On Computer-Aided Methods for Modeling and Analysis of Organizations
2008-03 Vera Hollink (UVA)
Optimizing hierarchical menus: a usage-based approach
2008-04 Ander de Keijzer (UT)
Management of Uncertain Data - towards unattended integration
2008-05 Bela Mutschler (UT)
Modeling and simulating causal dependencies on process-aware information systems from a cost perspective
2008-06 Arjen Hommersom (RUN)
On the Application of Formal Methods to Clinical Guidelines, an Artificial Intelligence Perspective
2008-07 Peter van Rosmalen (OU)
Supporting the tutor in the design and support of adaptive e-learning
2008-08 Janneke Bolt (UU)
Bayesian Networks: Aspects of Approximate Inference
2008-09 Christof van Nimwegen (UU)
The paradox of the guided user: assistance can be counter-effective
2008-10 Wauter Bosma (UT)
Discourse oriented summarization
2008-11 Vera Kartseva (VU)
Designing Controls for Network Organizations: A Value-Based Approach
2008-12 Jozsef Farkas (RUN)
A Semiotically Oriented Cognitive Model of Knowledge Representation
2008-13 Caterina Carraciolo (UVA)
Topic Driven Access to Scientific Handbooks
2008-14 Arthur van Bunningen (UT)
Context-Aware Querying; Better Answers with Less Effort
2008-15 Martijn van Otterlo (UT)
The Logic of Adaptive Behavior: Knowledge Representation and Algorithms for the Markov Decision Process Framework in First-Order Domains.
2008-16 Henriette van Vugt (VU)
Embodied agents from a user’s perspective
2008-17 Martin Op ’t Land (TUD)
Applying Architecture and Ontology to the Splitting and Allying of Enterprises
2008-18 Guido de Croon (UM)
Adaptive Active Vision
2008-19 Henning Rode (UT)
From Document to Entity Retrieval: Improving Precision and Performance of Focused Text Search
2008-20 Rex Arendsen (UVA)
Geen bericht, goed bericht. Een onderzoek naar de effecten van de introductie van elektronisch berichtenverkeer met de overheid op de administratieve lasten van bedrijven
2008-21 Krisztian Balog (UVA)
People Search in the Enterprise
2008-22 Henk Koning (UU)
Communication of IT-Architecture
2008-23 Stefan Visscher (UU)
Bayesian network models for the management of ventilator-associated pneumonia
2008-24 Zharko Aleksovski (VU)
Using background knowledge in ontology matching
2008-25 Geert Jonker (UU)
Efficient and Equitable Exchange in Air Traffic Management Plan Repair using Spender-signed Currency
2008-26 Marijn Huijbregts (UT)
Segmentation, Diarization and Speech Transcription: Surprise Data Unraveled
2008-27 Hubert Vogten (OU)
Design and Implementation Strategies for IMS Learning Design
2008-28 Ildiko Flesch (RUN)
On the Use of Independence Relations in Bayesian Networks
2008-29 Dennis Reidsma (UT)
Annotations and Subjective Machines - Of Annotators, Embodied Agents, Users, and Other Humans
2008-30 Wouter van Atteveldt (VU)
Semantic Network Analysis: Techniques for Extracting, Representing and Querying Media Content
2008-31 Loes Braun (UM)
Pro-Active Medical Information Retrieval
2008-32 Trung H. Bui (UT)
Toward Affective Dialogue Management using Partially Observable Markov Decision Processes
2008-33 Frank Terpstra (UVA)
Scientific Workflow Design; theoretical and practical issues
2008-34 Jeroen de Knijf (UU)
Studies in Frequent Tree Mining
2008-35 Ben Torben Nielsen (UvT)
Dendritic morphologies: function shapes structure
====
2009
====
2009-01 Rasa Jurgelenaite (RUN)
Symmetric Causal Independence Models
2009-02 Willem Robert van Hage (VU)
Evaluating Ontology-Alignment Techniques
2009-03 Hans Stol (UvT)
A Framework for Evidence-based Policy Making Using IT
2009-04 Josephine Nabukenya (RUN)
Improving the Quality of Organisational Policy Making using Collaboration Engineering
2009-05 Sietse Overbeek (RUN)
Bridging Supply and Demand for Knowledge Intensive Tasks - Based on Knowledge, Cognition, and Quality
2009-06 Muhammad Subianto (UU)
Understanding Classification
2009-07 Ronald Poppe (UT)
Discriminative Vision-Based Recovery and Recognition of Human Motion
2009-08 Volker Nannen (VU)
Evolutionary Agent-Based Policy Analysis in Dynamic Environments
2009-09 Benjamin Kanagwa (RUN)
Design, Discovery and Construction of Service-oriented Systems
2009-10 Jan Wielemaker (UVA)
Logic programming for knowledge-intensive interactive applications
2009-11 Alexander Boer (UVA)
Legal Theory, Sources of Law & the Semantic Web
2009-12 Peter Massuthe (TUE, Humboldt-Universitaet zu Berlin)
Operating Guidelines for Services
2009-13 Steven de Jong (UM)
Fairness in Multi-Agent Systems
2009-14 Maksym Korotkiy (VU)
From ontology-enabled services to service-enabled ontologies (making ontologies work in e-science with ONTO-SOA)
2009-15 Rinke Hoekstra (UVA)
Ontology Representation - Design Patterns and Ontologies that Make Sense
2009-16 Fritz Reul (UvT)
New Architectures in Computer Chess
2009-17 Laurens van der Maaten (UvT)
Feature Extraction from Visual Data
2009-18 Fabian Groffen (CWI)
Armada, An Evolving Database System
2009-19 Valentin Robu (CWI)
Modeling Preferences, Strategic Reasoning and Collaboration in Agent-Mediated Electronic Markets
2009-20 Bob van der Vecht (UU)
Adjustable Autonomy: Controling Influences on Decision Making
2009-21 Stijn Vanderlooy (UM)
Ranking and Reliable Classification
2009-22 Pavel Serdyukov (UT)
Search For Expertise: Going beyond direct evidence
2009-23 Peter Hofgesang (VU)
Modelling Web Usage in a Changing Environment
2009-24 Annerieke Heuvelink (VUA)
Cognitive Models for Training Simulations
2009-25 Alex van Ballegooij (CWI)
”RAM: Array Database Management through Relational Mapping”
2009-26 Fernando Koch (UU)
An Agent-Based Model for the Development of Intelligent Mobile Services
2009-27 Christian Glahn (OU)
Contextual Support of social Engagement and Reflection on the Web
2009-28 Sander Evers (UT)
Sensor Data Management with Probabilistic Models
2009-29 Stanislav Pokraev (UT)
Model-Driven Semantic Integration of Service-Oriented Applications
2009-30 Marcin Zukowski (CWI)
Balancing vectorized query execution with bandwidth-optimized storage
2009-31 Sofiya Katrenko (UVA)
A Closer Look at Learning Relations from Text
2009-32 Rik Farenhorst (VU) and Remco de Boer (VU)
Architectural Knowledge Management: Supporting Architects and Auditors
2009-33 Khiet Truong (UT)
How Does Real Affect Affect Affect Recognition In Speech?
2009-34 Inge van de Weerd (UU)
Advancing in Software Product Management: An Incremental Method Engineering Approach
2009-35 Wouter Koelewijn (UL)
Privacy en Politiegegevens; Over geautomatiseerde normatieve informatie-uitwisseling
2009-36 Marco Kalz (OUN)
Placement Support for Learners in Learning Networks
2009-37 Hendrik Drachsler (OUN)
Navigation Support for Learners in Informal Learning Networks
2009-38 Riina Vuorikari (OU)
Tags and self-organisation: a metadata ecology for learning resources in a multilingual context
2009-39 Christian Stahl (TUE, Humboldt-Universitaet zu Berlin)
Service Substitution – A Behavioral Approach Based on Petri Nets
2009-40 Stephan Raaijmakers (UvT)
Multinomial Language Learning: Investigations into the Geometry of Language
2009-41 Igor Berezhnyy (UvT)
Digital Analysis of Paintings
2009-42 Toine Bogers
Recommender Systems for Social Bookmarking
2009-43 Virginia Nunes Leal Franqueira (UT)
Finding Multi-step Attacks in Computer Networks using Heuristic Search and Mobile Ambients
2009-44 Roberto Santana Tapia (UT)
Assessing Business-IT Alignment in Networked Organizations
2009-45 Jilles Vreeken (UU)
Making Pattern Mining Useful
2009-46 Loredana Afanasiev (UvA)
Querying XML: Benchmarks and Recursion
====
2010
====
2010-01 Matthijs van Leeuwen (UU)
Patterns that Matter
2010-02 Ingo Wassink (UT)
Work flows in Life Science
2010-03 Joost Geurts (CWI)
A Document Engineering Model and Processing Framework for Multimedia documents
2010-04 Olga Kulyk (UT)
Do You Know What I Know? Situational Awareness of Co-located Teams in Multidisplay Environments
2010-05 Claudia Hauff(UT)
Predicting the Effectiveness of Queries and Retrieval Systems
2010-06 Sander Bakkes (UvT)
Rapid Adaptation of Video Game AI
2010-07 Wim Fikkert (UT)
A Gesture interaction at a Distance