Enabling Component-Based Model Transformations with QVT by Li Dan Doctor of Philosophy in Software Engineering 2013 Faculty of Science and Technology University of Macau
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Enabling Component-Based Model Transformations
with QVT
by
Li Dan
Doctor of Philosophy in Software Engineering
2013
Faculty of Science and Technology
University of Macau
Enabling Component-Based Model Transformations
with QVT
by
Li Dan
SUPERVISOR: Prof. Xiaoshan Li
CO-SUPERVISOR: Dr. Zhiming Liu
Department of Computer and Information Science
Doctor of Philosophy in Software Engineering
2013
Faculty of Science and Technology
University of Macau
Author’s right 2013 by
LI Dan
Acknowledgements
Firstly, I would like to express my sincere gratitude to my supervisors, Prof. Xi-
aoshan Li and Dr. Zhiming Liu, for giving me the chance to start my PhD study, and
for their guidance and help over the past four years. Also, I would like to thank Prof.
Gong Zhiguo, Dong Mingchui, Xu Qiwen, and Robert P. Biuk-Aghai of the Univer-
sity of Macau, and Prof. Anders P. Ravn of Aalborg University, Prof. T.H. Tse of the
University of Hong Kong, Prof. Shaoying Liu of Hosei University, for having taken
time and efforts to review my thesis and to serve on the examination committees of my
thesis proposal and oral defense.
Particularly, I am grateful to Dr. Volker Stolz of the University of Oslo, who has
helped me a lot during my PhD study. I would also like to express my thanks to
my colleagues Mr. Liang Zhao, Ruzhen Dong, Xiaoliang Wang, Jiaqi Zhu, Jian Zhu,
Yuanzhang Chang, Danning Li, Ms. Shuling Wang, Lijie Yang, Prof. Mingyi Zhang,
and all the colleagues of UNU-IIST, University of Macau, Institute of Software of
CAS, and Guizhou Academy of Sciences, for their cooperation, discussion and friendly
advice that are of great help in my work. Special thanks to UNU-IIST and general ser-
vices staff Ms. Wendy Hoi, Alice Pun and Kitty Chan for their administrative support
these years.
I am greatly indebted to my family - my parents, my wife and my son, for their
patience, love and endless support in all these years I was away from home.
Chapter2& 3 of this thesis are partly based on the literature [46; 74; 134; 135; 148]
and [38; 39; 82; 97; 112; 181], respectively. I would like to acknowledge and thank all
the authors of these publications.
i
Abstract
Model Driven Architecture(MDA) has become a mainstream framework formodel-
drivenandcomponent-baseddevelopment. To achieve the faster and less costly soft-
ware development promised by MDA, automating the development process with tools
is critical, but not easy. One reason is that MDA lacks a precise and concrete devel-
opment methodology. On the other side, stepwise refinement is a formal mechanism
which facilitates the development of systems correct-by-construction by incrementally
applying the refinement rules. But the limitation of available refinement rules and the
lack of integrated support tools make the method hard to scale up to complex models.
The research presented in this thesis aims at exploring techniques to automate the
MDA development process through application of the refinement mechanism as model
transformations. We use therefinement for Component and Object Systems(rCOS) in
the research, as the formal theory supports component-based modeling, and includes
a comprehensive refinement calculus. We define a UML profile that augments rCOS
with standard UML elements and diagrams, implement a set of the refinement rules as
model transformations, and integrate them into a CASE tool. Thus the full component-
based development process can be driven by interactively applying the refinement
transformations. Particularly, we present a transformation from object-oriented mod-
els to component models, so the OO design and component-based techniques can be
seamlessly combined in the development process.
Automation of these transformations places a high demand on transformation tools.
We adopt the graphical notation ofQVT Relations, an intuitive and powerful language
for defining model transformations. But currently there is no practical support tool
available. We propose an approach to implement QVT transformations as executable
XSLT programs. A tool, named QVTR-XSLT, has been developed to support the ap-
proach. The tool has a graphical editor for specifying a QVT transformation with the
graphical notation, and a code generator which automatically translates the transfor-
mation to XSLT programs. However, the QVTR-XSLT tool marks a useful attempt to
bring the OMG standard language to practice.
ii
Declaration
I declare that this thesis has not been previously submitted for a degree or other
qualification at this or any other higher education institution. To the best of my knowl-
edge and belief, this thesis contains no material previously published or written by
another person, except where due reference or acknowledgement is made.
I also acknowledge that I have read and understood the Rules on Handling Student
Academic Dishonesty and the Regulations of the Student Discipline of the University
of Macau.
iii
Contents
Contents iv
List of Figures x
1 Introduction 1
1.1 General Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Specific Background . . . . . . . . . . . . . . . . . . . . . . . . . .17
1.3 Research Goals and Objectives . . . . . . . . . . . . . . . . . . . . .19
1.4 Research Methodology and Design . . . . . . . . . . . . . . . . . . .21
1.5 Potential Contributions . . . . . . . . . . . . . . . . . . . . . . . . .23
1.6 Organization of the Thesis . . . . . . . . . . . . . . . . . . . . . . .25
1.7 Statement of Originality . . . . . . . . . . . . . . . . . . . . . . . .28
2 Model-Driven Development 30
2.1 Model Driven Architecture (MDA) . . . . . . . . . . . . . . . . . . 31
2.1.1 Models of MDA . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.2 Development process of MDA . . . . . . . . . . . . . . . . .34
2.2 Meta Object Facility (MOF) . . . . . . . . . . . . . . . . . . . . . .35
2.2.1 Essential MOF (EMOF) . . . . . . . . . . . . . . . . . . . .37
2.2.2 XML Metadata Interchange (XMI) . . . . . . . . . . . . . .38
2.3 Unified Modeling Language (UML) . . . . . . . . . . . . . . . . . .39
2.3.1 UML diagrams . . . . . . . . . . . . . . . . . . . . . . . . .40
2.3.2 UML profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.4 Object Constraint Language (OCL) . . . . . . . . . . . . . . . . . .51
2.5 Model Transformations and QVT . . . . . . . . . . . . . . . . . . .53
2.6 Component-Based Development (CBD) . . . . . . . . . . . . . . . .60
2.6.1 Component definition . . . . . . . . . . . . . . . . . . . . .62
iv
CONTENTS
2.6.2 Component composition . . . . . . . . . . . . . . . . . . . .64
2.6.3 Component diagram . . . . . . . . . . . . . . . . . . . . . .65
2.6.4 Component interaction protocol . . . . . . . . . . . . . . . .66
2.6.5 Component-based development process . . . . . . . . . . . .67
3 Refinement for Component and Object Systems – rCOS 69
3.1 UTP - Background of rCOS . . . . . . . . . . . . . . . . . . . . . .70
3.1.1 Programs as designs . . . . . . . . . . . . . . . . . . . . . .72
3.1.2 Refinement of designs . . . . . . . . . . . . . . . . . . . . .73
3.1.3 Reactive designs . . . . . . . . . . . . . . . . . . . . . . . .74
3.2 Object-Orientation of rCOS . . . . . . . . . . . . . . . . . . . . . .75
3.2.1 Syntax of rCOS . . . . . . . . . . . . . . . . . . . . . . . .76
3.2.2 Semantics of rCOS . . . . . . . . . . . . . . . . . . . . . . .79
3.2.3 Object-oriented refinements of rCOS . . . . . . . . . . . . .82
3.3 Component Model of rCOS . . . . . . . . . . . . . . . . . . . . . .85
3.3.1 Close components and refinement . . . . . . . . . . . . . . .86
3.3.2 Open components and composition . . . . . . . . . . . . . .88
3.3.3 Processes and coordination . . . . . . . . . . . . . . . . . . .91
3.4 Development Method of rCOS . . . . . . . . . . . . . . . . . . . . .92
3.4.1 Requirements modeling . . . . . . . . . . . . . . . . . . . .94
3.4.2 Object-oriented design . . . . . . . . . . . . . . . . . . . . .97
3.4.3 Component-based design . . . . . . . . . . . . . . . . . . . .98
3.4.4 Platform specific design and implementation . . . . . . . . .100
3.5 Tool Support for rCOS . . . . . . . . . . . . . . . . . . . . . . . . .101
4 QVTR-XSLT: A Tool for Graphical Notation of QVT Relations 102
4.1 State of the Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
4.1.1 Graph transformation languages and tools . . . . . . . . . . .109
4.1.2 QVT-like languages and tools . . . . . . . . . . . . . . . . .111
v
CONTENTS
4.1.3 Efforts to support graphical notation of QVT Relations . . . .115
4.1.4 XSLT related approaches . . . . . . . . . . . . . . . . . . . .116
4.2 QVT Relations and XSLT . . . . . . . . . . . . . . . . . . . . . . .117
4.2.1 QVT Relations . . . . . . . . . . . . . . . . . . . . . . . . .117
4.2.2 XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
4.2.3 XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
4.2.4 Comparison of QVT Relations and XSLT . . . . . . . . . . .127
4.3 OCL to XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
4.3.1 Mapping OCL types . . . . . . . . . . . . . . . . . . . . . .130
4.3.2 Mapping OCL expressions . . . . . . . . . . . . . . . . . . .131
4.3.3 Mapping OCL operations . . . . . . . . . . . . . . . . . . .134
4.4 QVT Relations to XSLT . . . . . . . . . . . . . . . . . . . . . . . .136
4.4.1 Mapping source domain to selection pattern . . . . . . . . . .137
4.4.2 Creating variable declarations . . . . . . . . . . . . . . . . .139
4.4.3 Generating construction instructions . . . . . . . . . . . . .. 140
4.4.4 Translating relation calls . . . . . . . . . . . . . . . . . . . .141
4.5 Support Semantics of QVT Relations . . . . . . . . . . . . . . . . .142
4.5.1 Transformation direction and check-before-enforce semantics 142
4.5.2 Relation domains . . . . . . . . . . . . . . . . . . . . . . . .143
4.5.3 Rule scheduling . . . . . . . . . . . . . . . . . . . . . . . . .144
4.5.4 Pattern matching . . . . . . . . . . . . . . . . . . . . . . . .146
4.5.5 Object creation using patterns . . . . . . . . . . . . . . . . .147
4.5.6 Transformation traceability . . . . . . . . . . . . . . . . . .148
4.5.7 Transformation composition . . . . . . . . . . . . . . . . . .149
4.5.8 In-place transformation . . . . . . . . . . . . . . . . . . . .151
4.6 Extensions to QVT Relations . . . . . . . . . . . . . . . . . . . . .153
4.6.1 Transformation parameter . . . . . . . . . . . . . . . . . . .153
4.6.2 Relation alias name and priority . . . . . . . . . . . . . . . .155
vi
CONTENTS
4.6.3 Conditional relation call . . . . . . . . . . . . . . . . . . . .157
4.7 Model Query with QVT-R Graphical Notation . . . . . . . . . . . .157
4.7.1 Syntax of the query facility . . . . . . . . . . . . . . . . . .158
4.7.2 Semantics of the query facility . . . . . . . . . . . . . . . . .161
4.7.3 Mapping domain patterns to XPath path expressions . . . .. 162
4.7.4 Generating XSLT functions for queries . . . . . . . . . . . .164
4.8 Tool Design and Implementation . . . . . . . . . . . . . . . . . . . .165
4.8.1 A UML profile for QVT Relations . . . . . . . . . . . . . .165
4.8.2 QVT-R graphical editor . . . . . . . . . . . . . . . . . . . .173
4.8.3 XSLT code generator . . . . . . . . . . . . . . . . . . . . . .176
4.8.4 A collection of predefined transformations . . . . . . . . . .. 177
4.9 Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
4.9.1 Simple UML to simple RDBMS transformation . . . . . . .178
4.9.2 Model querying examples . . . . . . . . . . . . . . . . . . .184
4.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190
5 A UML Profile for rCOS 193
5.1 A Metamodel of rCOS . . . . . . . . . . . . . . . . . . . . . . . . .194
5.1.1 Types and classes of rCOS . . . . . . . . . . . . . . . . . . .194
5.1.2 Components of rCOS . . . . . . . . . . . . . . . . . . . . . .196
5.2 A UML Profile for rCOS . . . . . . . . . . . . . . . . . . . . . . . .198
5.2.1 Mapping rCOS Concepts to UML . . . . . . . . . . . . . . .199
5.2.2 rCOS modeling architecture . . . . . . . . . . . . . . . . . .201
5.2.3 Class and interface modeling . . . . . . . . . . . . . . . . .202
5.2.4 Component modeling . . . . . . . . . . . . . . . . . . . . .204
5.2.5 rCOS sequence diagram . . . . . . . . . . . . . . . . . . . .209
5.2.6 State machine diagram . . . . . . . . . . . . . . . . . . . . .212
5.2.7 Visual diagram modeling . . . . . . . . . . . . . . . . . . .214
vii
CONTENTS
5.2.8 Profile constraints . . . . . . . . . . . . . . . . . . . . . . .216
5.2.9 Profile implementation . . . . . . . . . . . . . . . . . . . . .217
5.3 Supporting rCOS Development . . . . . . . . . . . . . . . . . . . .220
5.3.1 Requirements modeling . . . . . . . . . . . . . . . . . . . .220
5.3.2 Object-oriented design . . . . . . . . . . . . . . . . . . . . .222
5.3.3 Component-based model design . . . . . . . . . . . . . . . .223
5.3.4 Code generation . . . . . . . . . . . . . . . . . . . . . . . .224
5.4 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224
5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227
6 Enabling Model Transformations of rCOS 228
6.1 From Requirements Models to Design Models . . . . . . . . . . . .232
6.1.1 From sequence diagrams to protocol state machines . . . .. 234
6.1.2 Labeling protocol state machines . . . . . . . . . . . . . . .241
6.1.3 Generation of controller classes . . . . . . . . . . . . . . . .243
6.1.4 An example : clinic reception . . . . . . . . . . . . . . . . .246
6.2 From OO Design- to Component-Based Models . . . . . . . . . . .250
6.2.1 Selection of object lifelines . . . . . . . . . . . . . . . . . . .251
6.2.2 Validating the lifeline selection . . . . . . . . . . . . . . . . .253
6.2.3 Generating a component from selected lifelines . . . . . .. . 255
6.2.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . .256
6.3 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .258
6.3.1 Requirements modeling . . . . . . . . . . . . . . . . . . . .258
6.3.2 Object-oriented design . . . . . . . . . . . . . . . . . . . . .262
6.3.3 Component-based design . . . . . . . . . . . . . . . . . . . .267
6.4 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .277
6.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .281
viii
CONTENTS
7 Conclusions and Future Work 283
7.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
7.2 Limitations of Current Study . . . . . . . . . . . . . . . . . . . . . .290
7.3 Perspectives for Future Work . . . . . . . . . . . . . . . . . . . . . .293
References 295
Appendix 311
A EBNF for OCL used in QVTR-XSLT tool 312
A.1 Basic definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312
A.2 Expression definitions . . . . . . . . . . . . . . . . . . . . . . . . . .313
B Algorithms for OO- to component sequence diagram transformation 314
B.1 Calculate strongly connected lifelines . . . . . . . . . . . . . .. . . 314
B.2 Generate component from selected object lifelines . . . . .. . . . . 314
B.3 Generate required interface . . . . . . . . . . . . . . . . . . . . . . .316
Curriculum Vitae 317
ix
List of Figures
1.1 Research methodology (adapted from [127]) . . . . . . . . . . . . . . 22
1.2 Dependency relationships of the major chapters . . . . . . . .. . . . 28
2.1 The four modeling layers of MOF . . . . . . . . . . . . . . . . . . .36
2.2 Extract of the EMOF metamodel . . . . . . . . . . . . . . . . . . . .37
2.3 A use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . .42
2.4 A class diagram for the POS system . . . . . . . . . . . . . . . . . .44
2.5 A state diagram for classSale . . . . . . . . . . . . . . . . . . . . . 45
2.6 A sequence diagram for operationenterItem . . . . . . . . . . . . . . 47
2.7 Model transformation . . . . . . . . . . . . . . . . . . . . . . . . . .54
2.8 QVT Architecture (from [134]) . . . . . . . . . . . . . . . . . . . . . 57
3.1 Basic operations of UTP . . . . . . . . . . . . . . . . . . . . . . . .72
3.2 Syntax of rCOS OO language (RCOSP) . . . . . . . . . . . . . . . . 76
3.3 rCOS development methodology . . . . . . . . . . . . . . . . . . . .93
4.1 Overall process of using QVTR-XSLT tool . . . . . . . . . . . . . .105
4.2 Comparison of transformation approaches and tools . . . . .. . . . . 114
4.3 QVT Relations metamodel . . . . . . . . . . . . . . . . . . . . . . .118
4.4 Example QVT-R relation in graphical notation . . . . . . . . . .. . . 119
4.5 An excerpt of XML data model . . . . . . . . . . . . . . . . . . . . .122
4.6 XSLT metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
4.7 Trace class model . . . . . . . . . . . . . . . . . . . . . . . . . . . .148
4.8 In-place transformation example - relation PullUpAttribute. . . . . . . 152
4.9 Abstract syntax of QVT-R extensions . . . . . . . . . . . . . . . . .153
4.10 Definition of additional transformation parameters. . .. . . . . . . . 154
4.11 Metamodel of the model query . . . . . . . . . . . . . . . . . . . . .159
x
LIST OF FIGURES
4.12 Example of the model query . . . . . . . . . . . . . . . . . . . . . .161
4.13 The UML profile for QVT-R . . . . . . . . . . . . . . . . . . . . . .166
4.14 TheMetaModelpackage of QVT-R profile. . . . . . . . . . . . . . .169
4.15 The stereotype for mapping UML to XMI . . . . . . . . . . . . . . .169
4.16 A stereotype for in-place transformation. . . . . . . . . . . .. . . . . 170
4.17 The toolbar for the QVT-R graphical editor . . . . . . . . . . . .. . 174
4.18 Validating the transformation model . . . . . . . . . . . . . . . .. . 175
4.19 The XSLT code generator . . . . . . . . . . . . . . . . . . . . . . . .176
4.20 Simple UML metamodel . . . . . . . . . . . . . . . . . . . . . . . .180
4.21 Simple RDBMS metamodel . . . . . . . . . . . . . . . . . . . . . .180
4.22 The transformation model . . . . . . . . . . . . . . . . . . . . . . . .180
4.23 The root relation . . . . . . . . . . . . . . . . . . . . . . . . . . . .180
4.24 Class to table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181
4.25 Attribute to column . . . . . . . . . . . . . . . . . . . . . . . . . . .181
4.26 Association to foreign key . . . . . . . . . . . . . . . . . . . . . . .181
4.27 Primitive attribute to column . . . . . . . . . . . . . . . . . . . . . .181
4.28 Complex attribute to column . . . . . . . . . . . . . . . . . . . . . .182
4.29 Attribute in super class to column . . . . . . . . . . . . . . . . . . .182
4.30 Target metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . .185
4.31 Top-level relation . . . . . . . . . . . . . . . . . . . . . . . . . . . .185
4.32 Display query result . . . . . . . . . . . . . . . . . . . . . . . . . . .185
4.33 Count number of classes . . . . . . . . . . . . . . . . . . . . . . . .186
4.34 Classes with number of associations . . . . . . . . . . . . . . . . .. 186
4.35 Maximal depth of inheritance . . . . . . . . . . . . . . . . . . . . . .188
4.36 Number of super classes . . . . . . . . . . . . . . . . . . . . . . . .188
4.37 Find elements by name . . . . . . . . . . . . . . . . . . . . . . . . .189
4.38 Getting attribute names . . . . . . . . . . . . . . . . . . . . . . . . .189
xi
LIST OF FIGURES
5.1 Types package of rCOS metamodel . . . . . . . . . . . . . . . . . . .195
5.2 Class package of rCOS metamodel . . . . . . . . . . . . . . . . . . .195
5.3 Components package of rCOS metamodel . . . . . . . . . . . . . . .197
5.4 Mapping from rCOS concepts to UML . . . . . . . . . . . . . . . . .199
5.5 Overall structure of rCOS model . . . . . . . . . . . . . . . . . . . .201
5.6 ClassandInterfacemodels . . . . . . . . . . . . . . . . . . . . . . .203
5.7 Modeling rCOS component . . . . . . . . . . . . . . . . . . . . . . .205
5.8 Realizing component composition . . . . . . . . . . . . . . . . . . .206
5.9 An example of component composition . . . . . . . . . . . . . . . .208
5.11 rCOS sequence diagram . . . . . . . . . . . . . . . . . . . . . . . .209
5.12 Protocol state machine . . . . . . . . . . . . . . . . . . . . . . . . .212
5.13 Metamodel of diagram interchange (DI) . . . . . . . . . . . . . . .. 215
5.14 Definitions of rCOS profile . . . . . . . . . . . . . . . . . . . . . . .218
5.15 Requirements modeling in the rCOS modeler . . . . . . . . . . . .. 221
5.16 OO design in rCOS modeler . . . . . . . . . . . . . . . . . . . . . .222
5.17 Component-based design in the rCOS modeler . . . . . . . . . . .. . 223
6.1 Starting theSD to PSMtransformation . . . . . . . . . . . . . . . . .235
6.2 Rule formessage occurrence. . . . . . . . . . . . . . . . . . . . . . 236
6.3 Applying rule formessage occurrence. . . . . . . . . . . . . . . . . 236
6.4 Applying rule foralt . . . . . . . . . . . . . . . . . . . . . . . . . . 237
6.5 Applying rule forbreak . . . . . . . . . . . . . . . . . . . . . . . . . 237
6.6 Applying rule forloop . . . . . . . . . . . . . . . . . . . . . . . . . 238
6.7 Applying rule foropt . . . . . . . . . . . . . . . . . . . . . . . . . . 238
6.8 Applying rules forpar andcritical . . . . . . . . . . . . . . . . . . . 240
6.9 Applying rule forref . . . . . . . . . . . . . . . . . . . . . . . . . . 240
6.10 LabeledPSM from Fig.6.7 . . . . . . . . . . . . . . . . . . . . . . . 242
6.11 LabeledPSM from Fig.6.8 . . . . . . . . . . . . . . . . . . . . . . . 242
xii
LIST OF FIGURES
6.12 Use case and component for clinic reception . . . . . . . . . . . . . .246
6.13 Interface and controller class for componentReception . . . . . . . . 246
6.14 System sequence diagram for interfaceReceptDesk. . . . . . . . . . 247
6.15 Protocol state machine for interfaceReceptDesk. . . . . . . . . . . . 248
6.16 A relation to generate a component lifeline . . . . . . . . . . .. . . . 257
6.17 Domain class diagram of CoCoME example . . . . . . . . . . . . . .259
6.18 Use caseProcessSale. . . . . . . . . . . . . . . . . . . . . . . . . . 259
6.19 ComponentProcessSale . . . . . . . . . . . . . . . . . . . . . . . . 259
6.20 Sequence diagram forCInter . . . . . . . . . . . . . . . . . . . . . . 260
6.21 Interface ofProcessSale . . . . . . . . . . . . . . . . . . . . . . . . 260
6.22 Protocol state machine forCInter . . . . . . . . . . . . . . . . . . . . 261
6.23 The controller class for interfaceCInter . . . . . . . . . . . . . . . . 262
6.24 Interactively applying expert pattern . . . . . . . . . . . . . .. . . . 263
6.25 The object sequence diagram after applying expert pattern . . . . . . 264
6.26 The object sequence diagram after OO refinement . . . . . . . .. . . 265
6.27 Design class diagram of CoCoME example . . . . . . . . . . . . . .265
6.28 Select lifelines to become a component . . . . . . . . . . . . . . .. . 268
6.29 Validation error message . . . . . . . . . . . . . . . . . . . . . . . .269
6.30 The sequence diagram after the first transformation . . . .. . . . . . 270
6.31 Component diagram after first transformation . . . . . . . . .. . . . 270
6.32 Definitions of componentCOM_proce . . . . . . . . . . . . . . . . . 271
6.33 Component sequence diagram for componentProcessSale . . . . . . 271
6.34 Component diagram forProcessSale. . . . . . . . . . . . . . . . . . 272
6.36 SD ofCOM_store. . . . . . . . . . . . . . . . . . . . . . . . . . . .273
6.37 PSM ofCOM_store . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
6.38 PSM for the required interface of componentCOM_proce. . . . . . . 273
6.39 Apply component composition . . . . . . . . . . . . . . . . . . . . .274
6.40 Result of component composition . . . . . . . . . . . . . . . . . . .275
xiii
LIST OF FIGURES
6.41 Sequence diagram for componentCOM_pay_SH . . . . . . . . . . . 275
6.42 PSM for componentCOM_pay_SH . . . . . . . . . . . . . . . . . . 276
6.43 Optimized component diagram forProcessSale. . . . . . . . . . . . 277
xiv
Chapter 1
Introduction
Nowadays software systems become more and more intricate and complex. The grow-
ing complexity comes from two fundamental sources. Firstly, some complexity is in-
herent in the difficulty of the underlying application problems, as they have to provide
a large variety of services and features, and become increasingly distributed, dynamic
and mobile. Secondly, the complexity comes from the software technologies used to
solve the problems, as there exists a wide conceptual gap between the application do-
main concepts and the technical solutions that implement the problems as software
systems. Bridging the gap using traditional code-centric approaches gives rise to the
complexity [63]. To cope with this, new software paradigms and technologiesare intro-
duced, such ascomponent-based development, model-driven development, andmodel
transformations.
Component-based development (CBD) [84; 160]. CBD is a reuse-based software
development approach to develop components and compose components into systems.
A component is a reusable block of software for a particular task. It has well-defined
interfaces, and its internals are encapsulated and inaccessible except through the inter-
faces. Components are designed, implemented and verified independently. A complete
system or a new component can be built by composition of the prefabricated compo-
nents. CBD helps to conquer the inherent complexity by dividing a complex sys-
tem into smaller modules that relate to a common function or logical/physical feature,
and encapsulating such a module as a component to hide its complex details. CBD
promises the benefits of reduced production cost, and shorter development time by
reuse of the components developed in other applications or developed by third parties.
1
1. Introduction
Model-driven development (MDD) [78; 147]. MDD is a software development ap-
proach that proposes application of models and model technologies in various devel-
opment activities in a software life cycle, such as the specification, design, and imple-
mentation. A model is an abstraction of a system that captures only certain aspects
of features. MDD aims to reduce complexity and thus improve the software quality
through applying the principles ofraising the level of abstractionandseparation of
concerns. In MDD, an application problem is first modeled at a high level of abstrac-
tion with concepts and structures that are close to the application domains. Thenmodel
transformationsare used to gradually add detailed and platform specific information
to the abstract model, and finally obtain a concrete software implementation.
Model transformation and QVT. Model transformation is an automated process
that takes one or more source models as input and produces one or more target mod-
els as output, following a set of transformation rules [152]. In MDD, model trans-
formation is the main means to support rigorous model refinement, evolution, verifi-
cation and code generation. Many model transformation approaches and tools have
been developed [45; 120]. To address the need for a common transformation lan-
guage, theObject Management Group(OMG) proposed theQuery/View/Transforma-
tion language(QVT) standard [134], which consists of three different transformation
languages. Among them,QVT Relations(QVT-R) is a high-level declarative trans-
formation language that has two concrete syntax styles: textual and graphical. The
graphical notation of QVT-R provides a concise, intuitive and yet powerful way to de-
fine model transformations.
In a MDD development process, there exists multiple models that represent a sys-
tem at different levels of abstraction, as well as from different views, such as static
structure, dynamic behavior, and functionality. These views are closely related, and
sometimes overlapping, in the sense that the same concept may redundantly appear in
2
different views. This brings new complexity, as it is difficult to maintain mutual con-
sistency among the replicated concepts in the views, and ensure the conformance of
models at different levels of abstraction. Additionally, as more models and views are
introduced, more relationships among them are introduced, and management of these
interrelations becomes complicated. Whenever an interrelated part changes, some or
all of its related parts can be affected [78].
Thus, MDD and CBD paradigms pose a set of challenges to software engineering:
1. Theoretical foundations: As a system is modeled from different views at dif-
ferent abstract levels, we need a formal semantic theory to define the precise
relations among the views and the abstract levels, so the consistent analysis and
verification of the models is possible. In order to combine the advantages of both
MDD and CBD techniques, the theory must provide an appropriate framework
to describe objects, components and their compositions, and help us to develop
a coherent and comprehensive understanding of the whole system [112].
2. Development methodologies: Developing complex systems is a difficult task
which cannot be done in one step. Development methodologies provide the
best practice to guide the development process, which consists of a sequence
of phases, activities and steps. A development methodology should support the
identification of crucial aspects of the system at different stages of the devel-
opment, allow us to factor a system into sub-models of different views, and
systematically evolve models across the different abstraction levels.
3. Supporting tools: MDD and CBD are effective only when the theories and
methodologies have been integrated into automated tool support. Particularly,
automating the development process, at least for some key steps or activities,
is crucial for the success of a software project. Carrying out these activities
manually is time consuming, tiresome and error-prone. As model transformation
is the basic means to manipulate models, the development of suitable approaches
3
1. Introduction
and tools for automating the transformations becomes very important.
The research presented in this thesis is aimed to address the last mentioned chal-
lenge, that is, exploring techniques to automate a model-driven development process
of component-based software through the application of model transformations.
1.1 General Background
In this section, we review the mainstream frameworks for MDD and CBD, finding
existing problems that impede the automation of the development process. Then we
go to the relevant techniques of formal methods and identify what can be introduced to
solve the problems. Finally, we inspect the current model transformation approaches
and tools, and conclude the importance of supporting the graphical notation of QVT-R.
Model Driven Architecture
The best known MDD initiative,Model Driven Architecture(MDA) [ 142], is proposed
by theObject Management Group(OMG) as its vision of MDD. MDA provides a set of
standards: 1) to define models and modeling languages (Unified Modeling Language
(UML) [ 135], Meta Object Facility(MOF) [132], Object Constraint Language(OCL)
[131]); 2) to define interoperability of modeling tools (XML Metadata Interchange
(XMI) [ 133]); and 3) to specify model transformations (MOF 2.0 Queries, Views and
Transformations(QVT) [134]).
UML. Among all these standards, UML has been widely accepted as a standardized
visual language to represent models. It provides a certain degree of support for both
MDD and CBD. In order to specify a model from different views, UML defines thir-
teen types of diagrams which are divided into two categories: representing static struc-
ture and dynamic behavior. For example, we normally adoptuse case diagramsfor
requirements elicitation,class diagramsfor structural design,sequence diagramsand
4
1.1. General Background
state diagramsfor modeling system interactions and reactive behaviors. With the help
of component diagrams, composite structure diagrams, and a number of other model-
ing constructs, such asconnector, port, required/provided interface, UML provides a
semi-formal means for specifying components, their composition and deployment. To
enhance the expressiveness of UML, OCL is used to navigate in a model and formulate
constraints on it. In addition, many tools have been developed for UML, with functions
ranging from drawing simple diagrams to supporting reverse software engineering.
Since UML is designed as a general-purpose modeling language which can be
used in many application domains and implementation platforms, OMG only provides
UML with a rather loose semantics defined in natural language. As the consequence,
lots of ambiguities are introduced. The lack of a precise semantics makes it difficult
to automate verification and analysis, which is essential to ensure the correctness and
consistency for separation of concerns and multi-view modeling. Moreover, UML is
claimed to be methodology-independent. That is to say UML is defined as only a
modeling language, OMG does not provide methodological support for using UML
in a development process. In addition, UML involves too many concepts and mecha-
nisms, many of them are overlapping and far from being intuitive in many cases, and
this becomes a drawback rather than an advantage. From a practical point of view, the
loosely defined semantics, numerous modeling concepts, and the lack of a developing
methodology make "pure" UML difficult to apply in practice of MDD and CBD [62].
Development of MDA. The development strategy of MDA focuses on the definition
of two kinds of models:Platform Independent Model(PIM) andPlatform Model(PM).
Here a platform is a particular technology on which an application is implemented,
such asModel-View-Controller(MVC) architecture, CORBA or .NET. PIM considers
only the problems of an application domain, and PM details information of a platform.
In a subsequent step, using model transformations, the two models are combined to
build a Platform Specific Model(PSM) that captures both application concerns and
5
1. Introduction
implementation techniques. Selecting a different PM, the same PIM can be easily
applied on a different platform by generating a specific PSM. OMG estimates that the
PIM-to-PSM transformation is already 50-70% automated in current tools, and the
next development step, generation of the executable code from PSM, is virtually fully
automated already [136].
However, in practice, a model may evolve through different sub-stages inside the
PIM stage. MDA lacks a systematic methodology to develop a complete and consistent
PIM. According to the survey of [43], MDA does not provide a comprehensive and
concrete process that could govern software development activities, thus each project
that uses MDA has to define its own development process or select one from existing
MDA based methodologies.
Methodology support for MDA has been rather slow in coming [18]. Many de-
velopment methodologies proposed in the literature are compatible with MDA and
tightly coupled to UML, such asRational Unified Process(RUP) [100], Agile Software
Process(ASP), etc. In terms of software development process, use case driven itera-
tive development and object-oriented modeling have become a predominant paradigm,
which normally consists of a number of development phases, and each phase is in turn
divided into different development tasks and activities.
For example, RUP defines an incremental development life cycle which is divided
into four phases:inception, elaboration, construction, and transition. Each phase
involves tasks such asbusiness modeling, requirements elicitation, analysis & design,
implementation, testing, deployment, etc. RUP applies use cases as the main method
to capture requirements, and UML activity diagrams, collaboration/sequence diagrams
and class diagrams are used in analysis and design.
RUP is very extensive and heavy weight. Other development methodologies pro-
mote simpler and more flexible development processes with fewer phases and activi-
ties. However, as the purpose of these development methodologies is to provide guid-
ance for the developers to follow in software design, the development activities and
6
1.1. General Background
steps are in general not concrete and fine-grained enough, and no precise semantics is
defined for them. This brings difficulty to the automation of the development process.
From OO design to component-based models.As a natural step of model driven
development, object-oriented models are often further evolved to component-based
models to get the benefits of reusability, maintenance, as well as distributed and inde-
pendent deployment. As nearly all existing component-based technologies are realized
in object-oriented technologies, most design processes start with an OO development
process and then at the end of the process an OO design is directly implemented using
a component-based technology, such .COM or .NET.
Surveys of approaches and techniques for identification reusable components from
object-oriented models can be found in [25; 167]. Based on the principle of “high
cohesion and low coupling”, researchers try to cluster classes into components. The
basic ideas are: calculate the strength of semantic dependencies between classes and
represent them as a weighted directional graph, then cluster the graph using graph
clustering or matrix analysis techniques [167]. Using clustering analysis, components
with high cohesion and low coupling are expected to be obtained in order to reduce
composition cost.
Identifying reusable components from object-oriented models is considered to be
one of the most difficult tasks in the software development process [59]. Most existing
approaches just provide general guidelines for component identification. They lack
more precise criteria and methods [44]. Because of the complexity of source infor-
mation and the component model itself, it is not advisable for component designers to
manually develop component-based models from object-oriented models [167]. Alas,
there are almost no (semi)-automatic tools to help designers in the process [153].
In summary, to support model-driven development process of component-based
software in the framework of MDA, our approach should take advantage of the stan-
7
1. Introduction
dard graphical modeling notation of UML and its existing support tools, and follow the
use case driven development paradigm of RUP style. However, we have to complement
it with a precise semantics and a meticulous development methodology, while restrict-
ing the UML modeling elements that will be used. In addition, we need strong support
for component modeling, and enabling the evolution from OO models to component-
based models. In the follows, we will review the relevant techniques of formal meth-
ods, seeking solutions to meet these requirements.
Formal methods and stepwise refinement
Formal methods are the application of mathematical theories, techniques and tools to
model and verify software/hardware systems. In software engineering, formal methods
can be used to build a rigorous specification of a system. The specification can be
verified with respect to functionality, consistency, safety and certain other properties
through applying semi-automated or automated techniques like theorem proving and
model-checking. Finding and fixing flaws in earlier development phases is known
to significantly reduce the overall cost of software projects. Formal methods can be
also used in system design, architecture, testing, etc. The use of formal methods,
with their rigorous mathematical foundations for system specification, verification and
refinement, offer help to address the challenges faced by MDD and CBD.
Over the past decades, a rich body of formal theories and supporting tools have
been developed. We mention some of the state-based formal methods:Z [27], VDM
[92], ASM [26], B [6] andEvent-B[7], and process-based formal methods:CSP[85],
Petri Nets[144], SOFL [109], etc. Successful application of formal methods can be
seen in safety-critical systems such as for transportation, defence and medical appli-
cations [22; 175]. However, in spite of these successes and the theoretical potential,
formal methods have not seen widespread adoption as a routine part of systems devel-
opment practice [175]. Some of the reasons could be:
8
1.1. General Background
• Formal methods and tools are difficult to understand and use because they re-
quire deep mathematical background and adopt complex formal notations;
• The use of formal methods increases the burden on the system developers, even
though they can benefit from the improved system quality;
• A wider acceptance of formal methods is also hindered by their scalability, as
real systems are much more complex than the examples used in textbooks.
Combining formal methods with UML. Integrating formal methods into UML
opens up a powerful approach to support MDD and CBD. A formal method can sup-
ply UML with a precise semantics, and formal consistency verification and refinement
techniques. For the formal method’s side, the advantage of combining with UML is the
possibility to specify a system with a unified, standardized graphical notation, and to
exploit many available UML tools for saving development effort and time. Thus some
inherent shortcomings of formal methods, such as the complexity of the notations, the
mathematical background required for comprehending the formulations, and the lack
of easy-to-use tools, can be efficiently overcome. The formal methods could therefore
potentially reach a wider user-base.
The work of integrating formal methods into UML for supporting MDD has been
investigated for the past few years. Möller et al. [123] have integrated a formal method,
namelyCSP-OZ, into UML and Java. In their work, UML diagrams are first trans-
lated to CSP-OZ specifications, and then converted intoJML specifications, so the
hand-written Java programs can be checked against the assertions inJML to guarantee
the correct implementation of the formal specifications. In [13], a framework called
UML+Z was introduced for building, analyzing and refining models based on UML
and Z. A UML+Z model consists of class, state and object diagrams. The translation
of UML class diagram and sequence diagram intoVDM++ was discussed in [66]. A
sequence diagram is transformed to traces of VDM++ for the derivation of test cases.
9
1. Introduction
The UML-B [154] provides a framework to support modeling with UML class dia-
grams and state machine diagrams. Translation from UML-B into Event-B enables the
Rodin[8] proof obligation generator and provers to be utilized.
Verification and refinement. The vast majority of existing formal approaches, whether
automated or interactive, symbolic or computational, are designed forpost-hocveri-
fication of complete models [156]. It means that the developers have to first build a
complete model, either manually or with the help of some tools, and in the next step,
check or analyze the model using techniques like model checking and theorem proving.
Developers get little assistance in constructing a model, which makes formal modeling
more laborious and therefore increases the burden on the developers [89]. However, a
practical formal method, like in other engineering disciplines, should consider "calcu-
lating a correct design" more than just "proof of correctness" [139].
To improve the situation, the notion ofrefinementcould be helpful.Refinement
[20; 125] is one of the cornerstones in formal methods. The precise definition of re-
finement depends on the chosen modeling framework and hence might have different
semantics and degree of rigor. Informally, refinement describes an intended relation
between models at different levels of abstraction: a refined model retains all the es-
sential properties of its abstract counterpart, such as providing at least the same func-
tionalities as the abstract model. From the perspective of the system development,
refinement is a process in which new details are introduced into an existing model, or
the model is altered to become more concrete (closer to implementation), while the
refinement relation is preserved. Refinement is another useful mechanism for tackling
complexity by allowing to derive a consistent implementation from the specification.
Refinement styles. Techniques proposed for achieving provable refinement can be
roughly classified into two styles: "posit-and-prove" and "transformational" [104].
The posit-and-proverefinement is still a kind ofpost-hocverification, in which the
10
1.1. General Background
user firstpositsa refined model, and then the model is formally justified against its
abstract version using theorem provers or model checkers. This is typically achieved
by discharging a set of so-calledproof obligations, which are generated from both the
positedmodel and the abstract model. The proof of the refinement usually requires
considerable mathematical knowledge and could be tedious. In addition, the user must
prepare thepositedmodel manually or using other tools in advance.
On the other hand, a refinement oftransformationalstyle, also calledrule-based,
proceeds by applying a set of pre-defined and verified rules on the origin model to
transform it to a refined model. The soundness of the rules ensures the correctness of a
refinement. The refinement rules can be implemented ascorrectness preserving model
transformations. Thus, this approach can automatically generate the refined models,
keep the burden of proof minimal, and therefore helps the developers considerably
in the system development process. Its practicality is limited by the set of available
refinement rules and how well the supporting tools are integrated in the development
environment.
Stepwise refinement. The stepwise refinement method[125; 174] is an important
and well-established formal technique. It is well compatible with the development
process of MDA. Development starts from a specification at a high level of abstraction,
which is gradually transformed into a specification closer to the implementation by
performing a succession of refinement steps. In each step, some design decisions are
explicitly made, such as adding more details, changing data types or control structures,
or decomposing parts of the specification into more concrete expressions. Correctness
of the resulting specification is ensured by correctness of the refinement steps, or can
be verified by mathematical proofs.
The idea of using stepwise refinement for program construction originated in the
work of [52; 174], and then was further developed by C. Morgan [124]. One of the
classic formalizations of stepwise refinement is therefinement calculusof R. Back
11
1. Introduction
[20], which is a framework for reasoning about correctness and refinement by follow-
ing a succession of refinement rules. The calculus was first designed for traditional
imperative programs, and then it was extended to include object-oriented programs
[35]. In addition, refinement calculi have been studied in other formal notations such
as Z, B, and VDM, and in different contexts. In particular, a refinement calculus has
been defined for Eiffel contracts and encoded in PVS [138]. However, these meth-
ods use theposit-and-provestyle of refinement. A developer has to write down a new
model and then verify if it is a refinement of its predecessor.
A typical example isEvent-B[7], a successor of the B language. It is a textual lan-
guage based on set-theory and first-order logic. Object-oriented and component-based
designs are not supported. Event-B emphasizes system development through stepwise
refinement. A refinement step is checked for correctness by discharging proof obli-
gations with the help of theorem provers, and the proof obligations are automatically
generated by the Event-B toolRodin. Using the tool, a user can manually construct an
Event-B model in a stepwise way, and fixes the errors by making use of the feedback
from the tool, e.g., the unproved proof obligations. Moreover, applying refinement in
the transformational style for Event-B was explored in the work of [89]. It proposes
amechanism for automation of formal refinement based on reusable refinement steps,
calledrefinement patterns.
Refinement of UML models. MDA-based models are extremely complicated, as
they are usually specified with multi-view graphical notations from different aspects
and involve object-oriented designs and component-based architectures. It is difficult
and tedious to carry out the refinement process with generic UML tools while keeping
the consistency of various parts of a model. Some work has been done to support the
refinement of UML-based models. The UML-B project [145; 154] provides a UML-
like graphical front end for Event-B. UML-B introduces a number of refinement rules
which are used to add model elements to the class diagrams and state machines, such
12
1.1. General Background
as adding new attributes, new classes, new nested state machines, etc. The authors in
[141] try to recognize a set of refinement rules found in Object-Z, and then apply them
to refine UML class diagrams annotated with OCL expressions.
However, the scientific success of refinement seems in contrast with its acceptance
in industrial practice [87]. Obviously, most refinement techniques are somehow hard
to scale up to MDA-based modeling [175], as it is currently difficult to use with UML
notations as well as component-based systems. In addition, there is a lack of method-
ological studies related to the incremental development of complex systems across the
full development process using refinement mechanisms [15].
To summarize, integration with formal methods supplies UML with the precise
semantics necessary to support MDD and CBD, and the stepwise refinement mecha-
nism provides a solid foundation for automation of the development process. These
ideas form the basis of our approach. Implementation of the refinement rules as model
transformations is therefore the key to our work, and dictates a high demand for trans-
formation approaches and tools.
Model transformation approaches and tools
Graph transformations. Model transformation is the core of MDD. A lot of effort
has already been spent on developing different approaches for model transformations
[45; 120]. Many of them are based on graph transformations and adopt graphical
notations. We mentionAttributed Graph Grammars(AGG) [34], Fujaba[33], GReAT
[10], and these based on theTriple Graph Grammars(TGG) [149], such asMOFLON
[14] and ATM3 [51]. Graph transformation languages are mainly built on the theory
of graph rewriting over extensions or variations of typed-attributed labeled graphs. A
transformation is defined by an attributed type graph and a set of transformation rules,
where each rule consists of two or three graphs.
13
1. Introduction
Graph transformation approaches enjoy a solid formal foundation which allows au-
tomatically analysis and verification of the transformations. Furthermore, the graphical
notation can be visually attractive since it is easier and faster for the designers to un-
derstand the visual representation of a model’s structure and the relationships among
its parts, especially in design transformations that are based on UML-like graphical
metamodels. But graphical notation also has its own drawback of being quite verbose,
and the expressive power of graph transformation rules is often weak. In order to ex-
press a non-trivial transformation rule, the whole diagram is filled with lines, symbols
and labels of different colors, making it hard to read and understand. To improve the
expressive power, a need for integration of graph transformation and OCL has been
discussed in [77; 98; 99]. However, these works are still not mature enough to be used
in practical applications.
ATL. Probably the most mature and widely used transformation language is theAtlas
Transformation Language(ATL) [ 93]. ATL is mainly a declarative language, though
some imperative constructs are allowed to ease the coding of complex transformations.
An ATL transformation program is composed of rules that describe how to create and
initialize the elements of the target models. ATL transformations are always unidi-
rectional. Source models are read only and can be navigated, while target models are
write-only and cannot be navigated. However, ATL is only a QVT-aligned language.
Its concrete syntax and semantics are quite different from those given by the QVT
specification.
QVT-R and tools. QVT-R is a declarative model transformation language proposed
by the OMG as part of the QVT standard. It has both textual and graphical notations.
In QVT-R, a transformation is defined as a set ofrelations(rules) between the source
and target metamodels, where a relation specifies how two object diagrams, called
domain patterns, relate to each other. Optionally, a relation may have a pair ofwhen-
14
1.1. General Background
andwhere-clauses specified with OCL to define the pre- and post-conditions of the
relation, respectively.
Tool support for QVT-R is still immature [101]. Very few tools are considered
to be fully supporting the standard. Themedini QVT[117] is one QVT-R tool that
has a high degree of compatibility with the QVT standard. Features of medini QVT
include use of traces to enable incremental updates, limited support for bidirectional
transformations and thecheck-before-enforcesemantics. Yet some features, such as
collection template, are still missing.
The medini QVT provides a powerful QVT interpreter, and a transformation editor
with syntax highlighting, code completion, and debugging facilities. It is distributed
as an Eclipse plug-in or a stand-alone system. Currently, medini QVT seems to be
the most stable, mature and state-of-art implementation of QVT-R. It is chosen as the
model transformation tool in many researches. Our work also takes medini QVT as
the reference implementation of QVT-R. However, it looks difficult to integrate medini
QVT into CASE tools that are not based on the Eclipse platform.
Developed by Tata Consultancy Services Ltd.,ModelMorf [122] is another tool for
QVT-R. It supportsin-placetransformations, trace output, transformation inheritance
and relation overriding, incremental execution and collection templates. However, not
all language features of QVT-R are supported. For example, only two non-primitive
domains are allowed in a relation. The independent version of ModelMorf is only a
command-line QVT engine. It provides no integrated development environment, or
IDE. The transformations, models and metamodels have to be edited in other tools,
and exported in textual or XMI format.
Graphical notation of QVT-R. Both medini QVT and ModelMorf support only the
textual notation of QVT-R. However, we consider the graphical notation of QVT-R
more attractive. It uses UML object diagrams to define the structural matching pat-
terns of transformation rules. In addition, it has textual regions where OCL expres-
15
1. Introduction
sions can be used to specify rule constraints, evaluate values for local variables, and
decide the execution order of rules. The textual part therefore coexists with the visual
presentation so that users have a choice to appropriately present different aspects of a
rule using either textual or graphical expressions. Just as the combination of the virtual
diagrams and the OCL makes UML a perfect tool to define models, the graphical nota-
tion of QVT-R, with its visual presentations and OCL expressions, provides a concise,
intuitive and powerful way to specify model transformations. In [55; 58; 173], the
graphical notation of QVT-R was recognized as an intuitive, natural option to define
transformation, and the majority of transformations should be represented by the QVT
graphical notation [118]. In our research, we decide to use the graphical notation of
QVT-R to define the refinement transformations.
Some efforts have been made to support the graphical notation. The project of
Declarative QVT[3] intends to support QVT-R. Its goals include offering a graphical
editor for the graphical notation of QVT-R, and implementing a QVT engine on the
ATL virtual machine. In UPT [118], a UML profile for QVT graphical transformation
was presented. The purpose of the profile is to represent transformations using any
UML tool and send these transformations to different tools using the XMI standard.
Instead of using object diagrams, UPT uses a kind of class diagram to express the
transformation rules, so it is not fully QVT compatible. Also, theVisual Modeling
and Transformation System(VMTS) [30] provides a deployable QVT eclipse plug-
in [166]. Based on the VMTS tool, a QVT-R editor can be defined. Transformation
rules can be graphically specified in the editor, and then translated to VMTS code.
Nevertheless, currently the tools for the graphical notation of QVT-R are still far away
from practical use in software engineering.
16
1.2. Specific Background
1.2 Specific Background
MDD and CBD need sound theoretical foundations and strong methodology supports.
Particularly for the work of the thesis, we need a precise semantic theory for consistent
analysis and verification, as well as supporting object-oriented design and component-
based modeling. The latter is usually not within the consideration of the majority of
current formal approaches. More importantly, the formal method should contain a
comprehensive set of refinement rules for component and object systems. In this re-
gard, therefinement for Component and Object Systems(rCOS) [39; 97; 107; 112]
promotes a formal component-based model driven development method (CB-MDD)
for software development. Its scope covers theories, techniques, and tools for model-
ing, analysis, design, validation, and verification.
The rCOS has a formal semantic theory based on an extension of UTP [86] to in-
clude the concepts of classes, objects, components, interfaces, contracts, composition
(connectors), coordination and glue. It provides the behavioral semantics of these con-
cepts with high level rules for refinement and verification. This theory supports precise
checking of consistency among different model views, including static structure, inter-
actions and functionalities. It allows techniques and tool support to be integrated into
engineering processes with theories unified to underpin and justify the development of
tools and their integrated applications [97].
More importantly, rCOS provides the refinement calculus we need for supporting
the stepwise refinement in model-driven development process. It supportscorrect by
designwith its refinement calculus, includingdata functionality refinement, interac-
tion refinementandobject-oriented structure refinement[36; 82; 181]. The rCOS also
scales up refinement rules via formal use of design patterns [82; 114] and abstract-
ing of components from objects [107]. Application of such refinement rules as model
transformations generatesproof obligationsfor verification of properties of the models
before and after the transformations [112]. The verification tasks can be carried out by
17
1. Introduction
integrated verification tools, such as theorem provers, static checkers, or model check-
ers. The semantic theory of rCOS supports integrating verification into automated
correctness preserving model transformations.
The use ofdesign patterns[65; 103] makes rCOS refinement more systematic and
thus has much higher possibility for automation [82; 114]. Particularly, theexpert
pattern [103] is repeatedly applied to object-oriented design models forsupporting
stepwise refinement. The expert pattern provides a systematic decomposition of the
functionality of a method of an object into responsibilities of its related objects, called
information experts, which maintain or know the information for carrying out these
responsibilities [112]. Other patterns, such ashigh cohesion, low coupling[82; 103],
and rCOS refactoring rules [61; 114; 181] are used to optimize the structure of the
design models through introducing new classes, decomposing existing classes, and
adding or moving attributes of classes.
To support component-based design, rCOS defines a formal component model with
the notion of interface, component and component composition. In rCOS, a set of
composition operators are defined, such asparallel composition, plugging, disjoint
union, coordination, renaminginterface methods,hiding interface methods, etc. The
effects of these operators are proven in rCOS refinement calculus [97].
In addition, rCOS follows a use-case driven, incremental and iterative development
methodology that seamlessly combines model-driven, object-oriented and component-
based design and analysis techniques. The development process goes through the
stages of requirements elicitation, object-oriented design, logical component-based de-
sign, and to coding. Models in later development phases are constructed from those in
earlier phases by correctness preserving model transformations based on the rCOS re-
finement calculus. The main advantage of the rCOS methodology is that we can assure
consistency of the multi-view specifications at different abstraction levels [111].
18
1.3. Research Goals and Objectives
1.3 Research Goals and Objectives
Research problems. From the above discussion, we identify the following problems
to be addressed:
• Developing complex systems is a difficult task which cannot be done in one step.
Stepwise refinement is a useful method to help automating the development pro-
cess of MDA. But the current refinement techniques are difficult to apply on de-
veloping complex UML-based models across the full development phases from
requirements modeling to component architecture design, due to the limitation
of available refinement rules, the lack of methodological studies related to the
incremental refinement mechanisms, and the lack of integrated supporting tools.
Especially, applying refinements in theposit-and-provestyle, as done in many
existing formal methods, assists developers little in constructing models.
To take full advantage of stepwise refinement, we need a sound formal frame-
work that involves a comprehensive refinement calculus for supporting both the
object-oriented and component-based design. We also need to combine the for-
mal framework with UML, implement the refinement rules as correctness pre-
serving model transformations, and integrate them into a CASE tool, so the
graphical representations of the UML diagrams can be simultaneously updated
as the corresponding UML models are refined. In addition, as the judgement of
which model elements require to be refined is difficult, we mainly rely on the
developers to make the decisions. Thus it is worth studying how to effectively
apply the refinement transformations in an incremental and interactive way.
• It is often the case that an object-oriented model is developed first and then it
is further evolved to a component-based model to get the benefits of component
architecture, such as better reuse and maintenance. Identifying reusable compo-
nents from object-oriented models is considered to be one of the most difficult
19
1. Introduction
tasks in software development. Many of the existing approaches just provide
general guidelines without precise criteria and methods to automate the deriva-
tion of components from objects.
In order to seamlessly unify OO design and component-based design, and sup-
port OO implementation of component-based technologies, we need to provide
a transformation from an object-oriented design model to a component-based
model. Such a transformation can be used to transform a flattened OO design to
composition of a number of architectural components, and therefore decompose
a large component into a combination of internal sub-components. However, the
research challenge for the transformation is the formal definition of the correct-
ness criteria, and the algorithm for automation.
• The graphical notation of QVT-R provides a concise, intuitive and yet powerful
way to define model transformations. But the lack of tool support hinders its ap-
plication in real settings. It is also worth developing implementation techniques
and a supporting tool for this language. Particularly, this tool can meet our re-
quirement for implementing the refinement rules as model transformations.
Research goals and objectives.The research presented in this thesis is aimed at de-
veloping techniques to automate model-driven development of component-based soft-
ware through the application of model transformations. Particularly, in the context of
rCOS, this thesis addresses design and implementation of a set of rCOS refinement
rules as model transformations, and the use of the transformations to automate the
rCOS development process in an interactive and stepwise way. Because the automa-
tion of these transformations places a high demand on transformation tools, we have
developed the QVT-XSLT tool, by which a transformation can be specified using the
graphical notation of QVT-R, and become executable as programs of XSLT [178], a
standard language recommended by the W3C for transforming XML documents.
20
1.4. Research Methodology and Design
This goal is broken down into a set of partial objectives:
• Design and implementation of a model transformation approach and tool:
1. Analysis and evaluation of the QVT specification and related work, identi-
fying the most suitable way to implement the language;
2. Extend QVT-R if necessary;
3. Investigate an approach to support the graphical notation of QVT-R;
4. Design and implement a tool for supporting the approach;
• Support rCOS development methodology with model transformations:
1. Investigate rCOS theory and methodology to analyze and identify model
transformations required in rCOS development;
2. Investigate an approach for modeling rCOS in UML;
3. Design algorithms for the rCOS model transformations;
4. Implement the transformations using our transformation tool and integrate
them into the rCOS CASE tool;
5. Develop a method in which the full process of system development is
driven by interactively applying the model transformations with the CASE
tool.
1.4 Research Methodology and Design
The work of the thesis concerns engineering research and development. Similar to
scientific research, the research work in engineering is also about confirming particu-
lar theoretical predictions, but the artistry of design and the spirit of "make something
work" are also essential [47]. On the other side, development is the systematic use of
scientific and technical knowledge directed toward the production of useful materials,
21
1. Introduction
devices, or systems, including design and development of prototypes and processes.
Systems must be developed in order to test and measure the underlying theories. Sys-
tem development is therefore a key element of engineering research [127].
Figure 1.1: Research methodology (adapted from [127])
Our research work has been performed according to an integrateddesign research
methodologyproposed in [127]. As shown in Fig.1.1, this methodology corresponds
to a set of research activities:
• Theory building: includes development of new ideas and concepts, new methods,
or mathematical models. The theories may be used to suggest research hypothe-
ses, guide the design of experiments, and conduct systematic observations;
• Experimentation: includes research strategies such as computer and experimen-
tal simulation, as well as laboratory and field experiments. It straddles the gap
between theory building and observation by validating the underlying theories,
and evaluating the acceptance of systems and technology transfer. Experimental
designs are guided by theories and facilitated by system development. Results
from experimentation may be used to refine theories and improve systems;
22
1.5. Potential Contributions
• Observation: includes research work such as case studies, field studies, and lit-
erature surveys. Observation is often used when relatively little is known and it
can provide a general feeling for what is involved in a research domain;
• Systems development: includes concept design, constructing the architecture of
the system, prototyping, product development, and technology transfer. Concept
design is the adaptation of technologies and theories into potentially practical ap-
plications. It leads to a conceptual framework based on the theory building and
experiments. A system architecture provides a road-map for building system.
It puts the system components into perspective, specifies the system function-
alities, and defines the structural relationships and dynamic interactions among
system components. Prototyping is used as a proof-of-concept to demonstrate
feasibility. Much systems development stops at this stage. However, in order to
test the system in a real-world setting, an effort to further develop a prototype
into a product and the transfer of the product into an organization is necessary.
This allows a realistic evaluation of the impacts of the included technologies
and theories and their potential acceptance. The accumulated experiences and
knowledge will be helpful in redesigning the system. Thus systems development
is the hub of research that interacts with other activities to form an integrated re-
search life cycle.
1.5 Potential Contributions
In the domain of component-based and model driven software engineering, the follow-
ing contributions are made:
• C1. A framework to support stepwise refinement in MDD & CBD development.
It includes:
– C1.1. A UML profile for rCOS modeling, which augments rCOS with
23
1. Introduction
standard UML elements and diagrams, and defines the architecture and the
parts of an rCOS model;
– C1.2. Design and implementation of a set of model transformations that
realize the rCOS refinement rules, including:
∗ C1.2.1. OO design model to component-based model:Incrementally
applying the transformation obtains a correct refinement of an OO de-
sign model to a component-based architecture model, in which each
component of the requirements model becomes a composition of a
number of components. With the help of the transformation, the OO
design and component-based techniques can be seamlessly combined
in the development process.
∗ C1.2.2. Requirements model to object-oriented design model: This
transformation converts a requirements model into an initial OO de-
sign model, from which detailed OO design can start. The transfor-
mation helps to bridge the gap between requirement models and OO
design models;
– C1.3. We integrate the profile and the refinement transformations into an
rCOS CASE tool, and propose a development procedure for rCOS models
in the tool through applying these transformations in an interactive, step-
wise way.
• C2. A model transformation approach and tool for the graphical notation of
QVT-R, including:
– C2.1. An approach to map QVT-R transformations into executable XSLT
programs;
– C2.2.A method to map OCL, which is heavily used in QVT-R, into XPath,
a sub-language of XSLT;
24
1.6. Organization of the Thesis
– C2.3. An extension to existing QVT-R with three new constructs, for the
purpose of improving its usability in practice;
– C2.4. A graphical model query facility that adopts the graphical notation,
checking semantics and pattern matching mechanism of QVT-R;
– C2.5.A UML profile for modeling QVT-R in UML;
– C2.6. A supporting tool named QVTR-XSLT that consists of a QVT-R
graphical editor and an XSLT code generator. A QVT-R transformation
can be specified in the graphical editor using the graphical notation, and
then automatically translated into executable XSLT programs, which can
run fast and efficiently process large-scale models, and
– C2.7.A set of predefined transformations for improving the interoperabil-
ity of the tool, and for transformation verification and validation.
Since at the present time practical tool supports for the graphical notation of
QVT-R is scarce, our approach and tool mark a useful attempt to bring the
OMG’s standard language to practice.
ContributeC1 is presented in Chapter5 and6. Particularly, the rCOS profile of
contributionC1.1 is provided in Section5.2 and published as paper #1 in the publi-
cation list of Section1.7. The transformations of contributionC1.2 are given in Sec-
tion 6.2and6.1. Among them, contributionC1.2.1is reported in paper #3. We present
contributionC1.3 in Section5.3. In addition, Chapter4 is dedicated to contribution
C2, the QVTR-XSLT approach and tool. Particularly, contributionC2.2andC2.4are
published in paper #6 and #2, respectively. The applications of the QVTR-XSLT tool
are reported in paper #4 and #5.
1.6 Organization of the Thesis
The thesis is organized as follows:
25
1. Introduction
Chapter 1: Introduction. This chapter presents the motivation and the general
background of this thesis, lists its research goals and contributions.
Chapter 2: Model-Driven Development. In this chapter, we present an introduction
to the world of model-driven and component-based development, as the technical back-
ground for this thesis. We first introduce OMG’sModel Driven Architecture(MDA),
along with a set of its standards:Meta Object Facility(MOF), Unified Modeling Lan-
guage(UML), and Object Constraint Language(OCL). As model transformation is
the main means of manipulating models, we give an overview of model transforma-
tions and theQuery/View/Transformations(QVT), the standard model transformation
language of OMG. Finally, we review the concepts and general process of component-
based development.
Chapter 3: Refinement for Component and Object Systems – rCOS. In this
chapter, we review the fundamental concepts of rCOS and its development method-
ology. We first introduce the theoretical background of rCOS - theUnifying Theories
of Programming(UTP). Then we discuss the object-oriented part of rCOS with its syn-
tax, semantics and refinement rules. It is followed by component modeling techniques
of rCOS, and finally we describe its development process.
Chapter 4: QVTR-XSLT – A Tool for Graphical Notation of QVT Relations. We
present in this chapter our model transformation approach and tool for supporting the
graphical notation of QVT-R. We start with an introduction to the state of the art of
model transformation approaches and tools, and then compare the technical features
of QVT-R and XSLT. As QVT-R relies heavily on the use of OCL, we discuss how a
sub-set of OCL can be mapped into XPath, a sub-language of XSLT. We then present
the approach to translate QVT-R into XSLT, and discuss the semantic features of QVT-
R supported by the approach. To improve the usability of QVT-R, we provide some
26
1.6. Organization of the Thesis
extensions. In addition, we define a novel graphical model query facility which can
work within QVT-R. To support our approach, we propose a UML profile for QVT-R
and design a tool that consists of a QVT-R graphical editor and an XSLT code gener-
ator. Finally, we apply the tool on a case study and compare the results with another
QVT-R tool.
Chapter 5: A UML Profile for rCOS. In this chapter we present a UML profile
for the purpose of applying rCOS in practical UML-based software engineering. This
profile augments rCOS with standard UML model elements and diagrams, while en-
hances UML with the precise semantics and methodology of rCOS. We first briefly
review the major concepts of rCOS using a metamodel, which then maps to stereo-
types and their attributes of the rCOS profile. Then we define the UML elements used
in rCOS method. After that, we discuss the implementation of the profile in a CASE
tool and how rCOS development process is supported by the tool.
Chapter 6: Enabling Model Transformations of rCOS. In this chapter we show
how a set of rCOS refinement rules can be designed and implemented as model trans-
formations, and integrated into the rCOS CASE tool for supporting the rCOS devel-
opment. We present four of the transformations that are frequently used in rCOS, and
discuss in detail two of them. The first transformation automatically processes system
sequence diagrams into controller classes with method guards that enforce the seman-
tics of sequence diagrams, through an intermediate step of generating protocol state
machines. The second one, the object sequence diagram to component sequence dia-
gram transformation, enables component-based model-driven software design in prac-
tice by allowing the seamless combination of object-oriented and component-based
techniques. It is followed by a case study of a sale management system to show the
full development steps.
27
1. Introduction
Chapter 7: Conclusions and Future Work. In this chapter we summarize the re-
search work this thesis, discuss the limitations, and suggest future topics of research.
The contributions of the thesis are mainly discussed in Chapters4, 5 and6. The
main ideas and dependency relationships of the major chapters are depicted in Fig.1.2.
Figure 1.2: Dependency relationships of the major chapters
1.7 Statement of Originality
Part of the work presented in this thesis has been previously published as the following
three journal papers and five conference papers.
Publication list
1. Dan Li, Xiaoshan Li, Zhiming Liu, Volker Stolz,Support Formal Component-
based Development with UML Profile, In Proceedings 22nd Australasian Soft-
ware Engineering Conference (ASWEC 2013), IEEE Computer Society, Mel-
bourne, Australia, P191-200, June 2013.
28
1.7. Statement of Originality
2. Dan Li, Xiaoshan Li, Volker Stolz,Model Querying with Graphical Notation of
QVT Relations, ACM SIGSOFT Software Engineering Notes, Vol. 37, No. 4,
P1-8, July 2012.
3. Dan Li, Xiaoshan Li, Zhiming Liu, Volker Stolz,Interactive Transformations
from Object-Oriented Models to Component-Based Models, In Proceedings 8th
International Symposium on Formal Aspects of Component Software (FACS2011),
Vol. 7253 of LNCS, Springer-Verlag, Oslo, Norway, P97-114, Sep. 2011.
4. Dan Li, Xiaoshan Li, Volker Stolz,Solving the TTC 2011 Compiler Optimiza-
tion Case with QVTR-XSLT, In Proceedings Fifth Transformation Tool Contest
(TTC 2011), Vol. 74, Electronic Proceedings in Theoretical Computer Science
(EPTCS), Zürich, Switzerland, P54-69, June 2011.
5. Dan Li, Xiaoshan Li, Volker Stolz,Saying HelloWorld with QVTR-XSLT – A
Solution to the TTC 2011 Instructive Case, In Proceedings Fifth Transforma-
tion Tool Contest (TTC 2011), Vol. 74, Electronic Proceedings in Theoretical
Computer Science (EPTCS), Zürich, Switzerland, P223-236, June 2011.
6. Dan Li, Xiaoshan Li, Volker Stolz,QVT-Based Model Transformation Using
XSLT, ACM SIGSOFT Software Engineering Notes, Vol. 36, No. 1, P1-8, Jan.
2011.
7. Dan Li,QVT Based Model Transformation from Sequence Diagram to CSP, In
Proceedings 15th International Conference on Engineering of Complex Com-
puter Systems (ICECCS 2010), IEEE Computer Society, Oxford, United King-
dom, P349-354, March 2010.
8. Dan Li, Xiaoshan Li, Jicong Liu, Zhiming Liu,Validation of Requirement Mod-
els by Automatic Prototyping, Innovations in Systems and Software Engineering,
Vol. 4, No. 3, P241-248, Oct. 2008.
29
Chapter 2
Model-Driven Development
With the advent of visual modeling languages like UML, models and modeling tech-
niques have been widely applied in software engineering. As an emerging paradigm
for software development,Model-Driven Development(MDD) [119; 150] promotes
models as the primary software artifacts that can be explicitly manipulated by tools,
and systems are modeled at several levels of abstraction and from multiple perspec-
tives.
The key feature of MDD is that models are used in each stage of the software de-
velopment, from requirements to design to implementation, and it strongly emphasizes
model transformations between models used in the development process. That means
models in different development stages are linked through transformations, and the
ideas introduced in earlier stages contribute directly to building models in later stages.
Finally, these models can then be transformed into running systems by using gener-
ators or by executing the models at run-time [63]. Therefore, MDD requires models
to be complete, precise, and consistent specifications of a system with clearly-defined
semantics.
The main promises of model-driven development include [28]:
• increased productivity through automation of software production;
• improved manageability of complexity through higher level of abstraction;
• increased quality and reliability;
• better maintainability and documentation;
• easy portability to different platforms.
30
2.1. Model Driven Architecture (MDA)
However, model-driven development is still in its infancy compared to its ambi-
tious goals of having a (semi-)automatic, tool-supported stepwise refinement process
from vague requirements specifications to a fully-fledged running program. A lot of
unresolved questions exist for modeling tasks as well as for automated model transfor-
mations [57].
This chapter provides a general overview of model-driven techniques, including the
basic ideas of component-based development, as the background for this thesis. The
discussion of this chapter is partly based on the literature [46; 74; 134; 135; 148]. More
technical details and further related work will be discussed in the remaining chapters.
The structure of the chapter is as follows. We first introduce the best known MDD
initiative, Model Driven Architecture(MDA), the Object Management Group (OMG)
vision of MDD (Section2.1). MDA is founded on a set of standards. In Section2.2, we
focus on theMeta Object Facility (MOF) that basically allows for definition of mod-
eling languages. Section2.3describes theUnified Modeling Language(UML), which
is used to visually specify models, and its extension mechanism. Section2.4presents
Object Constraint Language(OCL) that complements the visual models by textual
constraints for clarifying the static semantics. As model transformation is the main
means of manipulating models, in Section2.5 we give an overview of model trans-
formations and theQuery/View/Transformations(QVT), the standard model transfor-
mation language of OMG. Finally, we review the fundamental concepts and general
process of component based development in Section2.6.
2.1 Model Driven Architecture (MDA)
One of the precursors of MDD is theObject Management Group(OMG), who defined
theModel Driven Architecture(MDA) [ 121] which has become rather popular today
in the software industry. OMG promotes MDA as a framework for system develop-
ment based on models. It is said to be model-driven because it provides means for
31
2. Model-Driven Development
using models to direct the course of understanding, design, construction, deployment,
maintenance and modification [121].
One of the main aims of MDA is to separate system design from system archi-
tecture. As the concepts and technologies used to realize designs and architectures
have changed at their own pace, decoupling them allows system developers to choose
from the best and most fitting in both areas. The design addresses the functional (use
case) requirements while architecture provides the infrastructure through which non-
functional requirements like scalability, reliability and performance are realized [171].
MDA also aims at integrating existing technologies standardized by OMG. It may
be seen as a specialization of MDD based on OMG standards. For instance, models are
expressed in UML. If another modeling language is needed, it should be defined using
the meta-modeling language of theMeta Object Facility(MOF), or defined as an ex-
tension of UML using theUML Profile. MDA usesXML Metadata Interchange(XMI)
for serialization of MOF models in XML format to persist models and to facilitate
the exchange of models between tools. In addition, theQuery/Views/Transformation
(QVT) language is used to transform models from one level of abstraction to another
abstraction level. We discuss these techniques in the subsequent sections.
2.1.1 Models of MDA
In MDA, models are specified from differentviewpoints, and a viewpoint is typically
focused on a specific system aspect. In [121], the term viewpoint is also clarified:
A viewpoint on a system is a technique for abstraction using a selected set of archi-
tectural concepts and structuring rules, in order to focus on particular concerns within
that system. Here ”abstraction” is used to mean the process of suppressing selected
detail to establish a simplified model.
MDA classifies models according to their abstraction level. In accordance to var-
ious stages of system development, MDA proposes four types of models:Computa-
32
2.1. Model Driven Architecture (MDA)
tion Independent Model(CIM), Platform Independent Model(PIM), Platform Specific
Model(PSM) andImplementation Specific Models(ISM). In the following we discuss
the first three of them:
1. Computation Independent Model (CIM): A description of a system from the
computation independent viewpoint, which focuses on the context and require-
ments of the system without consideration for its structure or processing. This
viewpoint is sometimes referred to as aconceptual viewpoint. A CIM describes
the domain and requirements of the system. Therefore, it aids understanding of
the domain problem, and it provides a system specific vocabulary for use in other
models. CIMs are often referred to as business or domain models, and play an
important role in bridging the gap between domain experts on the one hand, and
experts in design and construction of system artifacts, on the other hand.
2. Platform Independent Model (PIM) : A view of a system from theplatform
independent viewpoint. Here a platform is defined as a set of subsystems and
technologies that provide a coherent set of functionality through interfaces and
usage patterns [121]. The platform independent viewpoint, also known as the
design viewpoint, focuses on the operational capabilities of a system while dis-
regarding platform specific details. Platform independent views expose aspects
of a system that are shared between distinct target platforms. A PIM introduces
more details of logical and structural concerns, but is still independent of any
implementation technology. So it is possible to map a PIM to more than one
technology specific platforms.
3. Platform Specific Model (PSM): A model specified from aplatform specific
viewpoint. It is focused on the use of a specific platform. The viewpoint is
often identified as thedeployment viewpoint. A PSM augments its counterpart
PIM with details on how the system uses a particular type of platform and the
associated implementation technology. However, a PSM is still considered as an
33
2. Model-Driven Development
abstract model, since it may not include all of the details necessary to produce
an implementation on that platform.
2.1.2 Development process of MDA
MDA envisages to shift the work of the developers to higher levels of abstraction and
then generating the source code of the desired system automatically by applying mul-
tiple transformation steps. According to MDA, with respect to the previously defined
model types, a typical MDD cycle for a software system contains the following phases
[148]:
1. Specification of CIMs: Through analyzing the business processes addressed,
requirements and domain specific knowledge are specified within CIMs that pri-
marily describe the application’s context, and define a common vocabulary for
all forthcoming models. For capturing the requirements, UML use case diagrams
and system sequence diagrams [103] can be used.
2. Development of PIMs: Platform independent models are developed in accor-
dance to the application’s domain models (CIMs). This is done by taking more
computational issues into account, such as business logic, but still disregards
platform-specific details. These information can be represented in UML class
diagrams, object diagrams, activity diagrams and interaction diagrams. A PIM
should also be precise enough to support transformation into target PSMs.
3. Platform Specification: The underlying system’s technical concepts, like avail-
able interfaces, usage patterns, architectural properties, but also physical parts,
and available resources are specified in the platform specifications.
4. Transformation of PIMs to PSMs: The heart of a MDA compliant MDD pro-
cess is the transformation of PIMs to PSMs. The model transformations must
34
2.2. Meta Object Facility (MOF)
have been developed beforehand. Taking as input a particular platform specifi-
cation, the transformations automatically translate a PIM into a PSM by adding
platform specific patterns and architectural properties defined in that platform
specification. Note that a number of PSMs can be derived from a same PIM.
5. Transformation of PSMs to Code: A final step within a MDD process is code
generation. Typically, PSMs are translated into deployable executable code. This
transformation is mostly carried out by translating PSMs to source code that in
succession is compiled and linked into an executable binary.
Thus the development process of MDA is characterized by independently (and mostly
manually) developing an abstract model and an additional model with the platform
information, and a transformation is used to automatically merge the two models into
a more concrete model or implementation.
2.2 Meta Object Facility (MOF)
TheMeta Object Facility(MOF) [132] is an OMG standard that provides a framework
for specifying, constructing, and managing metamodels. MOF is recommended as
a main technology of MDA for defining modeling languages. Many other OMG’s
standards rely on MOF.
MOF conforms to the classic four-layer metamodeling architecture. In general,
a model in layern is calledan instance ofthe corresponding model in layern + 1,
which in turn is called itsmetamodel, and a model must conforms to its metamodel. In
Fig. 2.1, we illustrate these four modeling layers:
• Layer M0: The Instances. The bottom layer contains run-time instances of
model elements in a concrete system. These instances are considered as part
of the real world that is modeled and therefore M0 should not be regarded as a
35
2. Model-Driven Development
Figure 2.1: The four modeling layers of MOF
model level. The instances are manifested in various forms, such as objects in
object-oriented applications. M0 models are called snapshots of M1 models.
• Layer M1: The Model. This layer contains the model elements describing the
the concepts of a system. Within the MOF architecture, a UML model resides on
this layer. For example, the structural concepts of a university can be modeled
in terms of a class model and comprise classes such asdepartmentor student.
• Layer M2: The Metamodel. This layer contains the elements of the meta-
model. Models at M1 are expressed in modeling languages defined by means of
meta-models located at layer M2, e.g. UML metamodel. It should be noted that
the main purpose of the MOF model is to define modeling languages at layer
M2.
• Layer M3: The Meta-Metamodel. Finally, the top layer, the most abstract one,
contains the meta-metamodel, known as the MOF metamodel. It provides the
core modeling facilities for defining modeling languages, where classes repre-
sent modeling concepts, attributes for their variations, and associations for their
relationships. An example of this layer is the MOF itself, MOF is defined recur-
sively, that is, a model on this layer is an instance of itself
36
2.2. Meta Object Facility (MOF)
2.2.1 Essential MOF (EMOF)
Currently there are two versions of MOF:Complete MOF(CMOF) andEssential
MOF (EMOF). CMOF provides all modeling capabilities of the standard with more
sophisticated concepts, such as the reflection mechanism. It is used to specify complex
modeling languages such as UML. EMOF is a subset of CMOF. It provides a ”kernel
metamodeling capability” for defining simple metamodels using simple concepts while
supporting extensions. The EMOF is motivated by the fact that many metamodels do
not require the expressive power provided by CMOF.
EMOF is a straightforward, simple framework built on a restricted version of UML
class model that provides concepts and graphical notation. In other words, MOF and
UML are aligned to share a common core of concepts, which are presented as simple
classes with attributes and operations. Therefore, the OMG factored out the common
part of MOF and UML class model into the UMLinfrastructure, the minimal set of
object-oriented language elements, which is then reused to define MOF and UML class
diagrams.
Figure 2.2: Extract of the EMOF metamodel
The most important parts of the EMOF metamodel are shown in Fig.2.2. Basically,
the EMOF model consists ofclassesthat can be related with each other using various
kinds of associations, which can be directed such as thesuperClassrelation. Classes
37
2. Model-Driven Development
may containoperationsandproperties. For example, theNamedElementhas one at-
tribute called "name" of typeString. Properties can be either attributes or association
ends. To put it simple, classes can be regarded as types of model elements, whereas
associations can be seen as types for the links between model elements.
2.2.2 XML Metadata Interchange (XMI)
A standard related to MOF is the OMG’sXML Metadata Interchange(XMI) [ 133]
specification, which provides a set of rules that map the graph-based models to/from
tree-based XML documents. One purpose of XMI is to enable easy interchange of
models between UML-based modeling tools and MOF-based model data repositories.
XMI is also commonly used as the medium by which models are passed from modeling
tools to software generation tools as part of model-driven engineering.
XMI defines the method to serialize EMOF elements with XML tags. The structure
of an XMI document tightly matches that of the corresponding MOF model, with the
same names and an element hierarchy that follows the model’s hierarchy. As a result, a
model and its XMI serialization are isomorphic. The great advantage of XMI is that it
can be processed by the whole range of generic XML processors which are available in
every popular programming language. But unfortunately, XMI is excessively verbose
and is not easy for humans to read. Even small models yield large XMI files. Moreover,
XMI is not yet implemented in a standard way by tool vendors, e.g. MagicDraw XMI
is different from Visio XMI.
EMF Eclipse Modeling Framework (EMF) [54] is a modeling framework based on
an implementation of EMOF. It employs an XMI serializer to provide storage capa-
bilities for persistent models. The EMF XMI has essentially implemented XMI 2.0,
but keeps the document to a reasonable size. In contrast to graphs, an EMF model
has a tree structure which is characterized by the containment relations between their
elements. An EMF model has a root element that all the other elements are transi-
38
2.3. Unified Modeling Language (UML)
tively contained in, and may have non-containment references in addition [24]. The
ability to output models in EMF XMI format is becoming a standard feature in many
major modeling CASE tools, such asMagicDraw UML [126] andTopcased[165]. In
practice,EMF UML andEcoreare two most often used model types.
2.3 Unified Modeling Language (UML)
Currently, the object-oriented paradigm has become a prevalent paradigm in software
engineering. Supporting the concepts of object orientation, theUnified Modeling Lan-
guage(UML) [ 76; 135] has become thede-factostandard modeling language for sys-
tem analysis and design. As UML is widely used in industry and academia for model-
ing purposes, a large number of tools have been developed to support it.
UML is a visual modeling language for specifying, visualizing, constructing, and
documenting the artifacts of software systems [90]. A UML model has a graphical
representation. UML provides a set of notations that describes a system from dif-
ferent, partly overlapping perspectives. The whole complex system is separated into
several sub-models, and each sub-model specifies an aspect of the system, like its static
structure, or its behavior. In total, UML defines thirteen types of diagrams, which are
divided into two categories:
• Structure diagrams: show the static structure of the objects in a system. That is,
they depict those elements in a specification that are irrespective of time. The
elements in a structure diagram represent meaningful concepts of an applica-
tion, and may include abstract, real-world and implementation concepts. This
category includes class, object, composite structure, component and deployment
diagrams, etc.
• Behavior diagrams: depict dynamic behavior of the objects of a system, such as
their collaborations, activities, and state histories, which can be described as a
39
2. Model-Driven Development
series of changes to the system over time. This category includes activity, state
machine, and use case diagrams, interaction diagrams (including communica-
tion, interaction overview, and sequence diagrams), etc.
Advantages of using UML are numerous. UML is expressive enough to specify
complex system. As a standardized language it improves communication between dif-
ferent stakeholders, and provides a means to document software intensive systems. By
offering a common language it allows tool interoperation between different vendors.
In spite of its success, however, UML has its drawbacks. Since UML is designed
as a general-purpose modeling language which can be used in many application do-
mains and on many implementation platforms, it becomes a rather bloated and com-
plex language. UML involves too many concepts and mechanisms, many of them are
overlapping and far from being intuitive in many cases. There are also issues with the
semantics of UML. OMG only provides UML with a rather loose semantics defined in
natural language, where lots of ambiguities are introduced. For example, the seman-
tics of UML behavioral modeling brings certain ambiguities, and the problem cannot
be resolved by OCL [60]. Therefore, the validation of unrestricted UML applications
cannot be achieved in a precise way. Moreover, UML is claimed to be methodology-
independent. That is to say UML is defined as only a modeling language, there is a
lack of methodological support for using UML in development processes.
2.3.1 UML diagrams
In the following, we give a general description of UML diagrams used in the thesis.
A more formal definition of them will be given in Section5.2. We use as example
thepoint-of-sale system(POS) taken from Larman’s textbook [103]. This example de-
scribes a trading system that is typically used in supermarkets. This system deals with
business processes such as checking out at a cash desk, handling payments, managing
users, etc.
40
2.3. Unified Modeling Language (UML)
Use case diagrams
Use case diagrams specify high-level user interactions with a system. They are useful
for defining the usage requirements for the system. A use case diagram describes a set
of actions (use cases) that the system (subject) should or can perform in collaboration
with one or more external users of the system (actors). Actors are either real (human)
user roles, or other systems which are using the system under development. Each use
case represents some abstract activity that the actor may perform and for which the
system provides the support. Thus, the use case diagram defines the system bound-
ary, in which use cases may be applied to define the coarsest-grained logical system
modules. The modules can then be implemented as high-level components.
In addition, use case diagrams show the associations between the actors and the
use cases. An association exists whenever an actor is involved with an interaction
described by a use case. Use case diagrams also indicate the relationships between use
cases. A use case may be a variation of some other use case (the«extend» relationship),
or may incorporate one or more use cases using the«include» relationship, where the
behavior of the included use case is inserted into the behavior of the including (base)
use case.
Overall, use case diagrams are applied at initial requirements engineering phases
in the software life cycle to specify the different roles and functionalities of the system.
Use case diagrams are often defined in terms of the actual business processes of the
application domain. Fig.2.3 displays an example use case diagram for the checkout
system of the POS example. There are four use cases specified in the diagram, in
which the use caseCheckoutrefers to the included use caseDoPayment, and the use
caseHelp extends the use caseCheckout.
41
2. Model-Driven Development
Figure 2.3: A use case diagram
Class diagrams
As the main building block of object oriented modeling, class diagram is the most
widely used type of UML diagram. It is usually used to capture the static, logical
structure of a system, and specify the functionalities performed by the system. In
general, a class diagram consists of a number of classes that represent static concepts
of the application domain of the system. For each class it is possible to list its attributes
and operations. Syntactically a class is displayed as a rectangle that consists of a name
compartment in the top, an attribute compartment in the middle, and an operation
compartment in the bottom.
The relationships between classes come with different meanings:
• A normal association(for shortassociation) defines any arbitrary relationship
between two classes. It specifies how instances of the classes are linked to-
gether. An association can be labeled with a name, which uniquely identifies the
association. An association can also haverole namesannotated at theassocia-
tion ends, which can be used to refer to the associated instances. In addition,
42
2.3. Unified Modeling Language (UML)
multiplicity of an association end indicates how many of the instances at this end
can be allowed to participate in the relation.
• An aggregationis a special association which indicates that a class (the aggre-
gate) is comprised of another class (the part). It specifies a whole-part relation-
ship. This is in fact similar to the containment model, and is not specific about
who creates and owns the subordinate classes.
• A composition associationis a strong form of aggregation to indicate an owner-
ship relation between classes. The part class is contained in the owner class and
not shared with other classes. Composition associations have coincident life-
times of whole and part. That means once an object of the part class is created,
it must be destroyed before or at the same time with its owner.
• A generalizationis a form of association that indicates an inheritance relation-
ship between two classes, that is, a relationship between a more general class
(superclass) and a more specific class (subclass). The specific class inherits part
of the definition, including attributes, associations, and operations, from the gen-
eral class.
In the work of the thesis, we use only the binary association, the most common
kind of association. Other association kinds, such asternary, n-ary or association
classes, will not be considered. Also we will not consider the aggregation, and use the
composition associations only, since the latter covers most of the functionality of the
former. Fig.2.4 shows an example class diagram that describes the domain concepts
and their relationships of the POS system.
Another UML diagram that is closely related to class diagrams is theobject dia-
gram. An object diagram represents an instance of a class diagram. It shows class
instances depicted as objects connected bylinks, which are instances of associations
defined in the class diagram. An object has itsslotsthat are instances of the attributes
43
2. Model-Driven Development
datetime : Datetotal : MoneyisComplete : Boolean
+makePayment( amt )+makeLineItem( desc, qty )+becomeComplete()+getTotal()+cancel()+abandon()
Sale
id : String
+makeNewSale()+enterItem( id, qty )+endSale()+makePayment( amt )
Register
amount : Money
Payment itemID : ItemID description : String price : Double
ProductDescription
+getDesc( id )
ProductCatalog
quantity : Double
+getSubTotal()
SaleLineItem
name : String address : String
+addSale( s )
Store
name : String address : String
User
+catalog1
+workon
1
+completedSales
0..*
+description
1
+lineItems
1..*
+store
1
+payment 0..1 +descriptions 1..*
+currentSale 0..1
Figure 2.4: A class diagram for the POS system
of the corresponding class. Object diagrams can be consider as the snapshots of a
running system, representing thesystem stateat a particular moment.
However, UML introduces the conceptclassifieras a general super-class of model
elements that have common behavioral or structural features. A classifier is a classi-
fication of objects according to their features. Many UML model elements, such as
actors, classes, components, interfaces, use cases, as well asenumerationsandprim-
itive types, are all descendants of the classifier. Classifier is an abstract metaclass and
therefore cannot be instantiated. To simplify the expressions, sometimes we use ”in-
stance of aclassifier” instead of ”instance of instantiable descendants of aclassifier”.
State machine diagrams
The state machine diagram is one of the UML diagrams used to model dynamic nature
of a system. Particularly, it describes a system’s reactive behaviors, that is, how a
system responds to the external or internal stimuli. As the life cycle of an object can be
considered as a sequence of differentstates, a state diagram depicts the various states
that an object may be in and the transitions between those states. The state machine can
44
2.3. Unified Modeling Language (UML)
Paid
Archived
NewCreated
HasItemscancel
abandon
makeNewSale
makeLineItem
makePayment
becomeComplete
makeLineItem
Figure 2.5: A state diagram for classSale
be used for modeling discrete behavior of an instance of class, or part of the system,
such as use cases and operations. In addition, it can also be used to express the usage
protocol for part of a system. These two kinds of state machines are defined in UML
asbehavioral state machineandprotocol state machine.
The state machines are made up of states, events and transitions. Astate is an
exposed stable situation of an instance, in which it satisfies some condition, performs
some action, or waits for some event. States are represented by the values of the at-
tributes of the instance. They are shown in rounded rectangles in the state diagrams.
It is possible to have initial state and final state, the former represents the one that
an object is in when it is first created, whereas the latter indicates the last situation
throughout the life cycle of an instance. A state may comprise other encapsulated sub-
states. In such a case, the state is acomposite state. A transitionis a progression from
one state to another. It is triggered by aneventthat may be the invocation of a method
that causes an important change in state, or the sending of a message to the instance. A
transition is shown as an arrow, labeled with the triggered event. Fig.2.5 presents an
example state machine diagram specifying the state migrations for an instance of the
Saleclass.
45
2. Model-Driven Development
Sequence diagrams
UML interaction diagrams depict the detailed interaction steps between actors and
other entities of a system involved in particular use cases, or particular sequence in-
teractions between objects of a system. Two types of interaction diagrams are used in
UML: communication diagramsandsequence diagrams. We will mainly use sequence
diagrams in our work.
Sequence diagrams focus on time passage, that is shown vertically, increasing from
top to bottom. A sequence diagram consists of a frame, representing the environment
of the specified system. Inside the frame, the vertical dashed lines, calledlifelines,
represent individual instances that participant in the interaction. An instance could be
an object of a class, a component, an interface, an actor, or a system. Each lifeline can
have a name that should be unique within the diagram. The instances communicate
by means ofmessages, represented as horizontal arrows that are sent and received by
lifelines. The messages on one lifeline are always ordered (hence we describe them as
a sequence). A message can be a signal or an operation call. In the latter case, a small
vertical rectangle on a lifeline represents the execution period of the called operation.
In addition,combined fragmentsare drawn as big rectangles that may cover several
lifelines and contains several messages. Depending on the so-calledoperator labeled
in the top left corner, a combined fragment provides additional control flows, such as
conditional choice (opt or alt) and recursion (loop).
The intuitively appealing character and conceptual simplicity make the sequence
diagram an ideal tool for describing interaction behaviors of a system, even for non-
experts. During the requirements modeling phase, architects and developers can use
the diagram to specify the scenarios of use cases more precisely. A use case is often
refined into one or more sequence diagrams. This kind of sequence diagrams is often
called asystem sequence diagram, as it involves only two lifelines, one representing
an actor, and the other representing the system. In the design phase, sequence dia-
46
2.3. Unified Modeling Language (UML)
[i] : SaleLineItem : ProductCatalog
sl : SaleLineItem
: Cashier : Register : Sale
enterItem(id,qty)1:
desc=getDesc(id)2:
makeLineItem(desc, qty)3:
create(desc,qty)4:
add(sl)5:
Figure 2.6: A sequence diagram for operationenterItem
grams can also be used to specify how the functionality of an operation is spread over
multiple objects, and how such a functionality is implemented through sequences of
method invocations. Fig.2.6presents an example sequence diagram for the operation
enterItemintroduced in classRegisterof Fig. 2.4. This sequence diagram describes
the interactions among related objects to realize the functionality of the operation. The
following program code shows how this operation is implemented in Java.
public classRegister {
private Sale currentSale;
private ProductCatalog catalog;
public void enterItem(String id, Doubleqty) {
ProductDescription desc = catalog.getDesc(id);
currentSale.makeLineItem(desc,qty);
}
......
}
public classSale {
private Set <SaleLineItem> lineItems;
public void makeLineItem (ProductDescription desc,Doubleqty) {
47
2. Model-Driven Development
private SaleLineItem sl;
sl= new SaleLineItem(desc,qty);
lineItems.add(sl);
}
......
}
public classSaleLineItem {
private ProductDescription description;private Double quantity;
public SaleLineItem((ProductDescription desc,Doubleqty) {
description = desc; quantity = qty;
}
......
}
2.3.2 UML profiles
As a general-purpose modeling language, UML includes two kinds of extension mech-
anisms, which can be used to define UML based domain-specific languages. Exten-
sibility mechanisms enable tailoring and extension by adding new building blocks,
creating new properties and specifying new semantics in order to customize a model-
ing language to a specific problem domain in a controlled way. The first mechanism,
a heavyweight one, is based on direct modification of the UML metamodel. A new
metaclass may be defined by inheriting from an existing UML metaclass, with con-
straints, meta-attributes and associations specified. This approach sets no restrictions
on what is allowed to change in the UML metamodel, but the user models that uses the
new metaclasses are usually not supported by existing CASE tools.
On the other hand, there is a lightweight extension mechanism which easily adapts
UML through the use of profiles. A UML profile describes how UML elements are
48
2.3. Unified Modeling Language (UML)
tailored to support usage in a particular modeling domain by
1. introducing new concepts, syntax/notation and constraints;
2. introducing new terminology, semantics, and,
3. limiting the visibility and usage of particular model elements to the system de-
signers.
The primary extension means is thestereotype, which extends an existing UML ele-
ment with new attributes and associations, additional constraints and semantics. UML
uses thesemantic variation pointsto plug the additional semantics into the UML con-
cepts. Through themetamodelReferencepackage, we can specify the filtering rules that
determine which UML elements are visible when the profile is applied and which ones
are hidden [135]. However the profiles mechanism is not a first-class extension mech-
anism. It is not possible to take away any of the constraints that apply to a metamodel,
and also it is impossible to add properties to the extended classifier. As a consequence,
a meta-attribute (tagged value) can only be owned by a stereotype.
In brief, a UML profile is a kind of UMLpackagededicated to group UML ex-
tensions: stereotypes, tagged values, constraints defining well-formedness rules, icons
representing the stereotypes, pre-defined domain-specific model elements as libraries,
and imported UML model elements to support modeling in specific domains. Profiles
should be independent of tools. That’s to say the design of UML profiles should not
constrain to particular tools, and the profiles, together with models to which they have
been applied, must be possible to interchange among the vast majority of UML case
tools [135]. Moreover, a profile presents the usage of the modeling concepts in it, and
gives a generalized description of the possible systems after applying the profile.
Currently, there is no standard approach to define a UML profile for a specific
domain. Several authors [49; 102; 151] have proposed a set of steps for the creation of
aprofile. We use the following procedure to define our profiles for the thesis:
49
2. Model-Driven Development
1. Define the domain metamodel: a metamodel for the application domain is de-
fined to specify the concepts and their associations, as well as the semantics and
the constraints. This metamodel should be strictly based on the needs of the
application domain, without any consideration of the UML concepts;
2. Design the structure of the profile: how to organize the concepts of the meta-
model into different packages;
3. Define stereotypes: identify the UML elements to be extended, map the meta-
model concepts into these elements, and add necessary associations and at-
tributes. The UML elements whose semantics are closest to the semantics of
the domain concepts will be selected first as the base metaclasses;
4. Define well-formedness constraints: the constraints for the stereotypes are de-
fined using OCL;
5. Specify semantics: normally use natural language. Ideally, the semantics should
be defined in a formal manner for each stereotype; and,
6. Provide tool supports: develop tools for applying the profile in practice, either
built from scratch or adjusted from available tools.
Following the standard UML profile notation, the stereotype definition part of a profile
is presented as UMLprofile diagrams. A UML profile diagram is a special kind of
class diagram where a class either has label«metaclass» or «stereotype». The former
(metaclass) must be a standard UML metamodel element that is extended (the arrows
with the filled-triangle arrowhead) by the latter (stereotype). The name of the stereo-
type declares a new user-defined stereotype. All associations can only be directed from
a stereotype into a metaclass, or to another stereotype. Different from regular profile
diagram, we also indicate some associations between metaclasses. These associations
have already been defined in the UML specification, but we find them important to
express the semantics and to facilitate the definition of OCL constraints.
50
2.4. Object Constraint Language (OCL)
2.4 Object Constraint Language (OCL)
In general, a visual modeling language like UML is not expressive enough to achieve
the level of modeling precision required by MDD. In order to express complex relations
and restrictions in models, theObject Constraint Language(OCL) [131] is introduced
as part of the UML 2.0 standard. OCL is a textual, declarative language. A particular
characteristic of OCL is its mathematical foundation without mathematical symbols
[168]. OCL is based on mathematical set theory and predicate logic, but uses plain
ASCII words to express the concepts. This makes UML easier to learn for a broad
community of system designers and developers.
OCL is a strongly typed, side-effect-free language. Each OCL expression has a
type. The evaluation of an expression always returns a value as the result, and never
changes the system state. The type system of OCL is based on two kinds of types:
predefined types and user-defined types. The predefined types includes basic types,
such asInteger, String, and collection types, such asSet, Bag. The OCL standard
library [131] defines all these predefined types and the operations on thesetypes, for
examples, logical operations likeand, or, not, and arithmetic operations. As an OCL
expression is always evaluated on a contextual element that is defined in a class model,
the class model provides all the user-defined types for the OCL expression. However,
in an OCL expression, the contextual element can be explicitly referred to by theself
keyword.
OCL allows specification of formal constraints over MOF-based models. It serves
several purposes. Firstly invariants can be specified for classes. An invariant is a pred-
icate that must always holds before and after the execution of an operation. The invari-
ants are also called well-formedness rules. As OCL are, in theory, modeling language-
independent, OCL constraints can be defined on meta-metamodel (M3), metamodel
(M2) and model (M1) layers, and always affect the instances of the constrained ele-
ments on a lower metalevel, e.g., well-formedness rules for a model are validated on
51
2. Model-Driven Development
instances of the model. For instance, a rule says that theid as the identifier should be
unique in all instances of the classRegisterdefined in Fig.2.4.
context Register
inv uniqueId : Register→forAll (r1,r2 | r1< >r2implies r1.id< >r2.id)
A model which violates any invariant simply does not conform to its metamodel.
In particular, well-formedness rules on the metamodel layer define thestatic semantics
of a modeling language. On the model layer, business rules of the application domain
can be expressed as class invariants.
Secondly OCL supports the design-by-contract principle by defining contracts for
operations. Each contract consists of a pair of pre- and post-conditions that are boolean
expressions. Pre-conditions specify the conditions that must hold when the execution
of an operation is triggered, and post-conditions specify the conditions that must hold
when the execution of the operation terminates [131]. Third, OCL can be used to
define additional attributes and operations. Attributes added using OCL are always
derived attributes, i.e., their values are calculated from the values of other attributes.
OCL expressions can also be used to provide initial values for the attributes.
In addition, OCL 2.0 has matured from a constraint language to a full model query
language. It can navigate models and form collections of objects that satisfy given con-
ditions. Through the introduction of the tuple type, OCL now has the expressive power
of queries inrelational algebra. It supports a set of relational algebra operations, such
asunion, difference, selectionandcartesian product. However, even though OCL has
enough expressive power, a textual query language like OCL does not blend well with
visual models. Moreover, standard OCL expressions are claimed to be too verbose,
even defining simple queries quickly leads to complex query statements [157]. To
address these problems, a graphical query notation could help.
52
2.5. Model Transformations and QVT
Essential OCL Essential OCL is the minimal OCL required to work with EMOF
[131]. It is motivated by the same considerations as EMOF, that is,providing a simple
query and constraint language for simple metamodels. In essential OCL, concepts that
are specific to UML (likestateandmessagenotions) are removed, and special OCL
types such asAnyType, VoidType, andInvalidType, are not supported. In the work of
the thesis, we mainly use essential OCL.
2.5 Model Transformations and QVT
Model transformations
Model transformation represents one of the cornerstones of MDA. It is the process of
converting models into other models for the purposes of supporting rigorous model
evolution, verification, refinement, and code generation [63]. As shown in Fig.2.7, the
problem of model translation can be stated as follows: given a source metamodelMMA,
asource modelMA (as an instance ofMMA ) and a target metamodelMMB , define and
execute a transformationTAB which generates a modelMB that is an instance ofMMB
and suitably corresponds toMA. The transformationTAB conforms to its metamodel
MMT , but it involves also the metamodelsMMA andMMB to define the transformation
rules. All the metamodels finally conform to the meta-metamodel MOF at model layer
M3. In a more general case, a transformation can has multiple source models, and
produces multiple target models.
However, a transformationTAB itself can also be a model, called atransformation
model, which conforms to its metamodelMMT . Just as a normal model, a transforma-
tion model can be created, modified, and augmented through model transformations,
calledhigher-order transformations, to achieve the objectives of optimizing the trans-
formation, or producing a transformation model in another transformation language.
This uniformity implies that transformations can themselves be generated and handled
53
2. Model-Driven Development
Figure 2.7: Model transformation
by model-driven development, and this allows reusing tools and methods of the same
transformation frameworks.
Metamodels and models are in general complex information structures, because
they represent different kinds of information. Therefore, it is challenging to develop
languages and tools for automatic model transformations, because it requires different
types of knowledge and techniques to understand and handle the application domains,
and the syntactic and semantic issues.
Model transformations can be classified from different perspectives. According to
the metamodels, to which the source and target models conform to, two kinds of trans-
formation can be distinguished:exogenousandendogenous. An endogenous transfor-
mation, also called anin-placetransformation, translates a source model into a target
model that conforms to the source model’s metamodel (that is,MMA = MMB), e.g., a
refactoring of a UML class model. In contrast, an exogenous transformation, orout-
placetransformation, uses different source and target metamodels (MMA <> MMB),
e.g., transforming UML class models to relational database models.
54
2.5. Model Transformations and QVT
According to the transformation directions, a transformation can beunidirectional
or bidirectional. A unidirectional model transformation has only one execution direc-
tion, that is, it always modifies the target model according to the source model. In
case of a bidirectional transformation, the source model may be changed along with
the target model if the transformation is executed in the direction of target-to-source.
Many approaches have been proposed for model transformations. Based on the
classifying work of [45; 120], we can divide transformation approaches into the fol-
lowing major categories:
• Direct manipulation: General purpose programming languages, such as Java,
C++, can be used to implement model transformations aided by the use of APIs
libraries. Thevisitor patternis usually used to traverse the internal representa-
tion of a model to find matches. An advantage of this approach is that program-
mers do not need to learn a new language. On the other side, transformations
are defined at a low level of abstraction, thus they tend to be too complex and
unmaintainable.
• Template-based:It is commonly used with model-to-text transformations. Tem-
plates contain fragments of the target text and variables that can be replaced by
values from the source model elements. A typical example of this approach is
AndroMDA [1].
• Imperative/Operational: This approach is similar to the direct manipulation
approach, but with some high level constructs and language concepts. The trans-
formation is described as a sequence of rules that explicitly state how and when
to create elements of the target model from elements of the source one; the exe-
cution order of the transformation rules is also explicitly controlled. Imperative
languages offer flexibility and allow for efficient implementation. Since the large
amount of detail required for the transformation description, the transformation
55
2. Model-Driven Development
rules tend to become lengthy [120]. QVT-Operational Mappings [134] is an
example of the imperative languages.
• Graph transformation : Graph transformation languages build mainly on the
theoretical foundations of graph rewriting over extensions or variations of typed,
attributed, labeled graphs. Models are interpreted as graphs, and a transforma-
tion consists of an attributed type graph and a set of transformation rules (or
productions). AGG [34] and Fujaba [33] are among the many tools realizing this
approach. Recently, Triple Graph Grammars (TGG) [149] has become a promis-
ing approach as an extension of graph transformation. Its rules are specified by
three different graphs. Several tools such as MOFLON [14] and ATM3 [51] im-
plement TGG for model transformations. However, the solid formal foundation
allows automatically analysis of graphical transformations, but the expressive
power of graph transformation rules is often weak.
• Declarative/Relational: Declarative model transformations describe the rela-
tions between the source and the target metamodels, instead of specifying how
the transformation should be explicitly executed. The focus is on what should be
mapped by the transformation. Graph transformation is a subcategory of declara-
tive languages. Declarative languages are in general compact and transformation
descriptions are normally short and concise. QVT Relations is a perfect example
of the declarative model transformation approach.
• Hybrid : Hybrid transformation languages provide both imperative language
constructs and declarative language styles, and leave the user to choose which
style to use. Some widely used languages adopt a hybrid approach, and advocate
that the declarative style should prevail over the imperative one.
Of all these approaches, we are particularly interested in the declarative ones, as
they are usually more concise, and make reasoning about the transformation rules eas-
56
2.5. Model Transformations and QVT
ier. In this thesis, the declarative model transformation language QVT Relations (QVT-
R) is used to define model transformations of the rCOS method.
In declarative style, a model transformation always consists of a set of transforma-
tion rules. In general, a rule is expressed in three parts: two patterns, one from each
metamodel of the transformation, and a rule body. A pattern specifies a fragment of a
metamodel, either visually or textually. Thus, the source pattern indicates which seg-
ment of source model can be transformed, and the target pattern is used as a template
to generate a segment of the target model. In the context of graph transformation, the
source pattern is called the left hand side (LHS) and the target pattern is called the
right-hand-side (RHS). The rule body defines the link, also called relation, between
the source pattern and the target pattern. Also the rule body provides the conditions
under which this rule can be applied. Consequently, the rule body itself can be spec-
ified graphically, as in the case of graph transformations, or textually, where OCL is
frequently used.
Query/Views/Transformation (QVT)
Figure 2.8: QVT Architecture (from [134])
In 2002, the OMG issued a request for proposals to standardize in the domain of
Queries, Views and Transformations (QVT RFP) [130]. And in 2005, the OMG pro-
posed a standard consisting of three languages for model transformation: Relations,
Core and Operational Mapping [134]. The QVT specification defines the abstract syn-
tax (using MOF metamodels), concrete syntax (using EBNF and examples) and se-
57
2. Model-Driven Development
mantics (using natural language andRelationsto Coremapping). Among all the three
languages, QVT Relations is the most abstract and user-friendly [115].
These three languages are arranged in a layered architecture shown in Fig.2.8.
They form a hybrid transformation approach: Relations and Core are declarative lan-
guages at two different levels of abstraction, with a normative mapping between them.
The Operational Mapping language is an imperative language that provides constructs
commonly found in imperative languages (loops, conditions, etc.) [134]. Furthermore,
programs written in other programming languages may offer a ”MOF operation” that
can be plugged-in as black-box implementations, because their actual codes is not ac-
cessible or visible from the QVT side.
QVT Relations (QVT-R)
QVT Relations (QVT-R) is a high-level, user-friendly declarative transformation lan-
guage. It has both textual and graphical notations; the latter provides a concise, in-
tuitive and yet powerful way to specify transformations. In this language, a model
transformation is defined as a set of relations. A relation specifies a set of domains -
one domain for each participating model, relating to each other. Optionally, a relation
can have awhenclause that specifies conditions under which the relationship needs to
hold, and awhereclause that specifies conditions that must be satisfied by the model
elements that are being related.
A domain is defined by a pattern, which can be viewed as an object diagram of
object nodes, their properties and links originating from a metamodel. In addition to
the normal object diagrams, free variables can be used to indicate object identifiers and
values of attributes. The same variable can occur in domain patterns and both thewhen,
whereclauses, and refers at all occurrences to the same value [116]. A domain pattern
can be considered a template for objects and their properties that must be located,
modified, or created in a candidate model to satisfy the relation. Detail syntaxes and
semantics of QVT relational language will be discussed later in Section4.2.1.
58
2.5. Model Transformations and QVT
The following transformation scenarios are supported by thecheck-before-enforce
semantics of QVT-R, which ensures the target model elements that satisfy the relations
are not modified.
1. Check-only transformations: The execution of the transformation only checks
if given models satisfy the relations specified in the transformation. No models
are modified or newly created.
2. Bidirectional transformations: When this kind of transformation is defined, no
execution direction is assumed. When it is executed, one model is selected as the
target, and the transformation runs in this direction. This puts some requirements
on the definition of a transformation, that is: given a source model, it must return
the unique target model which is correctly related to the source, and vice versa.
3. Model synchronization: Supported by the bidirectional transformation, the ex-
isting elements of the target model can be updated or deleted if the relations are
not satisfied. Meanwhile, changes manually made on the target model can also
be propagated back to the source model. This scenario is motivated by the need
for handling model updates in an incremental fashion.
4. In-place transformations: Both source and target models are bound to the same
metamodel at runtime. Actually, there is only one model that may be changed
in this scenario. Normally just a small part of the model will be touched by the
transformation, and most part of the model remains unchanged.
QVT Core
QVT Core is a simple, low-level declarative language. It is just as expressive as QVT-
R, but transformation definitions written in it tend to be longer. A transformation in
Core is a set of mappings that roughly correspond to relations in QVT-R. The concepts
of enforced and check domains are also available. It supports pattern matching over
59
2. Model-Driven Development
a set of variables, where the variables of source, target and trace models are treated
symmetrically. In QVT Core, trace models must be defined explicitly. In contrast,
Relations Language implicitly creates trace classes and objects to record what occurred
during a transformation. The semantics of the Core language can be defined more
simply and formally. Thus, in the QVT specification, the semantics of the QVT-R is
given as a transformation to the Core.
Operational Mappings
QVT Operational Mappings is an imperative transformation language which extends
QVT-R with imperative constructs commonly found in imperative languages (loops,
conditions, etc.). It provides OCL extensions with side effects that allow defining a
transformation in a more procedural style. Transformations are always unidirectional.
The basic idea in this language is that the object patterns specified in the relations are
instantiated by using imperative constructs. In that way a declarative transformation is
imperatively implemented.
A transformation in Operational Mappings consists of a set ofmappingsand helper
operations. A mapping calledmainservers as an entry point for transformation execu-
tion. From themain, other mappings can be invoked.
This language is motivated by the problem that sometimes it is difficult to provide
a complete declarative solution to a complex transformation. Thus QVT Operational
Mapping can be used to complement relational transformations with imperative oper-
ations, or define the whole transformations using a completely imperative approach.
2.6 Component-Based Development (CBD)
Component-based development (CBD) aims at the development of cost-effective and
sound software systems, which build on reusable components. Components are sup-
posed to be off-the-shelf products delivered by third-parties, or at least developed inde-
60
2.6. Component-Based Development (CBD)
pendently. CBD promises to increase software quality and productivity, as it is based
on well-tested, mature and reliable components, reduces the efforts to design, develop
a system from scratch, and simplifies the maintenance and evolution by substitution
(and adaption) of components. For that purpose, components from different vendors
have to interact seamlessly. Therefore, it is important to develop components as en-
capsulated blocks that are equipped with a precise description of their static structures
as well as their dynamic behaviors, and have a framework to achieve reusability by
composing systems out of the prefabricated component.
The component description and composition framework must be specified at an
appropriate abstraction level to avoid too much implementation detail but with enough
knowledge to judge appropriateness for use in given systems. This can be achieved
by model-driven techniques – defining component models. In general, a component
model contains at least the following information that is necessary to fully understand
and use the components :
• Component definition: provides structural, functional and behavioral specifica-
tion of the component;
• Composition standard: The key to CBD is composition. It must be clearly de-
fined how and when the components are connected together (the design-time and
run-time infrastructure);
• Run-time interaction protocol: defines how data are exchanged and what hap-
pens to the flow of control within connected components when the system is
running.
Examples of the component model includeCOM (Component Object Model),
DCOM, CORBA, CCM, EJB and .NET. Each of them has its distinct syntax and se-
mantics which may render them incompatible with other component models. More-
over, frameworks, e.g. Fractal [29] or SOFA [32], provide more theoretical component
61
2. Model-Driven Development
models. In the following, we mainly discuss the UML component model [135]. It sup-
ports the specification of both logical components (e.g., business components, process
components) and physical components (e.g., EJB components, CORBA components,
COM+ and .NET components, WSDL components, etc.),
2.6.1 Component definition
In UML, a component can always be considered as an autonomous unit within a sys-
tem. A component represents a module of a system that encapsulates its contents and
whose manifestation is replaceable within its environment, and its behavior is defined
in terms of provided and required interfaces. As a sub-class of UMLclass, a com-
ponent may have its ownoperations, properties, as well asports that represent the
connection points of the component. Its internals are hidden and inaccessible. At run-
ning time, software artifacts thatrealize the component are used in the application,
instead of the component.
2.6.1.1 Interfaces
Components are characterized by theirinterfaces, which specify their possible inter-
action with the environment and offer the points of interaction for components. An
interface declares a set of public features and obligations that define acontract; any
instance of a classifier that realizes the interface must fulfill that contract. Due to the
descriptive nature of an interface, it does not specify how it is to be implemented, but
merely what needs to be supported by realizing instances.
Depending on the role of interfaces in a component, two kinds of them have to be
distinguished:
• Provided interface: The provided interfaces specify how a component can be
used and summarize what it offers to its environment. They are the interfaces
realized by the component.
62
2.6. Component-Based Development (CBD)
• Required interface: Besides the provided interfaces, a component can specify
what services the environment should provide in order for the component to be
able to perform its functionality. These services are explicated by the required
interfaces.
The public features of a component describe the structural aspect of the component.
They are represented as a set ofoperationsthat represent the services offered by the
interface, and a set of accessible data elements – itsproperties. Operations are uniquely
specified by their signature, a tuple consisting of the operation’s name and an ordered
list of parameters. And a property is specified as a tuple containing the name and data
type of the property. Properties owned by interfaces are abstract and only imply that
the implementing classifier should maintain the information with corresponding type
and multiplicity of the property.
On the other side, obligations of the interface contract can be specified by various
techniques, including invariants, pre- and post-conditions of the services offered/re-
quired by the interfaces, different kinds of logics, automata-like specifications, etc.
Moreover they can be defined at various levels of abstraction and can address various
needs.
In the normal case, each operation of the interface is provided with a functional
specification that describes the externally visible effects of the operation. The func-
tional specification comprises of a pair of pre- and post-conditions written in OCL.
The pre-conditions for an operation define conditions that must be true when the op-
eration is invoked, and the post-conditions define conditions that will be true when
the invocation of the operation completes successfully. Both conditions describe what
the operation does, and not how it does it. They typically comprise constraints on the
inputs and output of the operation, as well as the states before and after the operation
invocation. An implementation of this operation will satisfy the conditions.
In addition, we define the dynamic behavior of an interface as the allowed invo-
63
2. Model-Driven Development
cation sequences on operations of the interface. The behavior can be specified with
a UML protocol state machine attached to the interface. The protocol state machine
presents the possible and permitted transitions on the states of the interface or its own-
ing component, together with the operations that carry out the transitions. Here a state
is a particular configuration of the data values of properties of the component and the
interface. Thus the protocol state machine allows definition of a precise external view
by making dynamic constraints on the sequence of operation calls explicit.
However, since both the functional specifications and the protocol state machine
describe the behavior of same interface, they are required to be compatible. That is,
there should not be conflicts between the two specifications.
2.6.1.2 Ports
Port represents a distinct interaction point between a component and its environment
or between that component and its internal parts. Ports can support unidirectional
communication or bi-directional communication. Interfaces can directly attach to a
component, or to a port of the component. In the latter case, a message arriving at the
interface will first be forwarded to the port, and then be handled either directly by the
component itself or by forwarding it to a part of the component’s internal structure.
The results are also returned through the port. Thus ports provide a way to fully isolate
internals of the component. Both the provided and required interfaces can connect to
ports.
2.6.2 Component composition
The key to CBD is composition. Systems are developed by composition of components
usingconnectors, resulting in what is called a composite component. It in turn can be
encapsulated within a component that can again be used for composition with other
components and connectors.
64
2.6. Component-Based Development (CBD)
UML provides various ways to express component composition:
• Assembly connector: An assembly connector is a connector between provisions
and requirements of components. It simply connects a provided interface of
one component to a required interface of another component. Assembly con-
nectors are often use to interconnect components at the same hierarchical level
and having the same parent, and consequently form a flat composition of these
components. The connection is established if the corresponding required and
provided interfaces matches. That is, all operations in the required interface are
a subset of the operations in the provided interface.
• Delegation connector: A delegation connector connects provisions to provisions
of components, or requirements to requirements. It is often used to link a pro-
vided or required interface of a subcomponent to a port of its owning compo-
nent. Thus an external part of a component can communicates with its internal
realization, and messages travel along the connector originating in a required
interface and delivered finally to a provided interface. The interfaces provided
and required must be compatible. Delegation connectors form a hierarchical
composition of components.
In addition, thedependencyrelationships can be used to compose components.
A dependency signifies a supplier/client relationship between model elements where
the client model elements requires other supplier elements for their specification or
implementation. In particular, UMLusage, a special kind of dependency relationship,
can be used to connect provisions and requirements of components, instead of the
assembly connector.
2.6.3 Component diagram
In UML, component diagrams intuitively show the structure of a component model
at different detail levels. A component diagram depicts how components are wired
65
2. Model-Driven Development
together to form larger components or software systems. It illustrates the architectures
of the software components and the dependencies between them. System designers
and developers find the component diagram useful, because it provides them with a
high-level, architectural view of the system that they are building.
The following artifacts are typically drawn in a component diagram: component,
interface, port, connector and usage dependency. In the diagram, a component is shown
as a rectangle with a keyword«component». Optionally, in the right hand corner a
component icon can be displayed. A component icon is a rectangle with two smaller
rectangles jutting out from the left-hand side. As a component has not only an exter-
nal view (or black-box view), but also has an internal view (white-box view) via its
private properties and operations, the information may be displayed in an additional
compartment. Moreover, the internal structure of a component can also be shown in a
compartment, or using a separate component diagram.
Usually, a provided interface is denoted as a ball, while a required interface is
denoted as socket. An interface is labeled with the name, and attached by a solid line
to the component. Although this notation is quite intuitive to read, less information,
especially the interfaces’s operations and properties, is visible. Optionally, interfaces
may be shown using a rectangle as classes. An assembly connector can be notated
as the ball of the provided interface plugging to the socket of the required interface,
or using a dashed line to link these two interfaces. Ports are shown as small squares
on border of a component. A delegation connector is drawn as an arrow from the
delegating port/interface to the handling interface/port.
2.6.4 Component interaction protocol
Components can communicate with each other only by passing messages, which rep-
resent operation calls in general. As discussed previously, a component interacts with
its environment to complete its functionality, and its interaction behavior with the en-
66
2.6. Component-Based Development (CBD)
vironment is captured by a protocol state machine, which explicitly states the order of
sending and receiving messages. However, a component-based system or a composite
component realizes its functionality by a set of nested components, which coordinate
and synchronize with each other by passing messages. That is, a request for an opera-
tion in a component’s provided interface may require invoking one or more operations
in its required interfaces, and further lead to the invocations of the operations of other
components.
For these components to work correctly, they should exchange messages in the
right order. Component sequence diagrams, in which each lifeline represents a com-
ponent, can be used to specify the interactions among the group of components. If
a protocol state machine defines the behavior of a single interface, a component se-
quence diagram defines the behavior of a set of related components connected by
their interfaces. In generally, a component sequence diagram works based on therun-
to-completionsemantics. That is, a requester component invokes an operation of a
provider component and waits for the results, before the requester can starts the exe-
cution of next step.
2.6.5 Component-based development process
CBD often adopts a mixture of top-down and bottom-up development approaches.
Requirements should initially be captured and processed to construct an appropriate
system architecture. That is followed by a phase of search for existing components
that might be reusable for the given system. If such components indeed exist, they
are integrated into the existing architecture as subcomponents through composition or
assembling. According to component availability, initial requirements might be modi-
fied, as the CBD aims at reuse of existing components for faster system development.
It is unlikely that all required components are already available, more likely the exist-
ing components need to be adapted, and new components also needs to be developed.
67
2. Model-Driven Development
After that, the final set of components is validated, composed, and deployed. The
maintenance of the system is carried by substitution of existing components.
The whole CSD process is characterized by the following steps:
1. Requirements analysis and system architecture design;
2. Search for and identification usable components;
3. Selection and adaption components; modifying initial requirements;
4. Developing missing components;
5. Validating, composing and deploying components to construct the system;
6. Maintaining system by replacing components.
68
Chapter 3
Refinement for Component and
Object Systems – rCOS
The research on therefinement of Components and Object Systems(rCOS) develops
a model-driven development method that combines object-oriented and component-
based design and analysis techniques. The rCOS method consists of two parts:
• The rCOS language: Founded on a formal semantics theory, the language pro-
vides a multi-view modeling notation with a verification andrefinement calcu-
lus [39; 82]. It defines concepts and artifacts in the domain of object-oriented
and component-based software engineering, likeclasses, objects, components,
interfaces, contractsand composition, etc. The semantic theory provides the
behavioral semantics of these concepts with high level rules for refinement and
verification; and,
• The rCOS development methodology: It prescribes an integrated, use-case based
and model-driven software development process, from requirements elicitation,
object-oriented design, logical component-based architecture design, through to
coding. Models in later developing phases are constructed from those in earlier
phases by correctness preserving model transformations based on the rCOSre-
finement calculus. Within the process, the formal techniques of modeling, analy-
sis, design, verification and model transformation can be applied, supplemented
with tool support.
The rCOS has been well studied [38; 39; 82; 97; 112; 181]. In this chapter, we give
an overview of rCOS, showing how the key concepts and artifacts of object-oriented
and component-based software engineering are formalized in the notation. It provides
69
3. rCOS
a theoretical foundation for designing and implementing the transformations for rCOS.
The discussion of this chapter is based on the above literature, and similar descriptions
have sometimes been extracted from them without explicitly citing the source.
The rest of this chapter is organized as follows. First we introduce the theoretical
background of rCOS - theUnifying Theories of Programming(UTP) in Section3.1.
In Section3.2, we discuss the object-oriented part of rCOS, its syntax, semantics and
refinement rules. Section3.3describes the component-based parts of rCOS, and Sec-
tion 3.4 presents the rCOS development process. Finally, we briefly introduce the
existing tool supports for rCOS in Section3.5.
3.1 UTP - Background of rCOS
The rCOS method is equipped with a denotational semantics defined in Hoare and He’s
Unifying Theories of Programming(UTP) [86] with extension of object-oriented and
component features, and, derived from the semantics, a set of refinement rules.
UTP presents a unified model of a number of programming idioms, such as im-
perative, nondeterministic, concurrent, reactive, higher-order, etc. Theories in UTP
are predicates over a pre-defined collection of free observation variables, which are
referred to as thealphabetof the theory, and are generally used to describe a relation
between a before-state and an after-state, the latter typically indicated by primed ver-
sions of the observation variables [67]. In UTP, there is only one domain of discourse,
rather than separate domains of syntax and semantics, and a mapping between them.
Thus programming notations like sequencing and choice are defined as operations on
predicates like composition and disjunction. The result is a simple and streamlined
framework for reasoning about programs, without the clumsiness and noise imposed
by ubiquitous semantic brackets [69].
In UTP, we denote the alphabet of a programP asαP , or simplyα when there
is no confusion. A variable inα may take different values, but from the same value
70
3.1. UTP - Background of rCOS
space called thetypeof the variable. Given an alphabetα, astateof α is a well-typed
mapping fromα to the value spaces of the variables, denoted asσ. We useS to denote
the set of all states of programP . Note that state variables include both variables used
in programs and auxiliary variables needed for defining semantics and properties of
programs.
For a sequential programP , given initial values for its variables (that form aninitial
state), the execution ofP will change them into some possible final values, called the
final stateof the program, if the execution terminates. We use abooleanvariableok
to denote whether a program is started properly and its primedversionok′ to represent
whether the execution has terminated. We define astate predicateas a predicate that
selects a subset of the statesS . For example,x > y + 1 defines the set of statesσ
such thatσ(x) > σ(y) + 1 holds. We say that a stateσ satisfies a predicateF , denoted
by σ |= F , if it is in the set defined byF .
A state relationR is a relation over the statesS as a subset of the Cartesian product
S × S . It can be specified by a predicate over the state variables and their primed
versions. We say that a pair of states(σ, σ′) satisfies a relationR(x1, ..., xk, y′1, ..., y′n) if
the following expression hold, denoted as(σ, σ′) |= R
R(σ(x1)/x1, ..., σ(xk)/xk, σ(y′1)/y′1, ..., σ(y′n)/y′n)
where the notation[e1/x1, ..., en/xn] denotes simultaneous substitution of theei, i ∈ 1...n
for any free occurrence of the correspondingxi.
A relational predicate specifies a set of possible state changes. For example,x′ ≥ x + 1
defines the possible changes from an initial state to a state inwhich x has a value not
less than the initial value plus1. Thus, state predicateF can also be interpreted as
a relational predicate such thatF holds for(σ, σ′) if σ satisfiesF . Note that a state
predicate and a relational predicate only constrain the values of variables that occur in
them, leaving the other variables to take values freely.
71
3. rCOS
3.1.1 Programs as designs
A semantic model of programs is defined based on the way we observe the execution of
programs. For an execution of a sequential program, we are interested in observing the
values of the initial state and the final states. That is, the relation between the starting
states and the final states of a terminating program execution.
Definition 1 (Design) Given an alphabetα of a programP , a state predicatep and
a relational predicateR over α, a program designis defined asD = (α, p ⊢ R), and
we definep ⊢ R , ok∧ p ⇒ ok’ ∧ R, whereok, ok’ ∈ α describe the initiation and ter-
mination of the program, respectively. The design specifies a program that starts from
a proper initial stateσ (ok=true) satisfyingp and properly terminates in a stateσ′
(ok’=true) such that(σ, σ′) |= R.
We callp thepreconditionandR thepostconditionof the design. When the alphabet
is known, we simply denote the design byp ⊢ R. In Fig. 3.1, we define the basic op-
erations on designs over the same alphabetα, whereb is a boolean expression that is a
predicate whose free variables are all unprimed, and we defineskip , true ⊢∧
x∈α(x′ = x)
that represents a program which terminates successfully, leaving all the variables un-
changed. Also we havechaos , false ⊢ true as the worst program which behavior is
unpredictably.
x := e , true ⊢ x′ = e∨
y∈α,y 6=x y′ = y assignment
D1; D2 , ∃x0 · D1[x0/x′] ∧ D2[x0/x] sequential composition
D1 ⊳ b ⊲ D2 , b ∧ D1 ∨ ¬b ∧ D2 conditional choice
D1 ⊓ D2 , D1 ∨ D2 non-deterministic choice
b ∗ D , (D; b ∗ D) ⊳ b ⊲ skip iteration
Figure 3.1: Basic operations of UTP
It is proved in [86] that the notion of designs is closed under these operations.That
is, the result of an operation is equivalent to a design of the formp ⊢ R. This ensures
72
3.1. UTP - Background of rCOS
the soundness of the semantic model.
3.1.2 Refinement of designs
In MDD, system modeling follows an incremental approach: starting from a high-
level description, a model is incrementally obtained by adding more details. The idea
of refinement, well known in the framework of formal methods, gives the approach
a precise underpinning. It allows models to become more concrete while preserving
properties that have been verified in higher-level models.
In UTP, the refinement relation between designs is defined to be logic implication.
Definition 2 (Refinement) A designDl = (α, pl ⊢ Rl) is a refinement of a design
Dh = (α, ph ⊢ Rh), denoted asDh ⊑ Dl, if ∀x, x′ · ((pl ⇒ Rl) ⇒ (ph ⇒ Rh)) hold, where
x andx′ represents all the state variables and their primed versions inDl andDh.
The refinement relation forms acomplete partial order(CPO) for the set of designsD .
It ensures that any property satisfied by the ”higher level” designDh is preserved (or
satisfied) by the ”lower level” designDl. The refinement relation can be proved using
the following theorem:
Theorem 1 Dh ⊑ Dl when
1. weakening the precondition:ph ⊢ pl , and
2. strengthening the postcondition:pl ∧ Rl ⊢ Rh.
For a designp ⊢ R, we define its weakest precondition for a given state predicate r:
wp(p ⊢ R, r) , p ∧ ¬ (R;¬ r)
The refinement relation is preserved by sequential composition, conditional choice and
non-deterministic choice. That is, ifDh ⊑ Dl then for anyD, we have
• D;Dh ⊑ D;Dl
73
3. rCOS
• Dh;D ⊑ Dl;D
• Dh ⊳ b ⊲ D ⊑ Dl ⊳ b ⊲ D
• Dh ⊓ D ⊑ Dl ⊓ D
As (D ,⊑) forms aCPO, a smallest fixed point of the iterationb ∗ D can be calculated
from the bottom elementchaos in (D ,⊑). In addition,D1 and D2 are equivalent,
denoted asD1 = D2 if they refine each other. Thus, we have
• D1 ⊓ D2 = D2 ⊓ D1
• D1 ⊳ b ⊲ D2 = D2 ⊳ ¬b ⊲ D1
• D1 ⊓ D2 = D2 iff D1 ⊑ D2
For the proof of these properties, we refer to [86]. When refining a higher level design
to a lower level design, more program variables may be introduced or types of program
variables may be changed. If the two designs do not have the same alphabet, we can
usedata refinementto relate their state spaces.
Definition 3 (Data refinement) Letρ(αl, αh) be a many to one mapping from the state
space ofαl to the state space ofαh. DesignDl = (αl, pl ⊢ Rl) is a refinement of design
Dh = (αh, ph ⊢ Rh) if there is a design(αh ∪ αl, ρ(αl, α′h))such thatρ;Dh ⊑ Dl; ρ. We
call ρ a data refinement mapping.
The relation⊑ is fundamental for the development of the refinement calculusto support
correct by design in program development, as well as for defining the semantics of
programs.
3.1.3 Reactive designs
A service provided by aconcurrentor reactiveprogram may not always available to
its environment. Because its execution requires resources that might be occupied by
74
3.2. Object-Orientation of rCOS
other processes or requires synchronization with other processes, a service will usually
engage in alternative periods of computation and periods of stability, while it iswaiting
for interaction from its environment. Then the execution is suspended in a waiting
state. We therefore introduce abooleanstate variablewait to allow the observation of
the waiting state, and we define a mappingH on designs such that
H (D) , wait′ ⊳ wait ⊲ D
meaning that execution does not proceed in a waiting state, where it leaves the state
unchanged. A designP is a reactive designif it is a fixed point of the mappingH ,
H (D) = D, that is
H (p ⊢ R) , (wait ∨ p) ⊢ wait′ ⊳ wait ⊲ R
The domain of reactive designs enjoys the same closure properties as that of sequential
designs, and refinement is defined as logical implication also.
We use aguarded designg & D to specify the designD ⊳ g ⊲ true ⊢ wait′, where
D is a design andg is a state predicate. This guarded design specifies that if theguard
conditiong holds the execution of design proceeds from the non-waiting state and the
execution is suspended otherwise. It is easy to prove that a guarded design is a reactive
design. The semantics of a reactive design ensures that a synchronization of a method
invocation by the environment and the execution of the method can only occur when
theguard is true andwait is false.
3.2 Object-Orientation of rCOS
Most, if not all, of the current component-based design and implementation techniques
rely heavily on object-oriented techniques. The rCOS provides a rich variety of object-
oriented features including subtypes, reference types, visibility, inheritance, dynamic
binding, polymorphism and local variable nested declarations. To allow the use of OO
design and programming for component-based software development, rCOS extends
the theory of designs in UTP to a theory of OO designs.
75
3. rCOS
3.2.1 Syntax of rCOS
prog ::= cdecls • Main programcdecls ::= cdecl | cdecl ; cdecls class declarationscdecl ::= [private] class C class declaration
[extends D] { ~adecl ; ~mdecl }adecl ::= visib T a = cn attribute declarationvisib ::= private | protected | public visibility
mdecl ::= visib m(~T ~x; ~T ~y){c} method declaration
c ::= commandskip | chaos
| C.new(le) object creation| ~le := ~e assignment| var T x [= e] variable declaration| end x variable undeclaration| e.m(~e; ~le) method invocation| c; c command sequencing| g & c guarded command| c ⊳ b ⊲ c conditional choice| c ⊓ c non-deterministic choice| b ∗ c iteration| pre ⊢ post design
e ::= expressionle | this | cn
| (C)e type cast
p ::= predicateb | ∃ ~le · p | ∀ ~le · p
le ::= l-expressionx
| e.a object attributeMain ::= ( ~ext ; c) main method definition
ext ::= T x = cn external variable declaration
Figure 3.2: Syntax of rCOS OO language (RCOSP)
An rCOS program is specified in a textual language, calledRCOSP. The syntax
of its OO part includes object systems (programs), class declarations, commands and
expressions. A subset of the syntax is defined in Fig.3.2. HereC denotes the set of
class names andT is the names of types defined in the object system as a union ofC
and primitive data typesB, such asInteger, BooleanandString, and collection types
76
3.2. Object-Orientation of rCOS
S, such asSet, Bag. That is,T = C ∪ B ∪ S. Furthermore,m is a method name,a is a
field (or attribute) name,e is an expression andb a boolean expression;cn is a constant
literal (a constant of primitive data type or the null reference),x andy are variables,
andg, pre andpostarepredicates. Any text occurring in a pair of square brackets is
optional, and text with an arrow above denotes a sequence of elements, for example~u
representsu1, u2, ..., uk.
Class declarations Similar to Java, an OO programprog in rCOS consists of a list
of class declarationscdecls and a main methodMain. Each class incdecls is declared
with a distinct name. It may own someattributesandmethods, and can declare at
most one direct superclass denoted by the ”extends” keyword. So, there is no multiple
inheritance. We useC1 ≺ C2 to denote thatC2 is the superclass ofC1, andC1 � C2 if
C1 ≺ C2 or C1 = C2.
An attribute (or field) is declared with a name, a type and optionally initial val-
ues. The scope of its visibility is defined by the ”private”, ” protected” and ”public”
keywords. A method declarationmdecl has a list of input parameters and output pa-
rameters with their types, and a body commandc. To make sure that expressions have
no side effects, the language allows a method to have result (output) parameters instead
of returning values directly. Methods can be inherited and overridden by subclasses.
The main program bodyMain declares a list of external variables, called thepro-
gram global variables, with their types and initial values, and amain commandc. The
main command can accesses and updates the global variables. The main program can
be viewed as a classMain:
classMain { privatevars; methodmain(){c} }
wherevars is the set of global variable declarations.
Expressions Expressions include assignable expressionsle, which may appear on
the left-hand-side of an assignment, the special variableself that represents the cur-
77
3. rCOS
rently active object, and expressions of type casting(C)e, literalscn, ande.a that de-
notes the attributea of objecte, etc. Note thatb is a boolean expression we are not
concerned with the detailed structure, but simply assume it is of typeBoolean and can
be evaluated to eithertrue or false. In rCOS, evaluation of an expression does not
change the system state. Similarly we havepredicatesthat can also be evaluated to a
Boolean value. A predicate could be a boolean expression, an existential quantification
∃ ~le or a universal quantification∀ ~le.
Commands The data functionality of a method is specified by a command. It can
be simplyskip, that does not do anything, orchaos, the worst program whose behavior
is unpredictable. TheC.new(le) command creates an object of classC and attaches
it to a referencele, while the fields of the object are initialized with the initial values
declared inC. Theassignmentcommand assigns a sequence of variables (or fields of
objects) with a sequence (of the same length) of values. A variable and its scope can be
declared using thevariable declaration. Commande.m(~e; ~le) calls the methodmof the
objecte with a set of actual value parameters~e and actual result parameters~le. As de-
fined in UTP, commandsc; c, c ⊳ b ⊲ c, c ⊓ c andb ∗ c represent sequential composition,
conditional choice, non-deterministic choice and iteration, respectively.
In rCOS, the body of a method can also be specified as a UTP design :pre ⊢ post,
where the pair of predicates represents thepreconditionand thepostconditionof the
design. It means that when methodm is invoked, if the input parameters and the
current state of the program satisfy the precondition, the execution of the invocation
will terminate and the final state satisfies the postcondition. In order to support current
and reactive programming, we introduce theguarded designs. Given a design and
a predicateg over the state variables, we callg & (pre ⊢ post) a guarded design. It
specifies that if the guard conditiong holds the execution of design proceeds from non-
waiting state, otherwise the execution is suspended. Similarly, rCOS has the guarded
commandg & c, where the commandc defines the data functionality without guard
78
3.2. Object-Orientation of rCOS
conditions.
Example Consider an example of a currency converter. It is defined in rCOS as:
program CurrencyConverter {
...
class CurConv {
public double rate;
public setRate (double val ) {
[⊢ rate’ = val] }
public convert (double amount; double result ) {
[⊢ result’ = amount∗ rate] }
public convertInverse (double amount; double result ) {
[rate > 0⊢ result’ = amount / rate] }
}
class Main {
...
method main() {...}
}
}
3.2.2 Semantics of rCOS
Objects, types and states An OO program operates not only on variables of primi-
tive types, but also on objects of reference types (classes). The class declaration section
cdecls of a program defines thetypes(value space) as well as thestatic structureof the
program. We assume an infinite setREF of object identities (or references), with
null ∈ REF . Let B denote the set of built-in primitive types. We define avalue as
either a member of a primitive type inB or an object identity inREF with its run-time
type in the set of class namesCNAME . Let VAL be the set of values
VAL ,⋃
B ∪ (REF × CNAME)
79
3. rCOS
For a valuev = <r,C> ∈ REF × CNAME , we useref (v) to denoter and type(v) to
denoteC.
An object has anidentity, astateand abehavior. Thus, we define an objecto by a
triple o , <r,C, σ>, where
• r is the identity ofo, denoted byref (o), r ∈ REF ,
• C is the runtime type ofo, denoted bytype(o), C ∈ CNAME ,
• σ is called the state ofo, denoted bystate(o). It is a mapping that maps each
attributea of C to a valuev in VAL, that is, eitherv ∈ B being a primitive type,
or v ∈ REF × CNAME referring to an object. We useo.a to denoteσ(a).
Therefore, an object can have a recursive structure, which may contain or refer to other
objects.
States of programs Given an OO programP = cdecls • Main, a global state ofP is
defined as a mappingΓ from the external variables to their value spaces. Taking the
Main as a class:
classMain { privatevars ; methodmain(){c} }
The state ofP is thus the state of an object of classMain and thenΓ can be defined as
Γ : vars → B ∪ (REF × CNAME)
that assigns each variablex ∈ vars a value of object or primitive types depending on
the type ofx. During the execution of the main method, the identity of an object rep-
resenting the state will never be changed, but its value will be modified in each step
of the execution. Global states are enough for defining a UTP-based denotational se-
mantics and a ”big step semantics” of the program in which executions of intermediate
execution steps and the changes of locally declared variables are hidden.
Evaluation of expressions The evaluation of an expressione under a given state
determines its typetype(e) and its valuevalue(e) that is a member oftype(e). The
80
3.2. Object-Orientation of rCOS
evaluation makes use of the configuration of the system global variables. An expres-
sion e can only be evaluated under the condition that it is well defined, denoted as
D(e).
Semantics of commands An important aspect of an execution of an object-oriented
program is the attachment of objects to program variables. An attachment is made by
an assignment, the creation of an object or by passing a parameter in a method invoca-
tion. With the approach of UTP, these different cases are unified as an assignment of a
value to a program variable. The semantics[[c]] of each commandc has its well-defined
conditionD(c) as part of its precondition and thus has the formD(c) ⇒ (p ⊢ R)
• Assignments: An assignmentle := e is well defined if bothle ande are well
defined and the current type ofe matches the declared type ofle.
D(le := e) , D(le) ∧ D(e) ∧ type(e) ∈ CNAME ⇒ type(e) � type(le)
There are two cases of assignment:
– Assign a value to a variablex := e. This can be done when the type of the
object is consistent with the declared type of the variable.
[[x := e]] , D(x := e) ⊢ (x′ = value(e))
The attachment of values to other variables is not changed. Aswe do not al-
low attribute hiding or redefinition in subclasses, an assignment to a simple
variable does not have side-effects.
– Assign a value to an attribute of an object attached to a l-expressionle.a := e.
This is done by finding the attached object in the system objects and mod-
ifying its state accordingly. All variables attached to the reference of this
object are updated:
• Object creation: The commandC.new (le) creates a new object of typeC, sets
all the initial values of the attributes of the object, and attaches the object tole.
81
3. rCOS
The command is well defined if
D(C.new(le)) , C ∈ CNAME ∧ D(le) ∧ C � type(le)
• Method invocation: For a method signaturem(T1 x; T2 y), the command of
method invocatione.m(ve; re) first locates the objecto thate refers to, assigns
the values of the actual parametersve andre to the formal value and result pa-
rameters (x andy, respectively) of the methodm of objecto, and then executes
the body ofm under the environment of the class owning the method. Before
termination, the value of the result parameterre is passed back to the actual
parametery.
All other commands, such as conditional choice, non-deterministic choice and iter-
ative statements, can be defined inductively in the same way as in the UTP sequential
language.
3.2.3 Object-oriented refinements of rCOS
The rCOS refinement calculus supports object-oriented refinements at three levels :
refinement between whole programs (object systems), refinement between class dec-
larations (structure refinement), and refinement between commands. The refinement
calculus includes a set of algebraic laws expressed as equations of OO programs un-
der the UTP semantics [82], and a set of rules of graph transformations under the
graph semantics [181]. Model refactoring and design patterns are supported by these
rules/laws, and their soundness and relative completeness have been proven.
Refinement of commands The refinement relation between commands takes exactly
the same view as the UTP sequential programs that the execution of a command is a
relation between states. A commandcl is a refinement of a commandch, denoted
by ch ⊑ cl , if for any given initial stateσ, any possible final stateσ′ of cl is also a
82
3.2. Object-Orientation of rCOS
possible final state ofch. Thus a refined command is not more non-deterministic than
the original command.
Refinement of programs Refinement between commands in OO programming only
makes sense under the context of a given list of class declarationscdecls. Let Pl =
cdeclsl • Main l andPh = cdeclsh • Mainh be two object programs which have the same
external variables~ext . Pl is a refinement ofPh, denoted byPh ⊑ Pl, if the following
implication holds:
∀ ~ext , ~ext′, ok , ok ′ · ([[Pl]] ⇒ [[Ph]])
In such a refinement, all non-public attributes of objects aretreated as local (or
internal) variables.
Structure refinement An essential advantage of OO programming is that classes
can be reused in different applications and thus support differentMain programs. The
classes of an application program are in fact the metamodel of the structure or organi-
zation of the application domain in terms of concepts, objects and their relations and
behavior. When the main methods in the programs are syntactically identical, the rela-
tion between their system states is determined by the relation between the structure of
these programs, i.e. their class names, attributes, sub-superclass relations, and methods
in the classes. The structure refinement in rCOS characterizes this fundamental feature
of OO programming.
Definition 4 (Structure refinement) Class declarationscdecls l is a refinement ofcdeclsh,
denoted ascdeclsh ⊑ cdecls l, if the latter can replace the former in any object system:
cdeclsh ⊑ cdecls l , ∀Main · (cdeclsh • Main ⊑ cdecls l • Main)
That means thecdecls l supports at least as many services ascdeclsh. Thus a refined list
of class declarations has capacity for providing more and better services, and supports
all functionalities that the class structurecdeclsh supports.
83
3. rCOS
The notion of structural refinement is actually an extension to the notion of data
refinement. The rCOS refinement calculus gives a full formalization of OO program
refactoring by a group of simple transformation rules, referred as ”small-step” rules,
which includeadding classes, attributes, methods, decomposition and composition of
classes, promoting methods from subclasses to super classes, from private to protected
and then to public, etc. The transformation rules are proved to be sound and relatively
complete in the sense that the rules allow us to transform the class declarations of a
program to a tree of inheritance, and with the derived transformation rules on the main
method, the program can be refined to an equivalent program that only has the main
class. Thus each OO program can be transformed to an equivalent procedural program.
OO refinements in rCOS can also be divided into three kinds:functionality delega-
tion, attribute encapsulation, andclass decomposition.
Functionality delegation It also referred asexpert pattern, which assigns a respon-
sibility to an information expert, the class that has information necessary to fulfill the
functionality. Usually, the functionality specification of method makes use of naviga-
tion paths through the class model. That is, expressions in the specification traverse
the associations (or attributes), starting from the class of the current object. According
to object-oriented design principles, a method should not use navigation paths to di-
rectly manipulate elements “owned” by other classes. This would make classes tightly
coupled: a modification in one class may require subsequent changes in other classes.
Encapsulating behavior in the expert classes alleviates this, and reduces the number of
necessary followup changes through the model.
Assume thatC andC1 are classes incdecls , C1 o is an attribute ofC andT x is an
attribute of C1. Let m(){c(o.x, o.x′)} be a method ofC that directly accesses and/or
modifies attributex of C1. We can refine the program by changing methodm() to
m(){o.n()} and add a fresh methodn(){c(x/o.x, x′/o.x′)} to classC1, while make sure
that other variables in commandc are accessible inC1,
84
3.3. Component Model of rCOS
Attribute encapsulation Suppose an attributea of classC is only directly referred
to in the methods ofC, this attribute can be madeprivate; and it can be madeprotected
if it is only directly referred in methods ofC and its subclasses.
Class decomposition This is also calledhigh cohesion pattern, which requires that
the responsibilities of a class should be strongly related and focused. To make classes
simple and highly cohesive, we therefore often need to decompose a complex class into
a number of associated classes. For example, assume a classC{T1 a1, T2 a2;m1(){c1(a1)},
m2(){c2(a2)}} that declares two attributesa1, a2, and methodm1() only involvesa1,
and methodm2() only involvesa2, we can decomposeC into two classes: class
C1{T1 a1;m1(){c1(a1)}} that only involves attributea1 and methodm1(), and class
C2{T2 a2;m2(){c2(a2)}} that only involves attributea2 and methodm2(). There are
other rules for class decomposition in rCOS.
The expert pattern and other refinement rules in rCOS are proved to be big-step
refinements, and they are repeatedly used in the design of systems [39]. However, it is
important to note that method invocation, or object interaction, takes time. Therefore,
this object-oriented refinements usually exchanges efficiency for simplicity, ease of
reuse, maintainability, and data encapsulation.
3.3 Component Model of rCOS
An essential concept in rCOS is that of components. A componentK has various
models with different details in different stages and for different purposes. There are
two kinds of components in rCOS,service components(for short,components) and
process components (processes, for short). A component provides services represented
as methods to be called by the environment. On the other hand, processes do not
provide services but make invocations to methods of components following their own
flow of control to coordinate the behavior and pass data among components. Processes
implement business work flows.
85
3. rCOS
Definition 5 (Component) A componentK is a reactive program that can be repre-
sented as a tuple:K , (init , pIF , rIF , iIF , iA,F ), where
• an initial conditioninit defines the allowable initial states of the component;
• pIF, rIF, iIF denote theprovided interface, required interfaceand internal in-
terfaceof the component, respectively. An interface is a set of method signa-
tures of the formm(in; out) with possible input and result parameters. Each
methodm() is given a body that is a guarded command. It is required that
pIF ∩ iIF ∩ rIF = ∅;
• iA is an set of internal autonomous actions. Each actiona is given a body that is
a guarded command. So an action can be seen as a method without parameters.
The execution of an atomic action changes the current state of the program to
another state.
• F is a set of variables, also calledfields.
We useK .init ,K .pIF ,K .rIF ,K .iIF ,K .iA andK .F to denote the corresponding parts
of K.
3.3.1 Close components and refinement
We first considerclosed componentsthat only provide services but do not require ex-
ternal services.
Definition 6 (Closed component)A closed component is a component without re-
quirement interfacesK .rIF = ∅.
As a reactive program, a (closed) componentK repeatedly accepts requests (invo-
cations) from the environment to invoke its enabled services (methods) inK .pIF , or
executes an enabled action inK .iA, until no more methods or actions can be executed.
86
3.3. Component Model of rCOS
Its semantics only concerns the interaction with the environment. Lete be aneventrep-
resenting an invocation of a method defined inK .pIF , and the execution of the method
may need to execute a sequencea1 , ..., an (possibly empty) of actions inK .iA. We
useσe→ σ′ denotean observable transition relationso thatσ e
→ σ1a1→ ...
an→ σ′, where
σ, σi(0 ≤ i ≤ n) are states overK .F ∪ {ok ,wait}.
Definition 7 (Semantics of components)The semantics of componentK is defined
by a pair of sets of failures and divergences[[K ]] , (divergence(K ), failure(K )), where
• divergence(K ) is a set of execution traces over method invocationsm(u; v), where
m() ∈ K .pIF such that there is a sequence of state transitionsσ0e1→ ...
ek→ σk and
σk (ok) = false, hereσ0 is an allowable initial state,σ0 ⊢ K .init ,
• failure(K ) is set of pairs(tr,X), wheretr is a trace andX a set of method
invocations toK .pIF that K may refuse to respond to after engaging all events
in tr.
A component needs an interaction protocol for its client to follow. We define the
provided tracesof componentK as trace(K ) = {tr |(tr , {}) ∈ failure(K )}. Therefore
the set of all its provided traces can be used as theprovided protocol of componentK,
denoted asprotocol(K ).
There is a special kind of components that have no internal actions, i.e.,K .iA = ∅.
They are calledprimitive components. It was proved in rCOS that in general every
closed component is equivalent to a primitive component. That is, the internal actions
from a state can be collapsed into the preceding transitions of the invoking method,
thus the flow of control of the component forms a finite state machine. This implies
that the interface behavior of a component can be modeled in two forms:contractand
publication.
Definition 8 (Contract) A component contractC is a tuple(init , pIF ,F ), in which the
body of each methodm() ∈ C .pIF is defined as a guarded designg & (p ⊢ R).
87
3. rCOS
Definition 9 (Publication) A component publicationB is a tuple(init , pIF , pProt ,F ),
where the body of each methodm() ∈ B .pIF is just a designp ⊢ R of the data func-
tionality andpProt is the provided protocol ofB.
The protocol can be specified in a formal language, such as regular expressions or a
restricted version of process algebra such as CSP without hiding and internal choice. It
can be easily modeled by a state machine for the purpose of model checking. However,
publications are declarative, while contracts are operational. As a closed component
is semantically equivalent to a contract, contract is thus an important notion for the
requirement specification and verification of the correct design and implementation
through refinements.
Components refinement Refinement between two components is judged by com-
paring the services they provide to the environments. A componentKh is refined by
componentKl, denoted asKh ⊑ Kl, if
• Kl offers the same provided methods,Kl .pIF = Kh .pIF
• Kl is not more likely to diverge,divergence(Kl ) ⊆ divergence(Kh), and
• Kl is not more likely to block clients,failure(Kl ) ⊆ failure(Kh).
It is easy to see that ifKh ⊑ Kl, thenprotocol(Kh ) ⊆ protocol(Kl ). Moreover, if bothKh
andKl are primitive components then for allm() ∈ pIFh , we haveguardh(m) = guardl (m)
∧bodyh(m) ⊑ bodyl (m).
3.3.2 Open components and composition
Components often need to use the services provided by another component. That
is, to deliver a servicem() ∈ K .pIF , it can request services from other components.
Moreover, the execution of an internal action inK .iA or a private method inK .iIF
may also request these services. The requests to these services are made through the
88
3.3. Component Model of rCOS
required interfaceK .rIF . A component with a non-empty required interface is called
an open component.
The notion of composition is essential for a component-based design. We can
compose two componentsK1 and K2 in parallel so that a client can use the provided
services of the two components in an interleaving manner.
Definition 10 (Component composition)Let K1 and K2 be two components such
that
K1 .pIF ∩ K2 .pIF = ∅, K1 .iA ∩ K2 .iA = ∅, K1 .F ∩ K2 .F = ∅
(K1 .rIF ∪ K2 .rIF ) ∩ (K1 .iIF ∪ K2 .iIF ) = ∅
We define componentK as the parallel composition ofK1 andK2, denoted byK = K1 ‖ K2,
such that
• K .init = K1 .init ∧K2 .init
• K .F = K1 .F ∪ K2 .F
• K .iA = K1 .iA ∪ K2 .iA
• K .pIF = (K1 .pIF ∪ K2 .pIF ) − (K1 .rIF ∪ K2 .rIF )
• K .rIF = (K1 .rIF ∪ K2 .rIF ) − (K1 .pIF ∪ K2 .pIF )
• K .iIF = K1 .iIF ∪ K2 .iIF ∪ (K1 .rIF ∪K2 .rIF ) ∩ (K1 .pIF ∪ K2 .pIF )
Note that a provided method that offers a service to a requiredmethod of another
component is not serving the environment anymore. However, there are several special
cases for parallel composition.
• Plugging: WhenK1 .rIF ⊆ K2 .pIF andK2 .rIF ∩ K1 .pIF = ∅, we useK1 ≪ K2
to denoteK1 ‖ K2, calledK2 plugging intoK1. Here only the provided interface
of K1 is offered to the client.
89
3. rCOS
• Disjoint union : WhenK1 and K2 have all their interfaces disjoint from each
other, (K1 .rIF ∪ K2 .rIF ) ∩ (K1 .pIF ∪ K2 .pIF ) = ∅, we useK1 ⊕ K2 to denote
K1 ‖ K2, called disjoint union. Here all the provided and required interfaces are
offered to the client in an interleaving way.
Semantics of open component The semantics of an open componentK is defined
by a functional[[K]] : C → C , whereC is a set of closed components. So given a closed
componentK1, [[K]](K1) is defined ifK1 .pIF = K .rIF and it is the closed component
K ≪ K1.
Refinement of open component Let Kh and Kl be two open components,Kh ⊑ Kl
if for all componentK such thatKh ≪ K ⊑ Kl ≪ K. Notice that ifKh ⊑ Kl then
K ≪ Kh ⊑ K ≪ Kl.
To ensure the correctness of component composition, we have to check that an
assembly is possible by checking the composability of the linked interfaces.
Definition 11 (Composability) Two componentsK1 and K2 are composable if there
exists a closed componentK such thatK .pIF = (K1 ‖ K2 ).rIF and the provided pro-
tocol of(K1 ‖ K2 ) ≪ K contains non-empty traces.
In rCOS, some other operators over components have also been defined, such as
renamingandhiding:
• Renaming: Changing the name of methods in interfaces. Renaming the methods
m() in K .pIF to mr(), denoted byK [mr/m], gets a component that has a method
mr (){m()}.
• Hiding: Hiding a method from a provided interface. LetK be a component, and
m() ∈ K .pIF , then the operationK\{m} represents the component after removal
of methodm() from its provided service.
90
3.3. Component Model of rCOS
These operators server asconnectorswhich provide interface adaptation capability.
They can be implemented by simple open components.
3.3.3 Processes and coordination
Components as discussed so far provide a number of methods, but themselves only
passively wait for a client to call their provided services. To implement a desired
functionality, we need active entities that coordinate the behavior of the components,
and pass data and control in and out of components. These active components are
processes.
Different from a service component, a processP only has a required interface
P .rIF , but does not have any provided interface.
Definition 12 (Processes)A process is a tupleP , (init , rIF , iA,F ), where
• init is an initial condition that defines the allowable initial states;
• rIF denotes therequired interface, which consists of a set of guarded method
invocations in the form ofg & m(u; v). We also useP .rIF to denote the set of
method signatures for the guarded method invocations.
• iA is an set of internal autonomous actions.
• F is a set of variables, also calledfields.
A process calls the required methods actively according to its own flow of control.
Similar to a closed component, we define the semantics of process as a pair of failures
and divergences. We also define the set of traces on the events inP .rIF , and the inter-
action protocol ofP is defined as the traces. Moreover, refinement between processes
is defined in the same way as refinement between closed components.
Processes do not interact with each other and the parallel composition of processes
acts likedisjoint unionof components. However, the parallel composition of processes
and components is defined ascoordination composition
91
3. rCOS
Definition 13 (Coordination) Let P be a process andK1 a closed component such
thatK1 .iA ∩ P .iA = ∅, K1 .F ∩ P .F = ∅ andP .rIF ⊆ K1 .pIF . The coordination ofK1
by P is a closed componentK = K1 ⊙ P such that
• K .init = K1 .init ∧ P .init
• K .F = K1 .F ∪ P .F
• K .pIF = K1 .pIF − P .rIF
• K .iA = {guardK1(m) ∧ guardP (m) & body(m)|m ∈ P .rIF ∪ K1 .iA},
whereguardK1(m) andguardP (m) are the guards ofm in K1 andP , respectively,
and body(m) is the body ofm defined inK1.
It is easy to see when a number of components are coordinated by a process, the com-
ponents are not aware of each other, but are controlled by the process, and exchanges
data through the process.
3.4 Development Method of rCOS
To support component-based model driven development, rCOS proposes a use-case
driven, incremental and iterative developing methodology for designers to follow. This
development methodology covers the design process of gathering requirements, spec-
ifying system components, defining system structure, describing overall system be-
haviors, performing the refinement, validation and verification, detailed designing and
coding. Within the process, formal techniques and tools of modeling, design and verifi-
cation can be applied. Models in later development phases are constructed from those
in earlier phases by correctness preserving model transformations based on a well-
studied refinement calculus [82]. One of the main advantages of the rCOS methodol-
ogy is that we can assure consistency of the multi-view specifications [111]. In brief,
92
3.4. Development Method of rCOS
rCOS provides explicit modeling notations and refinement calculus for component-
based model-driven development of software systems. A tool,rCOS modeler[40], has
been developed to support the development process. Fig.3.3 shows the concepts of
rCOS development.
Figure 3.3: rCOS development methodology
The rCOS development process is characterized by the following features:
• Each phase is based on the construction of models;
• Models are validated and verified;
• Refined models are constructed by model transformations;
• Code is generated from design models;
• Proof obligations are generated by model transformations;
• The rCOS modeler integrates UML models into rCOS.
93
3. rCOS
3.4.1 Requirements modeling
The rCOS methodology considers the development of component-based reactive soft-
ware systems from use cases. This corresponds to systems that interact with their
environment through a set of well-defined methods invocations. Data types are given
as either primitive types, or modeled as object-oriented classes with single inheritance.
Naturally the computations of the system are encapsulated within the methods.
Use cases. As the first step, understanding and analysis of the problem domain is
necessary. Based on a textual system description which is more or less complete, each
use case is identified and created separately in the model. Relationships between the
participants (actors) and the use cases, and among use cases, in particular the«include»
relationship, can be documented in the use case diagrams. Usecases group function-
ality, represent specific work flows within the software application, and indicate their
origin in the original system description.
Conceptual class diagrams. Meanwhile, domain concepts and their relationships
are derived from the system description and represented as conceptual class diagrams,
where a class has no methods, and visibility of the attributes are all public. This may
require some interpretation of the description by domain experts. We borrow the term
”conceptual” class diagram from Larman [103] to characterize the class diagram at this
stage.
Interfaces and components. In rCOS, each use case will be realized by a compo-
nent, and the functionalities of the use case are modeled as methods in the provided
interface of the component. The user defines the signature of a method, and the data
functionality of the method is given as an rCOS design:p ⊢ R. The provided interface
aggregates the relevant data of class types as its fields. In addition, we allow a lim-
ited amount of fields of primitive types on the interface for use as guard conditions in
94
3.4. Development Method of rCOS
related sequence- and state diagrams. Corresponding to the use case diagram, a (top-
most) component diagram illustrates all components of the use cases. Especially, if a
use caseincludessome other use cases, we design a required interface for the compo-
nent of the use case, and connect the required interface to the provided interfaces of
the components representing the other use case.
Behavior protocols. The user then encodes the so-calledinteraction protocolof a
component into the model. The protocol describes how the component is to be used
through synchronized method invocation of the operations in the component’s provided
interface. It is achieved by adding a UML sequence diagram and/or state machine to
the interface. A sequence diagram illustrates the interaction of the component with
the external environment, represented by the actors. The initial sequence diagram,
calledsystem sequence diagram[103], is restricted to two lifelines, where one life-
line represents the environment (the actor of the use case), and the other represents
the component. Messages only flow from the actor to the component and represent
invocations of methods of the interface. We allow the usual control structures such as
iteration and conditional branches in the sequence diagram. These have controlling ex-
pressions in the form of boolean expressions over the fields of primitive types defined
in the interface.
While the sequence diagram describes the possible interactions with the system the
user can have, the state diagram describes how the system internally changes state dur-
ing execution. A transition of the state machine is triggered by an invocation of method
of the interface. There is a single initial state and a single final state. Choice nodes
with a boolean expression allow if-then-else constructs, without such an expression we
treat all alternatives as non-deterministic choices.
However, the reasons for having a sequence diagram and a state diagram are dif-
ferent [39]:
• the denotational trace semantics for the sequence diagram is easy to use as the
95
3. rCOS
specification of the protocol in terms of temporal order of the method calling
events,
• the state diagram has an operational semantics which is easier to use for verifi-
cation of both safety and liveness properties.
Analysis and verification. A requirements modelconsists of ause case diagramto
define the use cases of the system, acomponent diagramin which each use case is mod-
eled as a component, aconceptual class diagramrepresenting the domain concepts,
and a set ofsequence diagramsand/or state machines defining the behavior protocols
of the components. Also, each method of the provided interface of a component has an
rCOS designp ⊢ R to specify its data functionality. The validation of the requirements
model can be checked using the automated prototyping tool, AutoPA [106]. This tool
automatically generates executable code of the use case components directly from the
requirements.
However, these different artifacts of the requirements model have to be consistent:
• Static consistency: The consistency between the class diagram and the other
model artifacts is simply that the class diagram defines the type system for the
other diagrams. For functional specification of a method, all types, classes and
fields that are used in the specification are also defined in the class model, and
the commandof its method body must be well defined in the context of the
its owning class. It is obvious that adding new classes, associations and fields
preserves consistency. We define a set of well-formedness constraints, in the
language of OCL, to check the static consistency of a model. In addition, a type
checker has been developed to ensure the consistency of method specifications.
• Dynamic consistency: As both sequence- and state diagrams talk about the pro-
tocol of the same component from two different points of view, consistency
checking between them is also needed. Dynamic consistency requires that any
96
3.4. Development Method of rCOS
invocation sequence from the environment should be accepted if the sequence
conforms to the protocol. That is, whenever the users follow the interaction pro-
tocol defined by the sequence diagram, the interactions will not be blocked by
the system, i.e. no deadlock should occur. The traces of the sequence diagram
are also accepted by the state machine. The consistency is checked by translating
the sequence diagram and the state diagram to CSP [85], and do the checking in
FDR2, the model checker of CSP.
3.4.2 Object-oriented design
In this stage, we apply the rCOS object-oriented refinement rules [82; 181] to the
requirements model obtained from previous stage. The refinement rules formalize
both structural transformations and functionality refinement. Basically, there are three
kinds of OO refinements involved:functionality delegation, attribute encapsulation,
andclass decomposition. The refinement rules are implemented as model transfor-
mations. By stepwise application of these rules, the requirements model is gradually
transformed into a design model.
In particular, theexpert patternis the most often used refinement rule which de-
composes the functionality specification of a method by delegating responsibilities to
other classes. Theexpert patternensures that a functionality is allocated to an ap-
propriate object which can obtain the needed data to accomplish the functionality at a
minimum cost. It refines a design in the form ofp ⊢ R into object interactions, based
on a given class diagram. Basically, if a computation is realized by obtaining the data
that is distributed in different objects through association links, then this computation
task can be delegated to a target object by using this pattern. One feature of this re-
finement is that it does not introduce more couplings into the class structure by adding
new associations between classes.
When we first write the method specifications of a classC before applying the
97
3. rCOS
expert pattern, we often need to directly refer to attributes of the classes that are as-
sociated withC. Therefore, those attributes are required to be public. After function-
alities are delegated to associated classes, the attributes that were directly referred are
now only referred locally in their owning classes. These attributes can then be encap-
sulated by changing them to protected or private through applying theencapsulation
rule, which says that if an attribute of a class is only directly referred in the methods of
the class, this attribute can be made private; and it can be made protected if it is only
directly referred in specifications of methods of this class and its subclasses.
Moreover, theclass decompositionrule can be used to decompose a complex class
into a number of associated small classes. In addition, a set of small step structure
refactoring rules, as suchrenaming a class, adding an attribute, forward an attribute
through an association, are also proved to be refinements [181] and can be used in OO
design of rCOS.
The final model produced at the end of the OO design is adesign modelin which
the sequence diagram for each use case is refined to an object sequence diagram with
inter-object interactions, but the interactions between the actors and the component
remain unchanged. The conceptual class diagram is refined to adesign class diagram
in which methods and their specifications are assigned to domain classes. However the
state diagrams and component diagrams of the requirements model are not changed in
the OO design. The correctness of this design model is guaranteed by correct use of the
refinement rules. Since the class model and the method functionality design are purely
object-oriented, we can generate program code, for example, Java class declarations,
from the design model.
3.4.3 Component-based design
For the purpose of reusability, maintenance, and more importantly, distributed and
independent deployment (third party composition), the OO model needs to be further
98
3.4. Development Method of rCOS
refined to component-based model [160]. It takes place in the following two steps:
• Component abstraction: In this step, we take the object-oriented design model,
identify the "permanent objects" and decide if they should be made into com-
ponents according to their features. The features include if they logically repre-
sents existing components, hardware devices, external subsystems, or they can
be reused in different models of this application and other applications. A per-
manent object that aggregates a large amount of objects and functionality is also
suggested to be made into a component.
The identification of objects as components is carried out in an object sequence
diagram. It also decides the interfaces of the new components. Then we can ab-
stract the object sequence diagram into a component sequence diagram by hiding
the object interactions inside the identified components. This abstraction is au-
tomated as a transformation that correctly refines the OO design model into a
component-based design model, in which an original component is decomposed
into a composition of a number of components, and the component diagram of
the requirements model is refined to a set of component diagrams as more hier-
archical components are introduced. Moreover, protocols for the provided- and
required interfaces of the components are also automatically generated.
• Component architecture design: The set of components generated in the pre-
vious step may need to be reorganized to get a better model architecture. For
example, small components are composed into a bigger component to ease the
deployment. We use the set of operators defined in rCOS for component compo-
sition (see Section3.3.2), includingrenaminginterface methods,hidingservices
of a component,plugging a provided interface into a required interface, and
parallel compositionof components. These operators are also implemented as
model transformations, and the composability of the protocols for the provided
and required interfaces of the inter-dependent components should be checked to
99
3. rCOS
avoid deadlock and livelock.
The final result of the component-based design is a component-based architecture
model, which includes a set of hierarchical component diagrams to express the re-
lationships between these components, and a set of component sequence diagrams
describing the interactions of these components. To define its usage, each component
has a provided- and/or required interface, attached with protocols. Meanwhile, design
class diagrams and object sequence diagrams remain unchanged in the model.
Verification. We also define a set of well-formedness rules in OCL for static check-
ing of the component-based model. For verification of deadlock freedom of component
compositions, the component sequence diagrams are transformed to the input notation
of the FDR model checker for verification of deadlock freedom. Application depen-
dent safety and liveness properties are verified by model checking the state diagrams
of the components.
3.4.4 Platform specific design and implementation
The design activities in this stage include further refinements of the component in-
terfaces with concrete and appropriate mechanisms (or middlewares) such asRMI or
CORBA. Thus the platform independent model (PIM) of the component-based archi-
tecture model is transformed to a platform specific model (PSM) with regards to the
mechanisms. Program code can be constructed for each component using templates. A
template defines the information of the flow of method invocations and the assertions
specifying the functionality of the methods of the components. Verification and valida-
tion can be applied to components before and after introducing the PSM mechanisms,
such asruntime checking, and testing (unit testing).
100
3.5. Tool Support for rCOS
3.5 Tool Support for rCOS
The rCOS modeler. The tool plans to support the rCOS method in model construc-
tion, analysis, verification and correctness preservable transformations; and it generate
verifiable code from design models. The rCOS modeler provides an UML-like multi-
view and multi-notational modeling and a design platform with the ability to add plug-
ins. The tool is implemented on top of the Eclipse platform ensuring compatibility
with other UML-based software engineering tools.Topcased[165] is used to support
graphical model design.
The current version (v1.2.6) of rCOS modeler supports graphically design an rCOS
model using use case diagrams, class diagrams, sequence diagrams, state diagrams
and component diagrams. In the rCOS modeler, we can do the work of designing the
sequence diagram and specifying interface methods at the same time. In the view of
the sequence diagram, a new method signature is first created, then the message called
the method is added to the sequence diagram, and finally the data functionality of the
method is input. Moreover, the state machine can be automatically generated from the
sequence diagram of the interface.
The consistency of these diagrams can be checked by a group of OCL rules. CSP
specifications can be automatically generated from state diagrams and sequence dia-
grams, and checked in the FDR model checking tool. Textual rCOS specifications can
be specified, compiled and semi-automatically refined in the tool.
Correctness preserving model transformations. In the work of [179; 180], correct-
ness preserving transformations for rCOS were discussed. A set of metamodels for the
model of requirements, model of logical design and model of component architecture
were proposed. Some rCOS refinement rules, such as class decomposition, and class
to component transformation, were experimentally implemented using QVT Relations
in the tool of ModelMorf [122]. More rCOS refinement rules, such as expert pattern,
were proposed to implement as OVT transformations.
101
Chapter 4
QVTR-XSLT: A Tool for Graphical
Notation of QVT Relations
Model transformation is the core of model driven development. To address the need
for a common transformation language, OMG proposed the Query/View/Transforma-
tion language (QVT) [134] standard that consists of three transformation languages:
Relations, CoreandOperational Mappings. As a user-friendly, high-level declarative
transformation language, QVT Relations (QVT-R) has two concrete syntax styles: tex-
tual and graphical. The graphical notation of QVT-R provides a concise, intuitive and
yet powerful way to define model transformations.
However, as a standard transformation language of OMG, currently there are very
few tools supporting QVT-R, and even fewer for its graphical notation [50; 101; 118].
The lack of tool support for the QVT-R graphical notation greatly hinders its applica-
tion in real settings. To address the problem, and particularly to meet our urgent need
for a model transformation tool in the development of therCOS modeler[97], in which
model transformations are the main means for system refinements and refactoring, we
decide to develop a model transformation tool based on the graphical notation of QVT-
R. Because of our limited resources, we do not intend to provide a full implementation
of QVT-R, but instead a practical, easy-to-use tool that makes use of well-known and
commonly adopted standards, CASE tools and languages.
To develop a tool for supporting model transformations, immediately two questions
arise:
1. How to represent a transformation?
2. How to execute the transformation?
102
The methodology of MDD should be applied to design MDD tools themselves. In gen-
eral, there are two fundamental methods for the implementation of QVT-R. Since the
QVT specification [134] has defined the metamodel (abstract syntax), concrete syntax
and semantics for the QVT languages, the first method is directly based on the MOF
metamodel definitions, and creates a new implementation from scratch. The advantage
of this method is that the syntax and semantics of the language can be fully supported,
but the standard UML CASE tools will not be able to deal with such a language. We
have to design its own editor and compiler. On the other hand, UML, as a standard
modeling language, is not only capable to model various aspects of systems, but also
highly scalable by adding new properties to adapt it to specific domains. Therefore, the
second method, or the so-called "lightweight" one, uses the standard UML extension
mechanism calledprofile that consists in new stereotype definitions to extend existing
UML metaclasses. By reusing the UML infrastructure both at the language level and
tool level, the method will minimize the effort of developers and meet the requirements
for standardization and interoperability.
Following these considerations, we propose a UML profile that contains the nec-
essary stereotypes to represent main QVT-R ideas with UML concepts. The profile is
formally defined and uses OCL for expressing well-formed rules of the model, thereby
avoiding an arbitrary use of the profile elements. By applying the profile, a QVT-R
transformation can be elegantly represented as a standard UML model, called a trans-
formation model [21]. The model can be manipulated in standard UML CASE tools
using normal modeling means - its model elements can be copied, moved, edited in
the model, or refactored into modules. It can also be transformed into another model
(higher-order transformations) for the purpose of analysis, optimization or implemen-
tation. Therefore, the effort required for constructing a tool to edit and analyze the
rules of QVT-R will be much smaller than that of developing the QVT graphical editor
from scratch.
Transformations aim to be automatically executed. It is thus essential to provide a
103
4. QVTR-XSLT
transformation engine in our tool. We could have developed the transformation engine
using general programming languages such as Java or C++, but since QVT-R is a
declarative language, it will be a better choice to implement it with another declarative
language. In this way, we can focus on the semantic mappings of these two languages,
rather than on realization details, such as arranging the iteration and search-order. Of
course, we need to ascertain that the necessary semantic features of QVT-R can be
adequately supported by the executable implementing language.
As models are normally stored in the form of XML Metadata Interchange (XMI)
[133], a well-studied and standardized technique for mapping graph-based models to
and from tree-based XML documents, using an XML processor to manipulate the
concrete representation of a model comes as a natural choice. Having the charac-
teristic of both declarative and imperative languages, the Extensible Stylesheet Lan-
guage for Transformations (XSLT) [178], a standard language recommended by the
W3C for transforming XML documents, is powerful in defining rules, pattern match-
ing and processing structured data [96]. Moreover, XSLT is widely supported with
many industrial-strength processors, and can run efficiently on almost any platform
and work along with any programming language. Thus, it becomes our transformation
implementation language.
As the result, QVTR-XSLT, the tool we build for the graphical notation of QVT-
R, consists of two parts: a QVT graphical editor and a code generator. Based on the
UML profile for QVT-R, the graphical editor has been built on top of a popular UML
CASE tool. With the editor, we can define the metamodels, specify a transformation
using the graphical notation, validate it, and save as a transformation model in XMI
format. The code generator reads in the transformation model, automatically translates
it into pure XSLT programs, which can be directly executed under an XSLT processor
to produce target models from the source models. The XSLT programs can also be
easily integrated into other applications and systems. Furthermore, because of the strict
corresponding between QVT-R rules and the generated XSLT programs, many XSLT
104
Figure 4.1: Overall process of using QVTR-XSLT tool
CASE tools, such as XML Spy, can be used to debug a transformation. In addition,
with the help of a collection of pre-defined transformations, the definitions of a QVT-
R transformation can be exported in textual format and then reused in other QVT
tools, or we can produceXML Schemas(XSD) [176] from the metamodel definitions
to validate the generated target models. The overall process of using the QVTR-XSLT
tool is outlined in Fig.4.1.
The tool supports unidirectional non-incremental enforcement transformations of
QVT Relations, where a set of output models is produced from a set of input models.
The features supported by the tool include:
• Definition of metamodels using EMOF syntax.
• Definition of transformations using QVT-R graphical notation.
• Support the enforcement semantics of QVT-R with some restrictions, that is,
only single direction transformations from source to target models are allowed.
The target model will be empty at the beginning of a transformation. Further-
105
4. QVTR-XSLT
more, only two non-primitive domains - one source and one target, can be de-
fined in a relation.
• Traceability of transformation executions.
• Transformation inheritance and relation overlapping.
Some transformation scenarios, such as theconformance checkingtransformations,in-
cremental bidirectional transformations, model synchronization, as well as thecheck-
before-enforcesemantics of QVT-R, are not supported by the tool.
Even so, the QVTR-XSLT tool can still be applied in various transformation sce-
narios, for examples, the platform independent model (PIM) to platform specific mod-
els (PSM) transformations, or the transformations of UML models to models of formal
languages (such as CSP) for the purpose of model validation and verification.
Data transformation in data engineering is another potential application field for
the tool. In many application domains, such as enterprise systems integration and
health informatics, complex data coming from various sources with different structures
needs to be transformed and integrated. Using our tool, the structures of the XML
data can be described concisely by the metamodels, the mappings between the data
could be specified by relations of QVT-R, and the transformations can be effectively
completed by the generated XSLT programs. In addition, the tool can be used in the
fields of semantic web and ontologies, often there is a need to convert between different
knowledge models, which are also in XML formats. Since at the present time practical
tool support for the graphical notation of QVT-R is scarce, our tool marks a useful
attempt to bring the language to practice.
In order to apply the tool in reality, there are more issues to be considered than a
simple source model to target model transformation. For example, how to precisely
control the transformations through parameters. There is also a need for querying
models with a similar graphical notation as for defining QVT-R relations. In addition, it
is important for composition and reuse of transformation definitions in order to produce
106
new and more powerful transformations in a well-organized and maintainable way.
Furthermore, in case of model refinement and refactoring, changes may only happen
in a small part of a model. Hence the in-place transformation is required to improve
the efficiency and get rid of the definitions of copy rules for each model element. Part
of our work presented in the chapter involves developing solutions for these issues and
concerns.
The remainder of the chapter is organized as follows. We discuss related model
transformation approaches and tools in Section4.1. Section4.2 introduces the techni-
cal features of QVT Relations and XSLT, and gives a simple comparison of them. As
QVT-R relies heavily on the use of OCL, in Section4.3 we discuss how a sub-set of
OCL can be mapped into XPath, a sub-language of XSLT. In Section4.4, we present
the approach to translate QVT-R into XSLT, and Section4.5discusses the semantic fea-
tures of QVT-R supported by the approach. We describe the syntax and semantics of a
graphical model query facility and the techniques to implement it in Section4.7. Our
extensions to QVT Relations are shown in Section4.6. Section4.8 presents a UML
profile for QVT-R and discusses the implementation issues of the QVTR-XSLT tool.
Section4.9 focuses on applying our approach and tool on case studies and compares
the results with another QVT-R tool. Finally, Section4.10draws some conclusions.
107
4. QVTR-XSLT
4.1 State of the Art
Model transformations play a key role in all phases of rCOS development process.
These transformations anticipate a very high demand for the transformation approaches
and supporting tools:
• Capability: it should have enough expressive power and ability to deal with very
complex transformations;
• Correctness: provide functionality for the verification and validation of the trans-
formations;
• Integratable: transformations could be easily integrated into other CASE tools
without too much burden of addition libraries or execution engines;
• Interoperability: transformations can work with different programming languages
and work on different platforms;
• Standardization: transformations should use standards proposed by OMG or
other international organizations;
• Declarative style: transformations should be defined in declarative style, and use
graphical syntax, to facilitate manual checking, reviewing and maintenance.
• In-place transformation support: transformations in rCOS focus on model re-
finement and refactoring, so the tool should effectively support in-place trans-
formation.
Many approaches have been proposed for model transformations. In the fol-
lowing, we will select some relatively well-known transformation approaches, discuss
their main features and tool supports, and assess whether they can be applied to im-
plement rCOS transformations. The discussion will be limited to approaches of graph
transformation and QVT-like (including QVT-compliant or QVT-aligned) transforma-
tions.
108
4.1. State of the Art
4.1.1 Graph transformation languages and tools
Graph transformation specifies and applies transformations between graphs by so-
called graph rewriting rules. Graph rewriting can be taken as an extension to the
well-known string rewriting technique in Chomsky grammars. A transformation is
defined by an attributed graph transformation system which consisting of an attributed
type graph and a set of transformation rules. A rule consists of two graphs : the left-
hand side (LHS) and the right-hand side (RHS). While applying the rule, nodes and
edges defined in the LHS are matched to particular nodes and edges in the host graph.
Then, the matched nodes and edges that do not exist in the RHS are removed from the
host graph. After that, the nodes and edges that are defined in the RHS but do not exist
in the host graph are created as new nodes and edges in the host graph.
Among others, VIATRA [164], Fujaba [33], MOFLON [14], AToM3 [51], and
GReAT [10] are typical representatives of graph transformation approaches. Concern-
ing the categorization we focus on AGG as a representative of graph transformation
languages.
AGG. The Attributed Graph Grammars (AGG [34]) is a visual language supporting
an algebraic approach to graph transformation. In AGG, both the source and target
models are labeled graphs owning attributes, and the attribute values are defined by
separate data nodes. The types of the attribute could be primitive or user-defined types.
In AGG, the applicability of a rule can be further restricted by additional appli-
cation conditions. Given a host graph and a set of graph rules, two kinds of non-
determinism may occur: 1) several rules might be applicable and one of them is chosen
arbitrarily; 2) given a certain rule several matches might be possible and one of them
has to be chosen. There are techniques to restrict both kinds of choices. Some kind
of control flow on rules can be defined by applying them in a certain order or using
explicit control constructs, priorities, etc [161].
AGG is open-source. The AGG tool provides a graphical editor to design graphs
109
4. QVTR-XSLT
and transformation rules. It also have a textual editor for adding JAVA expressions. An
interpreter executes an AGG transformation by resolving the graph rewriting rules as a
constraint satisfaction problem. So the transformations are executed in one step with-
out any support for incremental update propagation. In the contrast, some other graph
transformation tools, such as Fujaba, generate executable code from the rewriting rules
in order to perform model transformations [161].
Due to its formal foundation, AGG offers validation support by means of consis-
tency checking of graphs and graph transformations according to the graph constraints.
In addition, critical pair analysis is used to find conflicts between rules and check of
confluence and termination for the transformations.
Classical graph rules do not embody OCL constraints, which greatly limits their
expressive power. In the recent literature, a need for integration of graph transforma-
tion and OCL has been expressed [77; 98; 99]. The OCL expressions are employed
for updating attributes and specifying restrictions. However, these works are still not
mature enough to be used in practical applications.
In summary, the advantage of graph transformation approaches is that they are
based on a formal foundation that allows automatic verification of and reasoning about
the transformations. And most of them offer user friendly graphical editors supporting
easy and intuitive design of transformation rules. A drawback of graph transformation
is that the transformations have to be expressed operationally rather than declaratively.
Since graph transformations do not explicitly support the separation of source and
target models, they can only be used for in-place transformations. In general, because
of the lack of expressive power, they cannot handle complex model transformations.
Furthermore, no graph transformation based language has been standardized.
110
4.1. State of the Art
4.1.2 QVT-like languages and tools
Many approaches have been proposed for QVT model transformations. For approaches
supporting QVTOperational Mappings, we mention SmartQVT [4] and Borland To-
gether [2]. Both of them provide a front-end for Operational Mappings that can be
used to parse transformation programs and obtain a model conforming to the QVT ab-
stract syntax. But since the work of the thesis is based on QVT Relations, we focus
on the discussion of some well-known languages and tools for relational QVT in what
follows.
ATL. The Atlas Transformation Language (ATL) [93] provide a set of transforma-
tion tools on Eclipse platform. ATL is mainly a declarative language, though some im-
perative constructors are allowed to ease the coding of complex transformations. The
language has a textual concrete syntax. An ATL transformation program is composed
of rules that describe how to create and initialize the elements of the target models.
ATL transformations are always unidirectional. Source models are read only and can
be navigated, while target models are write-only and cannot be navigated. The order
of rule execution is determined automatically, with the exception of lazy rules, which
need to be explicitly called.
ATL tool provides an IDE that supports dedicated editors, debuggers, code com-
pletion, syntax highlighting, metamodel registry, etc. ATL code is compiled and then
executed by the ATL transformation engine (ATL Virtual Machine). The latest version
of the ATL tool provides with advanced capabilities, like multiple source patterns and
rule inheritance. In addition, there are many successful transformation examples in the
ATL transformation zoo.
Currently, ATL is the most technically stable and mature model-to-model transfor-
mation tool which is able to deal with complex model transformations. But it still has
its drawbacks, including:
111
4. QVTR-XSLT
• ATL is only a QVT-aligned language, not QVT-compliant. Its concrete syntax is
quite different from what is defined in the QVT specification;
• ATL aims to support exogenous (out-place) transformations. It provides only a
limited capacity, called the refining mode, for endogenous (in-place) transfor-
mations;
• ATL does not have a graphical notation;
• Execution of ATL needs its own ATL virtual machine. This may cause difficul-
ties in integrating ATL transformations into other CASE tools.
To enhance ATL, some works have been proposed to align ATL and QVT [94], and
implement QVT-R on the ATL Virtual Machine [3].
UMLX and Declarative QVT. UMLX [ 173] and Declarative QVT (Eclipse Model
to Model (M2M) QVT-Relations project) [3] are two closely related approaches intend
to support QVT Relations, both led by Ed Willink.
UMLX is a graphical transformation language to complement the OMG QVT.
UMLX attempts to provide a declarative and easy to understand notation by re-using
the familiar UML notation for defining patterns, extended semantically by a solid def-
inition of the meaning of multiplicity and sets of objects [173]. Similar to graph trans-
formations, UMLX uses standard UML class diagrams to define information schema
and their instances, and extends the class diagram to define inter-schema transforma-
tions.
UMLX provides a graphical editor as an Eclipse plug-in based upon GEF. Then
a compiler is used to generate an executableNiceXSLimplementation. NiceXSL is a
dialect of XSLT. In this sense, UMLX can be regarded as a high level language for
XSLT from which it inherits many important concepts such as referential transparency
[173].
112
4.1. State of the Art
One drawback of UMLX is that it uses its own graphical concrete notation which
is more like the notations of graph transformation approaches, than the notation of
QVT-R. As no OCL is adopted, the expressive power of UMLX is limited.
Declarative QVT is an Eclipse M2M subproject that aims at extending UMLX to
support standard QVT-R. The goal of Declarative QVT includes offering a graphical
editor for the graphical notation of QVT-R.
Declarative QVT is still far from practical use. However, it seems that the project
is in trouble at present. The author tried to implement it on the ATL Virtual Machine,
instead of NiceXSL, but then he claimed the attempt was ”unsuccessful”, and a new
execution engine is being planned [3]. The author also claimed that his progress on an
enhanced QVT-R graphical language is very slow since there are numerous issues with
OCL and QVT that he has to work out.
medini QVT. The medini QVT [117] was one of the first available QVT tools that
support textual notation of QVT-R. It has a remarkable compatibility with QVT and
OCL standards. Features of medini QVT include the use of traces to enable incre-
mental updates and limited support for bidirectional transformations. Although some
features, such as the collection template and the check-before-enforce semantics, are
still missing.
The medini QVT provides a powerful QVT interpreter, and a transformation editor
with syntax highlighting, code completion, and debugging facilities. It is distributed
as an Eclipse plug-in or a stand-alone system. Currently, medini QVT seems to be
the most stable, mature and state-of-art implementation of QVT-R. It is chosen as the
model transformation tool in many research papers. Our work also takes medini QVT
as the reference implementation of QVT Relations. However, medini QVT does not
support graphical notation, and it is difficult to integrate medini QVT into CASE tools
that are not based on the Eclipse platform.
113
4. QVTR-XSLT
ModelMorf. ModelMorf [162] is a commercial tool for QVT Relations developed
by Tata Consultancy Services Ltd. It supports in-place transformation, trace output,
transformation inheritance and relation overriding, incremental execution and collec-
tion template. However, not all language features are supported. For example, there is
no support for bi-direction transformation execution and graphical notation.
In contrast to products discussed so far, ModelMorf is a command-line application.
ModelMorf provides no development environment or IDE. Transformation code can
be edited in any text editor, and executed by calling the ModelMorf QVT engine with
parameters. The metamodels and instance models are constructed by the MetaModeler,
which is also developed by Tata, and exported in the format of XMI. ModelMorf also
builds up intermediate structures, for example for saving the tracing information.
However, ModelMorf seems to be an abandoned. The latest version in its web site
is Beta 1, released in the year 2009, and there is no clear sign of a forthcoming release.
Figure 4.2: Comparison of transformation approaches and tools
Comparison of transformation approaches. Although model transformations are
highly necessary in the context of model driven approaches, not even the QVT stan-
dard was able to attract sufficient interest until now [183]. A main reason for this is the
lack of adequate tool support. Fig.4.2summarizes main features of transformation ap-
proaches we have discussed so far to evaluate whether they can meet the requirements
of our work. However, we can conclude that none of these currently popular tools fully
meets the requirements for implementing the rCOS transformations.
114
4.1. State of the Art
4.1.3 Efforts to support graphical notation of QVT Relations
QVT-R comes with two types of concrete syntaxes: textual (like coding a program) and
graphical. Compared to the rules of graph transformation approaches, the diagrams of
QVT-R relations look more concise because they textually specify the relationships
between the source and target model elements. In [55; 58; 173], the graphical notation
of QVT-R is recognized as an intuitive, natural option to define transformation, and
the majority of transformations should be represented by the QVT graphical notation
[118].
Some efforts have been made to support the graphical notation beside the UMLX
project [173] we have discussed previously.
• Visual QVT/R: In [31], Max Bureck of the Freie University Berlin proposed to
build a graphical editor for QVT Relations in his thesis project "Development of
a visual transformation-framework for QVT". The editor looks like it is building
on the Eclipse platform. However, there is no further information about the
editor.
• UPT: A UML profile intended for QVT graphical transformation is presented
in [118]. The purpose of the profile is to represent QVT transformations using
any UML tool and send these transformations to the different tools using the
XMI standard. A tool is implemented as a web application which does not pro-
vide a graphical interface, but only translates a transformation into Java code.
However, instead of using object diagram, UPT uses a kind of class diagram to
express the transformation rules, so it is not fully QVT compatible. Furthermore,
UPT is designed as part of the WebSA tool, rather than an independent model
transformation tool.
• Enterprise Architect : Based on Enterprise Architect (EA) [155], a commercial
UML CASE tool, Oliver Alt of the BOSCH Company proposed an approach
115
4. QVTR-XSLT
to realize a graphical editor for QVT-R [137]. He first designed a UML profile
which enables EA for QVT editing and then used the EA automation interface
extensions to realize the user interface. An experimental generator was imple-
mented using C# to derive the QVT textual representation from the graphical
representation. However, this proposal is only a case study for proof of concept.
No further related work can be found.
• VMTS : is a project to provide a QVT plug-in for the Visual Modeling and Trans-
formation System (VMTS) [30]. Based on the VMTS tool, a QVT-R editor has
been defined. Transformation rules can be specified in the editor, and then trans-
lated to VMTS code. However, also this project is only a case study of VMTS.
In summary, currently tool support for the graphical notation of QVT-R is still far
away from practical use in software development.
4.1.4 XSLT related approaches
Many transformation tools, such as ATL or medini QVT, read in models as XMI files,
execute a transformation, and output the resulting target models as XMI files. Since
models are often stored as XMI documents, XSLT becomes a natural choice for im-
plementing model transformations. XSLT is one of the most successful XML tech-
nologies, because it offers a very good balance between complexity and power [91].
In addition, since XML has rapidly emerged as a dominant standard for data represen-
tation and exchange, there are already many industrial-strength implementations, such
asSaxon, Xalanand MicrosoftMSXML, which have been widely used in web appli-
cations and data-intensive applications, e.g., querying XML databases. Stored as XMI
files, even large-scale models can be efficiently processed by XSLT and translated to
target XML files. Furthermore, XSLT is now well supported by CASE tools, such as
XML Spy. These tools provide good IDEs supporting keywords highlight, auto com-
plete, grammar check, breakpoints, execution traces, etc. Not to mention that XSLT is
116
4.2. QVT Relations and XSLT
supported by almost all programming languages and platforms.
Even so, directly programming in XSLT to manipulate complex XML structures, as
those involved in model transformations, is still error prone and cumbersome, because
of its low level syntax. To address this problem, MTrans [140] proposes a language
to describe model transformations, and then XSLT is generated from the descriptions.
Bichler [23] discussed model-to-text transformations using XMI as the input format.
An intermediate XML format is used to simplify the XMI, and then XSLT operates
on this simplified XML representation of the XMI content. The UMT tool [73] sup-
ports UML-to-UML model transformation based on XMI Light and generates XSLT
as the implementing language. Willink [173] proposed a graphical transformation lan-
guage UMLX to do model-to-model transformations. In its early version, UMLX is
transformed into XSLT that executes the transformation between XMI instances.
4.2 QVT Relations and XSLT
In this section we first discuss QVT-R on an abstract level with a metamodel and a
short example, then introduce the necessary concepts of XSLT and its sub-language
XPath. Finally, we compare the concepts of QVT Relations and XSLT.
4.2.1 QVT Relations
MOF Query/View/Transformations (QVT) [134] is a language proposed by Object
Management Group (OMG) for model transformations and manipulation. The QVT
specification [134] includes three packages: two declarative packages (Relations and
Core) and one imperative package (Operational Mappings). The QVT Relations (QVT-
R) aims to provide a high-level, user friendly declarative language. It supports complex
object pattern matchings and implicitly traceability.
The QVT-R metamodel shown in Fig.4.3 is adapted from the Relations package
[134]. Since we focus on the Relations language, we eliminate several abstract classes,
117
4. QVTR-XSLT
Transformation
+type : Type
Variable
CollectionTemplateExp
+isTopLevel : Boolean
Relation
PropertyTemplateItem
+isCheckable : Boolean+isEnforceable : Boolean
Domain
OCL::OCLExpression
OCL::OCLExpression
TemplateExp
OCL::CollectionType
ObjectTemplateExp
OperationCallExp
EMOF::Operation
EMOF::Property
EMOF::Property
RelationCallExp
EMOF::Package
DomainPattern
PatternTypedModel
EMOF::Class
EMOF::Class
Key
Pattern
Predicate
Function
Variable
0..*
+queryExpression
0..1
+referredRelation
0..*
+modelParameter1..*
+typedModel
0..1
+conditionExpression
1
0..1
+bindTo0..1
+where0..1
+referredClass
+bindsTo
0..*
+identifies
+argument0..*
+rootVariable
+referredCollectionType
0..1
+variable
0..*
+referredProperty
+predicate
0..*
+rule1..*
+extends
0..1
+when
0..1+where
0..1
+ownedKey
0..*
+part
1..*
+argument *
+value
0..1
+templateExpression0..1+referredOperation0..1
+rest
+domain *
+part *
+usePackage1..*
+member 1..*
+pattern0..1
Figure 4.3: QVT Relations metamodel
such asRule, RelationDomain, RelationTransformation, andRelationImplementation,
etc. Fig.4.4depicts an example QVT-R relation between instances ofClassandTable
(ClassToTable) in graphical syntax. This example is adapted from Annex A of [134]
and will be discussed later in Section4.9.1.
In the metamodel, atransformationconsists of a set ofrelations asrules. A trans-
formation has one or moretyped models(a typed modelis a model with a metamodel as
its type) as its parameters, and may extend from another transformation. In addition,
a transformation may ownkeysthat uniquely identify instances of model elements,
and functions, which are side-effect-free operations. Arelation is defined by two or
morecheckonlyor enforced domains. As shown in Fig.4.4, the relationClassToTable
consists of two domains. Marked by therelation symbol in the middle, the
118
4.2. QVT Relations and XSLT
Figure 4.4: Example QVT-R relation in graphical notation
left-hand domain, which concerns the typed modeluml, is acheckonlydomain, while
the right-hand domain isenforcedand comes from the typed modelrdbms.
Each domain is defined by adomain patternthat is composed of a set of linked
template expressions (TemplateExp), which may beobject template expressionsor col-
lection template expressions. The former refers to the classes of the corresponding
metamodel, and the latter defines a pattern that matches a collection of elements. Note
that templateExpitself is also an OCL expression, it may be hierarchically contained
in othertemplateExps, and consist of variable bindings and optional constraints.
A domain pattern has a distinguishedroot object template expressionwith tag«do-
main». It is required to be bound to a variable called theroot variable. The root
variable serves as a formal parameter of the relation. In addition, anobject template
expressionmay own a set ofproperty template items. Each of them binds aproperty
of the typed class to avariable (e.g. "name=cn” in the box labeled with "c:Class” in
Fig. 4.4, which binds the propertynameto variablecn) or to an OCL expression (e.g.
"kind=’Persistent”’).
A relation may define a pair of optionalwhenandwhereclauses that consist of
119
4. QVTR-XSLT
predicates, which are OCL expressions separated by semicolon ";". Thewhenclause
indicates the conditions under which the relation holds, and thewhereclause provides
additional conditions, apart from the ones expressed by the domain patterns them-
selves, that must be satisfied by all pattern elements in the relation [134]. A relation
call expressionin a clause specifies an invocation of a subsequent relation.
A relation may also have someprimitive domains, which serve as additional pa-
rameters of the relation. A primitive domain is a domain that possesses a data type,
but no specification of the domain pattern. Primitive domains only have the purpose
to forward values at the call of a relation. Furthermore, a relation is either designated
as atop-levelrelation, or anon-top-levelrelation. Atop-levelrelation is invoked from
the transformation framework, while non-top-level relations are invoked throughwhen
andwhereclauses of other relations. In general, a transformation only has one top-
level relation which has nowhenclause. We call it theroot relation, as it is the first
relation to be executed in the transformation.
Variableis an important concept of QVT-R. A variable may be of a primitive type,
or of a type defined in the metamodels, and can be referenced bypredicatesin both
whenandwhereclauses. A variable can be defined either in a domain pattern as a
name beingboundto an element or a property of an element, or in thewhereclause
using an OCL expression to give it a value. In fact, it is thevariablesthat makes a
pattern different from a normal object diagram.
A QVT-R transformation can be executed incheckonlyor enforcementmode. In the
checkonlymode, it simply checks if all relations hold, no modification to the models
will take place. In theenforcementmode, one of the typed models can be selected as
the target model and the transformation executes in the direction of it, while the others
serve as the source models. Then the execution first checks whether the relations hold,
and if the check fails, enforces the relations hold by modifying the target model. In the
follows, we only discuss executions of transformations inenforcementmode.
For the example of Fig.4.4, if the relation is executed in the direction ofrdbms,
120
4.2. QVT Relations and XSLT
the source domain pattern (left part) is searched in the source model by way ofpattern
matching: here the pattern matching starts from the root variable "c" of typeclass. In
addition, the relation callPackageToSchema(p,s)in thewhenclause states that, before
executing the current relation, there must already exist an element "p" in the source
model and an element "s" in the target model, and these two elements have been
related by relationPackageToSchema. Thus all child elements of "p" are searched
in the pattern matchingto locate elements that are of typeclassand have property
kind=”Persistent”. If a match is found, the variable "c" is bound to the element, and
the value of the element’snameproperty is bound to the variable "cn" (name=cn).
The target domain pattern is searched in the target model. In case of the target
domain ischeckonly, if no match is found, an exception will be thrown. In contrast,
if the target domain isenforcedand no match is found, the target domain pattern acts
as a template to modify the target model through adding, deleting or changing model
elements to satisfy the relation. The target model may be empty at the beginning of the
transformation. In this case, model elements and their links are created from scratch
by the target domain pattern.
In Fig. 4.4, the target domain isenforced (marked asE). If the matching fails,
under the context of "s", an element "t" of typeTableis created and itsnameproperty
is assigned to the value of variable "cn". In the same way, the model elements of type
ColumnandKey are created, their properties are set, and the links (columnandkey)
among them are established as specified in the domain pattern. Finally, in thewhere
clause, the relationAttributeToColumnis invoked using variables "c", "t" and "prefix"
as the arguments.
More issues about QVT-R semantics will be discussed in next section. Detailed
syntax and semantics of QVT-R can be found in [134].
121
4. QVTR-XSLT
Element
name : String
Node
value : String
ValueAttribute
Document
ReferenceAttribute
{ordered} {ordered}
Text
0..1
text
child
0..*
parentchild
0..*
referred 1..*
attribute0..*
Figure 4.5: An excerpt of XML data model
4.2.2 XPath
In XML technical space, XPath is a suitable tool for pattern matching. As one of the
W3C’s standards, XPath (XML Path Language) [177] is a declarative language for
locating nodes in XML documents at a higher level of abstraction. Complex search
conditions, which may require tree-oriented navigation, and may involve logic, arith-
metic, string, and set operators on attributes and nodes, can be adequately expressed
using XPath [91]. Thus XPath provides a powerful and convenient way to implement
pattern matching. Furthermore, XPath path expressions are also used to assign values
to variables,argumentsandattributes.
XPath is a textual language for representing search expressions in hierarchical
XML documents. It works on an abstract, logical tree-structure data model. Fig.4.5
shows an excerpt of the data model we use. In this model, every item is aNode.
TheDocumentis the distinguished root node of the tree, denoted by a global variable
xmiXMI in our approach. Anelementowns a set of attributes, each of them either
belongs to the set ofValueAttributesdenoted asAv, or is aReferencein the setAr.
Moreover, we denote the set of parameters of the XSLTrule templateowning the path
expression asP, andV is the set of variables declared before the path expression inthe
rule template.
We require an element has an identity attributeID ∈ Av . Thus an attributeαr ∈ Ar
122
4.2. QVT Relations and XSLT
is a set ofIDs.We define a functionxmiRefs : Reference → Sequence( Element) to
obtain the referred elements. Moreover, an element has anxmi labelthat consists of the
element’s name and some particular attributes. For example, aclassin a UML model is
represented in XMI as<packagedElement xmi:type=’uml:Class’ .../>, so thexmi labelfor
it is "packagedElement[@xmi:type=’uml:Class’]". We introduce a function
xmiLabel() to get the xmi label for each model element defined in the metamodel. The
set of xmi labels for all elements in the XML tree isL.
In XPath, there is only one basic type: sequence, a ordered collection that may
contain duplicate items. That means every value in XPath is a sequence. Of course
XPath provides atomic values which are sequences of length. The types of atomic
values includexs:boolean, xs:string, xs:doubleandxs:integer.
XPath usespath expressionsto locate particular elements in XML documents. The
syntax of path expressions is defined by:
〈Expr〉 = 〈NodeExpr〉 | 〈AttributeExpr〉;
〈NodeExpr〉 = ‘$’ ( 〈ν〉 | ‘xmiXMI ’ ) ( ( ‘ /’ | ‘ //’ ) 〈Step〉 )∗;
〈Step〉 = 〈Axis〉 ( ‘ [’ 〈Predicate〉 ‘ ]’ )∗;
〈Axis〉 = 〈ℓ〉 | ‘∗’ | ‘parent()’ | ‘xmiRefs(’ 〈RefExp〉 ‘ )’;
〈AttributeExpr〉 = 〈NodeExpr〉 ‘ /’ ‘ @’ 〈αv〉;
〈RefExp〉 = 〈NodeExpr〉 ‘ /’ ‘ @’ 〈αr〉;
whereν ∈ P ∪ V represents a parameter or a variable,αr ∈ Ar a reference attribute,
αv ∈ Av a value attribute, andℓ ∈ L an xmi label. We use∗ to denote a special label
that is used to match all elements.
A path expressionExpr is either aNodeExpr which is used to select a sequence of
nodes, or anAttributeExpr that gets a set ofvalue attributes. The selection starts from
the variable representing the context node, which can either be a parameter/variableν,
or the global variablexmiXMI, and is followed by location steps (Step) separated by
a path operator ”/” or ” //”, where the ”/” selects only the direct children of the context
123
4. QVTR-XSLT
node, and the ”//” finds all its descendants at arbitrary depth. A step is used tonavigate
from one node to a sequence of related nodes along anAxis, and the resulting sequence
can be filtered by a set ofPredicates that are enclosed by the brackets ”[” and ”]”.
An axis gives the direction of navigation. Among the possible axes are thechild
axis, which is represented by an xmi label in setL, theparent axisas functionparent(),
and thereference axiswhere the functionxmiRefs() is used to get the related nodes.
The wildcard "∗" can be used to match any node. A predicate defines constraintsthat
the resulting items must satisfy. It is either a boolean expression selecting the items for
which the predicate istrue, or a numeric expression that selects the item at the position
given by the value of the expression, for example "[2]" selects the second item. To
get values of attributes, ”@” is prefixed to the names of the attributes.
4.2.3 XSLT
ApplyTemplateExp
+fileName : String
Stylesheet
+mode : String+priority : Integer
RuleTemplate
XPathExp
SelectionPattern
+name : String
WithParamExp
+name : String
FunctionExp+name : String
KeyExp
ParamExp
+name : String
ElementExp+name : String
VariableExp
+name : String
AttributeExp
+match+body
1..*
+match +select
0..*+declare
0..*
0..*0..*
+select
+referred 0..*
+select
0..*
0..*
+import
0..*
+root
+mode.
0..*
0..*
+select
+contain
0..*
0..*
1..*
Figure 4.6: XSLT metamodel
XPath acts as a sub-language within XSLT. Having the characteristic of both declar-
124
4.2. QVT Relations and XSLT
ative and imperative languages, theExtensible Stylesheet Language for Transforma-
tions (XSLT) [178], is a standard language recommended by the W3C for transform-
ing XML documents. It is powerful in defining rules, pattern matching and processing
structured data [96]. Fig. 4.6shows the XLST metamodel used in our approach, and an
example of an XSLT rule template that implements the QVT-R relationClassToTable
is depicted in Listing4.1.
An XSLT program is called astylesheetthat consists of a set ofrule templates,
keyand functiondefinitions. Thekey is an index mechanism for rapid searching of
a particular model element through its attributes. XSLT also supports user-defined
functions that can be invoked from templates and functions. Moreover, a stylesheet
canimportsother stylesheets to compose a complex XML transformation.
1 <!−− pattern matching−−>
2 <xsl:templatematch="//ownedElement[@xsi:type=’uml:Class’][@kind=’Persistent’]"
3 mode="ClassToTable">
4 <xsl:param name="_targetDom_Key"/>
5 <!−− variable binding−−>
6 <xsl:variable name="c" select="current()"/>
7 <xsl:variable name="cn" select="$c/@name"/>
8 <xsl:variable name="p" select="$c/parent()"/>
9 <xsl:variable name="prefix" select="$cn"/>
10 <xsl:variable name="s" as="item()∗">
11 <xsl:apply−templatesmode="_func_PackageToSchema" select="$p"/>
12 </xsl:variable>
13 <xsl:if test="$s and $s/@name=$_targetDom_Key">
14 <!−− create target model−−>
15 <xsl:elementname="table">
16 <xsl:attribute name="name" select="$cn"/>
17 <xsl:elementname="column">
18 <xsl:attribute name="name" select="concat($cn,’_tid’)"/>
19 <xsl:attribute name="type" select="’NUMBER’"/>
20 <xsl:attribute name="rkey" select="concat($cn,’_pk’)"/>
125
4. QVTR-XSLT
21 </xsl:element>
22 <xsl:elementname="key">
23 <xsl:attribute name="name" select="concat($cn,’_pk’)"/>
24 <xsl:attribute name="column" select="concat($cn,’_tid’)"/>
25 </xsl:element>
26 <!−− invoke rule templates−−>
27 <xsl:apply−templatesmode="AttributeToColumn" select="$c">
28 <xsl:with−param name="prefix" select="$prefix"/>
29 </xsl:apply−templates>
30 </xsl:element>
31 </xsl:if>
32 </xsl:template>
Listing 4.1: An example XSLT rule template
An XSLT rule template is endowed with amatchattribute which has aselection
patternas its value, along with amodeattribute that can be regarded as the template’s
name. A rule template may have parameters defined by the<xsl:param> instruc-
tions. Inside a rule template, a set of variables is declared and obtains values using
the<xsl:variable> instructions. A template contains also a collection of hierarchical
<xsl:element> and<xsl:attribute> instructions to construct new nodes and their at-
tributes. A template can invoke another template through the<xsl:apply-templates>
instruction, and pass arguments to it. Theselection patternis an XPathpath expression
that locates the nodes in a source model to which the template applies.
There are more constructs in XSLT. In particular, the<xsl:import> instruction is
used to import the contents of one stylesheet into another. Like inheritance in object-
oriented languages,<xsl:import> is designed to allow the creation of a library or a
set of reusable stylesheets [96]. Furthermore, thedocument() function reads in multi-
ple XML files, and the<xsl:result-document> instruction writes models into different
XML files.
Inside a stylesheet, each template matches one or more elements in the source
126
4.2. QVT Relations and XSLT
model, and defines the actions to take and how to produce the output when a match
is found. The result of processing all of the elements in the source model generates
the target model. Execution of an XSLT stylesheet is by recursive application of each
individual template to the whole source model or a selected part of the model. A
template is selected by its mode attribute and matching condition (selection pattern).
Once a template has been matched, the variables defined in the template are bound to
their values, and the<xsl:element> and<xsl:attribute> instructions are executed to
build a fragment of the target model using these variables. Finally, the successive rule
templates are invoked.
For example, the path expression in lines 2-3 of Listing4.1selects elements of type
class(as anownedElementwith anxmi:typeattribute of value "uml:Class" and akind
attribute of value "Persistent"). All matched elements will be processed by the template
one by one. Inside the template, variables "c", "cn", "p" and "prefix" are bound to
values using path expressions (lines 6-9). Especially, in lines 10-12, the variable "s"
gets its value through an<xsl:apply-templates> instruction, and the existence of the
value is checked in line 13. Then, a model element of typetableand its child elements
of typescolumnandrkeyare created, and the links between them are established (lines
15-25). Finally, in the context of thetableelement, the templateAttributeToColumnis
invoked to sequentially create fragments of the target model as the child of thetable
element.
4.2.4 Comparison of QVT Relations and XSLT
In the following, we informally compare the major concepts of QVT-R and XSLT.
Table4.1summarizes the correspondences between these two languages.
Basically, both QVT-R and XSLT are declarative languages that do not opera-
tionally describe how a transformation is executed. QVT-R bases onEMOF metamod-
els, and XSLT can useXML Schemasas a metamodel mechanism. In our approach,
127
4. QVTR-XSLT
Table 4.1: Comparison of QVT Relations and XSLT
QVT Relations XSLT
EMOF metamodel XML schemasource model input XML filetarget model result XML filemultiple source model document() functionmultiple target model <xsl:result-document>transformation stylesheettransformation extend <xsl:import>relation rule templatesource domain pattern selection patterntarget domain pattern construct instructionprimitive domain template parametersource domain source context elementtarget domain target context elementobjectTemplateExp in node expression in selection
source domain pattern pattern &<xsl:variable>propertyTemplateItem in attribute expression in selection
source domain pattern pattern &<xsl:variable>objectTemplateExp in <xsl:element>
target domain patternpropertyTemplateItem in <xsl:attribute>
target domain patternOCL expression XPath expressionpredicate in when clause path expressionpredicate in where clause <xsl:variable>function <xsl:function>key <xsl:key>not template not() function
a QVT-R transformationcorresponds to an XSLTstylesheet. Thesource modeland
target modelof the transformation correspond to the source XML file and the resulting
XML file of the XSLT stylesheet, respectively. Each relation of the QVT-R transforma-
tion maps to arule template. Theroot variableof the source or target domain pattern
correspond to the source or targetcontext elementsof XSLT.
An object template expressionin a source domain pattern can be mapped to anode
expressionof the selection pattern and an<xsl:variable> instruction. Aproperty tem-
plate itemin a source domain pattern maps to anattribute expressionof the selection
128
4.3. OCL to XPath
pattern and an<xsl:variable> instruction. For the target domain pattern, anobject
template expressioncorresponds to an<xsl:element> instruction, and aproperty tem-
plate itemto an<xsl:attribute> instruction.
Furthermore, anOCL expressionin QVT can be mapped into an XPath expression.
So a predicate in thewhenclause can be mapped as anattribute expressionin the
selection pattern, and a predicate in thewhereclause corresponds to an<xsl:variable>
instruction. Finally, for QVT-Rfunction, keyandnot template(negative application
conditions), we have<xsl:function>,<xsl:key> instructions and thenot() function in
XSLT, respectively.
4.3 OCL to XPath
QVT-R relies heavily on the use of essential OCL. In awhenclause, each OCL ex-
pression is a predicate that specify a precondition for entering the relation, and OCL
expressions in thewhereclause are used to assign values to variables. Furthermore,
property template items in the domain patterns can directly bind to OCL expressions.
OCL is a strongly typed language used to specify constraints or queries for mod-
els. Each OCL expression evaluates to a type either predefined by the language or
defined as an element of a UML model. An OCL expression can be constructed by
using OCLoperationsand/ornavigationsthat follow links from one object to locate
other object(s) in the model. On the other hand XPath is designed for the purpose of
providing flexible and powerful query facilities to extract data from XML documents.
In XPath everything is an expression that evaluates to a value [95]. XPath has a range
of operators and functions for selecting nodes in a tree, or operating on sequences and
atomic values. What OCL can do for UML models, the XPath can do the same for
XML documents. Accordingly, a large subset of OCL can be mapped to XPath.
The mapping is defined as a functionOCLtoXPath(), which inputs an OCL ex-
pression and outputs an XPath expression. By applying regular expressions, the tex-
129
4. QVTR-XSLT
tual representation of the input OCL expression is parsed and analyzed using XSLT
xsl:analyze-string instruction. The expression is first segmented into OCL constructs
according to the delimiters, such as ".","->", "(" or ")". Then the constructs and their
relations are analyzed and mapped into semantic equivalent XPath expressions.
The abstract syntax of OCL is defined by the OCL metamodel in the UML 2.0 OCL
Specification [131] as two packages: theTypespackage defines the OCL type system,
and theExpressionspackage describes structure constructs of OCL expressions. In
addition, the specification defines a standard library that includes a set of predefined
operations. As we only support a subset of OCL, in AppendixA, we define the textual
syntax for the subset of OCL expressions and operations using EBNF.
The whole mapping process is divided into several steps that will be discussed in
detail next:
• map OCL types into XPath types;
• map OCL expressions, such asNavigationCallExps, IfExp and AttributeCall-
Exps, into XPathpath expressions;
• map OCL operations for primitive types and collect types, such asselect, includ-
ing, forAll, etc.;
• map OCL type operations, such asoclIsTypeOf, allInstances, oclIsUndefined,
etc.
4.3.1 Mapping OCL types
The OCL type system consists of predefined types as well as the types defined by the
UML model on which an OCL expression is built. All classifiers from the UML model
are types for the OCL expressions attached to the model. The predefined types can be
divided into basic types and collection types. The basic types includeBoolean, Integer,
RealandString. OCL uses collection types to specify collections of values. There are
130
4.3. OCL to XPath
four collection types:Set, OrderedSet, BagandSequence. These collection types have
the usual semantics.
In case of XPath, there is only one basic type: sequence, a ordered collection that
may contain duplicate elements. That means every value in XPath is actually a se-
quence. Atomic values are provided in XPath as sequences of length one. The types
of atomic values includexs:boolean, xs:string, xs:doubleandxs:integer. In addition,
XPath provides adistinct-values() function that removes duplicate values from the in-
put sequence. Table4.2shows the mapping from OCL types to XPath types.
Table 4.2: Mappings from OCL types to XPath types
OCL types XPath types
Boolean xs:booleanInteger xs:integerReal xs:doubleString xs:stringSet distinct-values(sequence)OrderedSet distinct-values(sequence)Bag sequenceSequence sequence
4.3.2 Mapping OCL expressions
An OCL expression is always evaluated in a given environment and based on an in-
stance of a model element as its context. The contextual instance can be explicitly
referred to by theself keyword. For example, a class invariant always takes the class
as the contextual element, and an object of the class will be the context. The envi-
ronment of an OCL expression defines what model elements are visible and can be
referred to in the expression. Typically, the metamodel of the current model serves as
the environment.
In our case, the OCL expressions work within QVT-R relations for specifying con-
ditions of the relations or calculate values for variables. To simplify the implementa-
tion, we restrict the environment for OCL expressions to the relation’s source domain
131
4. QVTR-XSLT
pattern. That means an OCL expression can only navigate along the links specified
in the domain pattern. Because it is impossible to decide which element in a relation
should be selected as the context, we don’t support theself keyword. In our approach,
an OCL expression generally starts from avariabledefined in the source domain pat-
tern or thewhereclause, and thisvariableis used as the context element. The variable
can be of a collection type that contains same kind of model elements. In this case, all
elements in the collection are evaluated individually and always return a union of the
results as a collection.
In OCL Expressionspackage, all possible kinds of expressions, such asNaviga-
tionCallExp, AttributeCallExp, IfExp andLoopExp, are specializations of the abstract
classOclExpression. We have to understand every construct ofOclExpressionin order
to intuitively map them into constructs of XPath. Due to space limit, we only discuss
some important constructs for each kind here. The goal is to demonstrate that the map-
ping of a complete OCL expression can be carried out in an inductive way from its
constructs.
NavigationCallExp: A NavigationCallExpis used to determine linked target objects
from a source object through an association between the classes of source and target
objects. For example, if there is an associationasso from classA to classB through
association endassoab , then from an objecta:A, the navigation call expressiona.assoab ,
a.asso or a.B gets a same objectb:B, or a same collection of objects of typeB if the
multiplicity of the association end is more than one.
A NavigationCallExpis mapped to an XPathpath expressionwith an axis ofchild
or parentto select a sequence of nodes. Letxa be an XML element corresponding to
typeA. Consider the kind of associationasso between classA andB in the metamodel,
there are three cases:
• If asso is a composition association, that means classA composes of classB,
the navigation call expression is directly mapped topath expressionxa+”/”+ ℓb,
132
4.3. OCL to XPath
whereℓb = xmiLabel(B) is the xmi label ofB;
• If B is the parent ofA, the expression is mapped toxa+”/”+” parent()”;
• If asso is a normal association, there must be a reference attribute with name
assoab in the XML element of typeA. In this case, we have to access objectb us-
ing thexmiRefs() function, and map the expression toxmiRefs(xa+”/@”+assoab ).
However, for the path expression starting from awherevariable, we only support the
case of composition association.
AttributeCallExp: An AttributeCallExpis a reference to an attribute of a class and
evaluates to the value of the attribute. For instance, if classC has an attributeatt , then
an attribute call expressiono.att gets the value ofatt from objecto:C.
We map the attribute call expressions intopath expressionswith axis ofattribute.
If xo is an XML element of typeC, theno.att becomesxo+”/@”+att in XPath.
I fExp: OCL has a direct representation for the conditional expressions like all other
programming languages. Meanwhile XPath has also the same kind of expressions.
Thus an OCLIfExp is directly mapped to an XPathif expression. For example, the
OCL expression "if con then exp1 elseexp2 endif " becomes the XPath expression "if
(xcon) then xexp1 else xexp2 ", wherexcon =OCLtoXPath(con), xexp1 =OCLtoXPath(exp1 ),
and xexp2 =OCLtoXPath(exp2 ).
LetExp: A LetExpis used to define new local variables with initial values, and the
variables cannot change their values. Frankly speaking, theLetExpvery often leads to
a long expression which is hard to read and debug. In QVT OCL, variables are defined
with each variable definition separated by a semicolon ’;’, and the scope of a variable
is the rest of thewhereclause from where the variable is declared. For example, we
use expression "var1 = exp1; var2 = exp2;" instead of "let var1 : Type1 = exp1 in let
var2 : Type2 = exp2 in ... ". A variables definition "var=exp;" becomes an XSLT
variable instruction:
133
4. QVTR-XSLT
<xsl:variable name="var" select="xexp"/>
where xexp =OCLtoXPath(exp). Still, a variable cannot change its value once it is
bound.
LoopExp: A LoopExpis an iteration construct over a source collection and results in
a value that depends on the specific kind and name of the loop expression. ALoopExp
can be either anIterateExpor anIteratorExp. An IteratorExpis an expression which
evaluates its body expression for each element of a collection using a set of predefined
collection operations which we are going to discuss later.
TupleExp: A TupleExpreturns a data structure of multiple values. For example,
let v1, v2 be the values of variablevar1, var2, respectively, we map the tuple expres-
sion var = Tuple{var1, var2} into a set of<xsl:element> instructions that create the
following XML node and assign it to variablevar.
<tupleExp>
<var1> v1 </var1>
<var2> v2 </var2>
</tupleExp>
After that, the expressionvar.var1 can be used to get the valuev1.
4.3.3 Mapping OCL operations
Operations for primitive types: Like most programming languages, OCL has a set
of operations for primitive types, such as arithmetic operators+, −, ∗, /, logical op-
erationsnot , and , or and comparison operations<, <=, =, >, >=, etc. On the other
hand, XPath also has this set of operations for primitive types with almost the same
syntax and semantics. So we can directly map these OCL operations into correspond-
ing XPath operations.
134
4.3. OCL to XPath
Operations for collection types: OCL has defined a set of collection operations
which are declared and informally explained in the chapter about the OCL standard li-
brary in [131]. These operations can be divided into two categories: regular operations
and loop operations. The regular operations provide common functionality over given
collections. For example, thesizeoperation computes the cardinality of a collection,
and we map it into the XPathcount function.
A loop operation iterates over each element of a given collection to perform a spe-
cific action. For instance, the OCLselectoperation: ”col -> select(bexp)”, wherecol is
an OCL expression which evaluated to a collection, andbexp is a boolean expression.
When theselectoperation is evaluated, every element of the collection is checked
against thebexp. The operation returns a subset of the original collection for which
bexp is true.
We map theselectoperation into an XPathnode expression: xcol [xbexp], wherexcol
is a sequence of nodes, andxbexp is a node test predicate which provides the ability
to filter the nodes, herexcol =OCLtoXPath(col) and xbexp =OCLtoXPath(bexp). In
a similar way, we have mapped the other collection operations. An excerpt of the
mappings from OCL collection operations to XPath expressions is shown in Table4.3.
Table 4.3: An excerpt of mappings for collect operations
OCL expression XPath expression
col->size() count(xcol)col->isEmpty() empty(xcol )col->first() xcol[1]col->asSet() distinct-values(xcol )col->including(col2 ) insert-before(xcol , 1 , xcol2 )col->includes(obj ) index-of(xcol , xobj )> 1
col->exists(bexp) exists(xcol [xbexp])col->forAll(v|bexp) every $v in xcol satisfies xbexp
col->iterate(v|exp) for $v in xcol return xexp
col->one(bexp) exactly-one(xcol [xbexp])
135
4. QVTR-XSLT
Type operations: In addition, OCL has defined a set of operations for type check
and type cast. Currently, we support the following type operations:
• oclIsTypeOf: This operation indicates if an element belongs to a specific type.
We implement it by checking thexmi:typeattribute of the element. For example,
in EMF XMI model, the expression ”obj->oclIsTypeOf(Cls )” becomes XPath
expression ”substring-after(xobj /@xmi:type,’uml:’)=’Cls”’.
• allInstances: This operation yields all existing objects of the specified class in
a model. It is implemented as an absolute path expression which checks the
xmi:typeattribute of each model element. For example, expressionCls.allInstances()
is mapped into XPath expression ”//∗[@name=’Cls’ and @xmi:type=’uml:Class’]”.
• oclIsUndefined: This operation checks whether an element is defined or not. We
implement the operation by checking the existence of the element. For example,
the expressionobj.oclIsUndefined()is mapped to XPath expressionnot(exists(xobj )).
Note that theoclIsTypeOfandallInstancesoperations support only the EMF models.
4.4 QVT Relations to XSLT
As we have seen in Section4.2.4, there are apparent similarities and analogies between
QVT-R and XSLT. Therefore, it is possible to define a mapping from QVT-R to XSLT.
Given a QVT-R transformation in the graphical notation, we can translate it into XSLT
by creating an corresponding XSLT stylesheet, defining the keys and functions for it,
and implementing each QVT-R relation as an XSLT rule template by the following
major steps:
• map the source domain pattern and thewhenclause into theselection pattern;
• create variable declarations from thesource domain patternand thewhereclause;
136
4.4. QVT Relations to XSLT
• generate element and attribute instructions from thetarget domain pattern;
• translaterelation call expressionsin the whenandwhereclause into template
invocation instructions.
Naturally, once a QVT transformation has been translated to an XSLT stylesheet, it
can be run repeatedly on different input models (conforming to the same source meta-
model). In the following, we shall focus on implementing a QVT-R relation through
an XSLT rule template, as it is the central phase of our approach, and the other steps
of our transformation approach are rather simple and straightforward.
4.4.1 Mapping source domain to selection pattern
We map the following three kinds of QVT expressions into theselection patternof an
XSLT rule template.
• Object template expressions;
• Property template items that bind a property to a literal expression
• Predicates in thewhen-clause, that impose restrictions on the object templates
and property templates.
Let Vd andVw denote all variables declared in the source domain and thewhereclause,
respectively. Using an algorithm similar to thedepth-first search, the mapping starts
from the root objectTemp, the pattern element under the tag«domain», which may
bind to aroot variablevarrt . Let expr be the path expression of the selection pattern
we are going to build. There are two situations:
• If the relation is top-level, that means the root variable is still a free variable,
and the pattern matching will search over all the source model. So we choose
the rootobjectTempas thecurrent context elemento : C , the objecto of type
137
4. QVTR-XSLT
C , and start from it to build anabstract path expressionexpr="//"+ℓc, where
ℓc = xmiLabel(C ) is the xmi label of typeC .
• If the relation is non-top-level, then the root variable is already bound to a model
element by the invoker of the relation, and the pattern matching will search under
the context of the root variable. So we select the element directly linked to the
root variable as thecurrent context elemento : C to start building arelativepath
expressionexpr=ℓc.
For example, as relationClassToTableshown in Fig.4.4 is a top-level relation,
by combining ”// ” with the xmi label for the root pattern element "c:Class", the select
pattern of its XSLT rule template starts with ”//ownedElement[@xsi:type=’uml:Class’]”
(line 2 of Listing4.1).
Now we consider thepropertyTempsof the objectTempo : C and the predicates
defined in thewhenclause. Letρ be apropertyTempreferred to a property of the class
C , there are two cases:
• if ρ is bound to a variablevarρ, and if there is a predicate in thewhenclause
that is related to the variable, we translate the OCL expression of the predicate
into an XPath boolean expressionxexp using the functionOCLtoXPath(). Then
we haveexpr = expr + ”[” + xexp + ”]". Otherwise if there is no such a predicate,
the expr will remain unchanged. Consequently an XSLT variable is defined as
<xsl:variable name=varρ select=expr+”/@”+ρ/>.
• if ρ is bound to an OCL expressionoexp, we getxexp= OCLtoXPath(oexp). Thus,
we haveexpr = expr + "[" + xexp + ”]”. In particular,oexp could be a regular
expression in our approach.
For example, in Fig.4.4, the element "c:Class" has a property template item "kind=
’Persistent’" that binds attributekind to literal expression’Persistent’, so an attribute
expression ”[@kind=’Persistent’]” is added to the select pattern (line 2 of Listing4.1).
138
4.4. QVT Relations to XSLT
As the next step, from the current elemento:C, the mapping moves to a pattern ele-
ment, for example,b:B, which directly links to the elemento. Consider the association
between classesC andB in the metamodel, three cases arise:
• If the association is composition, that’s to sayB is a child ofC, we get the xmi
label ofB by ℓb = xmiLabel(B), then we add to the path expression achild step:
expr = expr + "/" + ℓb.
• On the other hands, ifB is the parent ofC, we add to the path expression aparent
step:expr = expr + ” /” + ”parent()”.
• If the relationship is a normal association with nameasso, there must be a ref-
erence attributeαr in the XML element corresponding too, and the referred el-
ements can be gotten by functionxmiRefs(), then the path expression becomes:
expr = xmiRefs(expr + "/@" + αr).
Now, we takeb as the current element, sequentially handle its property template
items, related predicates in thewhenclause, and linked object templates in the same
way. This process continues until all object template expressions in the source domain
pattern are mapped.
4.4.2 Creating variable declarations
Variables may be declared in the source domain pattern and thewhere-clause. To in-
stantiate the variables in the source domain pattern, we adopt an algorithm similar to
the above one. We also start from the«domain» element, follow the links down to build
a path expression, and instantiate every variable (as the name of an object template
or the name binding to a property template item) we meet. For example, the object
template "c:Class" in Fig. 4.4 becomes<xsl:variable name="c" select="current()"/>
shown in line 6 of Listing 4.1, herecurrent() is an XSLT function to get thecur-
rent context element), and its property template item "name = cn" is translated to
139
4. QVTR-XSLT
<xsl:variable name="cn" select="$c/@name"/>, as shown in line 7.
For each predicate in awhere-clause that takes the formvar = oexp, wherevar
is a variable name andoexp is an OCL expression, we map the OCL expression into
an XPath expressionxexp=OCLtoXPath(oexp). Then this variable is defined through
the XSLT variable instruction<xsl:variable name="var" select="xexp"/>. For exam-
ple, the predicateprefix=cn in the whereclause of Fig.4.4 becomes<xsl:variable
name="prefix " select="$cn"/> as shown in line 9 of Listing4.1,
4.4.3 Generating construction instructions
As mentioned previously, a target domain pattern acts as a template to create corre-
sponding objects and links in the target model. If the relation is theroot relation, the
first executed relation, the creation process starts building a new target model using the
root variable as its root element. Otherwise, the creation process starts from the pattern
element directly linked to the root variable, and a new fragment of the target model is
created as the child of the root variable. In this process, an object template expression
o:C turns into an XSLTElementExp<xsl:element name="C "/>; a property template
item of the form"p=oexp", where"oexp" is an OCL expression, becomes anattribute-
Exp<xsl:attribute name="p" select="xexp"/>, wherexexp = OCLtoXPath(oexp). Other
linked object template expressions, depending on the associations in the metamodel,
become containedelements(for composition relationships) or key referencedattributes
(for normal associations).
For instance, in Fig.4.4, the "k:Key" element in the target domain is created as a
children of element"t:Table", while its nameproperty and the linkcolumnturn into
two attributeExps:
<xsl:elementname="Key">
<xsl:attribute name="name" select="concat($cn,’_pk’)"/>
<xsl:attribute name="column" select="concat($cn,’_tid’)"/>
</xsl:element>
140
4.4. QVT Relations to XSLT
4.4.4 Translating relation calls
In our approach, only two non-primitive domains are allowed, one source- and one tar-
get domain. For a relation call expressionRcall(svar,tvar,pvar1,...,pvarn), whereRcall
is the relation name, and thesvar, tvar,pvar1 to pvarn represent the source, target and
primitive domains of the relationRcall, we translate it into an XSLTApplyTemplateExp
instruction:
<xsl:apply−templatesselect="$svar" mode="Rcall">
<xsl:with−param name="pvar1" select="$pvar1"/>
...
<xsl:with−param name="pvarn" select="$pvarn"/>
</<xsl:apply−templates>
wheresvar is a variable already defined in the rule template where it is bound to an
object template expression, andpvar1 to pvarn are variables or literal expressions. This
apply-templatesinstruction will become a child of the current target domain pattern
elementtvar. This location serves as the target domain of the relationRcall, from here
the relationRcallwill subsequently create the substructures of the target model.
As an example, the relation call "AttributeToColumn(c,t,prefix)" in the whereclause
of Fig. 4.4 translates to an XSLTApplyTemplateExpin the context of"t:Table":
<xsl:elementname="Table">
...
<xsl:apply−templatesselect="$c" mode="AttributeToColumn">
<xsl:with−param name="prefix" select="$prefix"/>
</xsl:apply−templates>
...
</xsl:element>
whereselect="$c" means to select the variable "c" as the argument"c", and the current
target context"t:Table" as the argument"t" . At the same time, the variable"prefix" is
passed as the third argument.
141
4. QVTR-XSLT
4.5 Support Semantics of QVT Relations
In the previous section, we have discussed the approach to translate a QVT-R transfor-
mation into an XSLT stylesheet. However, it is not sufficient to only map constructs of
one language onto constructs of another language. The more challenging and crucial
problem is to preserve the execution semantics in the mapping. This is the focus of our
work when translating QVT-R into XSLT.
The semantics of QVT-R is defined in section 7 of the QVT specification [134].
Annex B of the specification gives a more formal definition of the semantics. In the
follows, we describe how a subset of the execution semantics of QVT-R can be sup-
ported in the approach. Particularly, we consider the support for:
• Mechanisms for reuse and extension of generic transformation definitions;
• Transformation traceability;
• Multiple source and target metamodels and models;
• In-place updates where the source and target models are the same.
The discussion tends to be informal, since a formal proof of the implementation is out
the scope of our work.
4.5.1 Transformation direction and check-before-enforce seman-
tics
QVT-R allows to specify multi-directional transformations. In the enforcement mode,
transformations can be executed in any direction by selecting one of the candidate
models as the target, and the target model may be empty or already contain model
elements at beginning of a transformation. Meanwhile, the check-before-enforce se-
mantics of QVT-R ensures that before creating a new element, it is checked whether
142
4.5. Supporting Semantics of QVT Relations
an existing one satisfying the constraints of the relation can be reused. In this way,
QVT-R supports both creating new, and modifying existing target model elements.
On the other hand, XSLT always generates new target models from the source
models. Bidirectional or check-before-enforce are not directly supported in XSLT,
even though it is possible to generate an XSLT stylesheet that performs a QVT trans-
formation in the opposite direction. Starting with empty target models, an XSLT im-
plementation always executes unidirectionally. So we must decide the source model
and the target model during the design of a transformation, instead of selecting one as
the target model at the execution time of the transformation.
4.5.2 Relation domains
In QVT Relations, a transformation is specified as a set of relations between candidate
models; each of them conforms to a metamodel. A relation is defined by two or more
domains. A domain is a distinguished typed variable which defines a domain pattern.
In the enforcement mode, a relation may contain multiple source domains, a target
domain, and some primitive domains.
By default, an XSLT stylesheet takes one XML file as input, and produces another
as the output. But XSLT also has mechanisms for supporting multiple input and output
models. Thedocument() function can be used to read a set of external XML docu-
ments, and the<xsl:result-document> instruction allows to serialize the target models
to different XML files. So it is possible to support more than two candidate models in
XSLT.
In our approach, a transformation can define more than two candidate models,
but for a relation only one source domain and one target domain are allowed, i.e., one
relation may have different source- and target domains with another relation. However,
as the template parameter, a primitive domain in our approach can be of a complex
type. It can represents a part of a model, or a whole model. Supplementing with the
143
4. QVTR-XSLT
primitive domains, more than two candidate models are able to participate in a relation.
In addition, a primitive domain can be used as an argument for a relation call, and then
becomes the source domain of the called relation. In this way, multiple source models
can be supported.
4.5.3 Rule scheduling
The most complex part of the QVT-R execution semantics is how the set of relations
is arranged in the execution of a transformation. Relations are mutually dependent
through the relation calls in thewhenandwhereclauses. The dependencies form a
dependency tree, in which two kinds of dependencies -whenandwhere, exist among
relations. The tree is rooted with a specific top-level relation, theroot relation, which
does not have any relation call in itswhenclause. A transformation starts from theroot
relation. Yet, whether a relation can be executed does not only depend on conditions
defined in its domain patterns and itswhenclause, but is also determined by its de-
pendent relations. A relation allows to define multiple relation calls in bothwhenand
whereclauses.
For example, as shown in Fig.4.4, in the whenclause of relationClassToTable,
there is awhenrelation callPackageToSchema(p,s). WhenClassToTableis invoked,
the variables "p" and "s" must already be bound to values by the relationPackage-
ToSchema, which is supposed to have already been evaluated. On the other hand,
relationClassToTablehas awhererelation callAttributeToColumn(c,t,prefix). Before
invoking that relation, the values for variables "c", "t" and "prefix" must have been
ready and then pass to the invoked relation.
As we have discussed in Section4.4.4, a where relation call can be fully imple-
mented as an XSLT template invocation instruction. It is relatively difficult to support
thewhenrelation call. One way to accomplish it is to put all top-level relations in a
waiting list, and keep checking the trace model to find the required variable bindings
144
4.5. Supporting Semantics of QVT Relations
for relations in the list, while executing the transformation. If all bindings for a relation
are found, the relation is then invoked. Obviously, an interpreter is needed to realize
this mechanism. In contrast, our approach implements QVT-R by mapping to XSLT.
However, in case of existing one target domain only, a relation is equal to a func-
tion that, given valid elements of the source domains and primitive domains as input,
produces an output of the type of the target domain, where the inputs and the output
satisfy the constraints of the relation. Thus awhenrelation call is similar to a so-called
backward where relation call[71]. Therefore we realize awhen relation call by the
following steps:
• implement a corresponding "backward"whererelation call in the called relation.
For example, if relationA calls relationB in its whenclause, then in the imple-
mentation, a relation call toA will appear in thewhereclause of relationB. If
there are severalwhenrelation calls in the relation, only the one that concerns
the context element of the target domain becomes thewhererelation call;
• generate an additional function from the definition of the called relation;
• invoke the function in the calling relation, and check its result.
For example, as shown in Fig.4.4, the relation callPackageToSchema(p,s)in the
whenclause is first implemented as a relation callClassToTable(c,t)in thewhereclause
of relationPackageToSchema. In addition, a function_func_PackageToSchemais gener-
ated from the definition of relationPackageToSchema. In the body of templateClassToTable,
the function is called and calculates a "s" from the input element "p" (lines 10-12 of
Listing 4.1), then we check: a) does the "s" exist; b) is "s" the correct context (parent)
element of target domain "t" (line 13, the key of the context element is passed as the
parameter "_targetDom_Key", and here key is thenameattribute). If the checks fail,
the execution of the relation aborts.
145
4. QVTR-XSLT
Moreover, in order to ensure the correctness of the transformation execution, we
can analyze the trace model (see Section4.5.6) for:
• all top-level relations are executed;
• all elements that have been referred in other relations are correctly created; and
• no duplicate created element.
Using the above procedures, our approach successfully simulates the rule schedul-
ing strategies of QVT-R.
4.5.4 Pattern matching
QVT-R uses pattern matching to find required elements in the source models and bind
them to the variables declared in the relation. The internal rule scheduling of Relations
is based on the pattern matching. Using theobject template expression, collection
template expressionandproperty template item, QVT-R supports definition of complex
patterns, which can involve sets of objects, non-existence of objects and ordered links.
In addition, a pattern might need to navigate and gather information from different
places of a model.
In order to handle such complex object patterns, pattern matching becomes a core
technique to implement QVT-R transformations. XPath provides a powerful and con-
venient way to implement pattern matching for QVT-R. Complex searching conditions
can be adequately expressed with XPath. The pattern matching semantics of QVT-R
can be fully supported by the path expression of XPath. In our approach, a domain
pattern of QVT-R is mapped to an XPath path expression, which is used as thematch
attribute of a rule template, and performs the searches in the source models.
146
4.5. Supporting Semantics of QVT Relations
4.5.5 Object creation using patterns
In the enforcement semantics of QVT-R, the target domain pattern acts as a template
for modifying the target model. If there does not exist a valid match for an object
template expression, a corresponding object is instanced in the target model, then the
property template items are used to assign values to the attributes of the object, and
the links to other objects are established. However, in case a required object already
exists, thekey, which is normally an identifying attribute of an object, is used to prevent
creation of a duplicate object.
In our approach, we implement an object template expression as an XSLTelement
instruction<xsl:element/>, and a property template item as an attribute instruction
<xsl:attribute/>. The complex hierarchy structure defined by the target domainpattern
can be supported by nested use of theelementinstructions.
For XSLT, the in-memory model has the same tree structure as the XML file of
the model. When a transformation starts running, the root of the tree of the target
model is first created by the root relation, and each of the other relations builds a
new fragment of the tree under the context element represented by the root object
template of the target domain of the relation. That is to say in our approach only the
elements which are direct descendants of the target root object template are going to be
created by the relation. The element of the target root object template itself may also
be created if the relation is top-level. All other non-descendant elements, which can
be thought as generated by other relations already, are only used for creating referred
links to them. A link is realized as areference attributewhose value is thekeysof the
referenced elements. Again, to ensure correctness of the transformation, the existence
of all referenced elements must be checked.
147
4. QVTR-XSLT
PrimitiveDomain
name : Stringsource : Stringtarget : String
Transformation
name : String href : String refName : String model : String op : String
TraceInstance
name : String
Relation
{ordered}
Object
0..*
0..*
Figure 4.7: Trace class model
4.5.6 Transformation traceability
Traceability has been identified as a basic requirement for model transformations. It is
important to keep a record of correspondences between source and target elements in
the execution of a transformation. The trace information can be used for incremental
updating, change propagating, or for debugging of the transformation.
QVT achieves traceability by producing a trace model during the execution of the
transformation rules. The trace model consists of trace-elements that refer to corre-
sponding model elements created by or contributed to the rules. For QVT Relations,
the requirement for outputting trace information is only "implicit". But as the executive
semantics of a transformation is given by the trace model, which establishes the rela-
tionships between elements of candidate models, we decide to support the generating
of trace models in the QVTR-XSLT tool.
Fig. 4.7 depicts the trace class model that we used to produce the trace(instance)
models. ATransformationin the class model represents an execution of a transforma-
tion as it records the name of the transformation, and names of the source and target
models. Thetransformationclass consists of an ordered set ofRelations, each of
them records an execution of a QVT-R relation whose name is specified in thename
attribute. ATraceInstancecould be anObjector aPrimitiveDomain. The former in-
dicates an object that takes part in the execution of the relation. Identified by thehref
148
4.5. Supporting Semantics of QVT Relations
property, an object belongs to a typed model indicated by themodelproperty, and may
have a name as the value of the propertyrefName. Moreover, thenameproperty keeps
the name of the corresponding object template in the relation, and theop property in-
dicates whether the object is created, or just referenced (contributed) in this execution
of the relation. For a primitive domain, its name is kept in thenameproperty, and its
value (or identifier) is stored in thehref property.
Output of the trace model is implemented by the XSLT<xsl:message> instruc-
tion that sends a constructed message to an implementation-defined destination, which
is normally different from the destination of the target model. During execution of the
stylesheet, the trace information is output to a message window, or can be captured
and saved as an independent trace file. An example of the trace model can be found at
List 4.3.
4.5.7 Transformation composition
The design and development of a complex software system using MDD means the use
of complex model transformations. However, to build a single transformation to deal
with such a complex transformation is difficult and almost impossible to maintain and
evolve. Following the principles of divide-and-conquer and separation of concerns,
a single transformation should be designed at a suitable granularity and focused only
on a specific aspect. This kind of smaller transformation is much easy to develop and
maintain. Thus a complicated model transformation can be realized by composing sev-
eral smaller transformations. Moreover, these smaller transformations can be reused
in different transformations, greatly improving the efficiency and reducing the skill
required for developing new transformations.
There are two mechanisms for the composition of model transformations [163]. An
external composition chains a set of separate model transformations, and each trans-
formation takes the output of the previous one as the input. An internal composition
149
4. QVTR-XSLT
composes two model transformation definitions into one new model transformation,
with a typically complex merge of the transformation rules [163]. Since the external
composition supports the composing of transformations written in different languages,
and usually operates in a framework that can execute different model transformation
languages, discussion of external composition is out of the scope of this thesis.
QVT-R supports the internal composition mechanism by transformation inheri-
tance and relation overriding. A transformation may extend from another transforma-
tion using theextendskeyword. The overridden relation should be indicated with the
overrideskeyword in the declaration of the overriding relation. Only single inheritance
is allowed.
This kind of inheritance mechanisms can be well supported in our approach. For
example, if transformationB extends from transformationA, then the following se-
mantics is supported:
• All relations, queriesandfunctionsdefined inA are accessible fromB;
• A relation defined inB overrides a relation with the same name defined inA.
Consequently all invocations to the relation will invoke the one defined inB;
• The same override mechanism applies toqueriesandfunctions;
• B is responsible for providing transformation arguments toA.
Obviously overriding a relation is only possible with one that has the same signature,
and the original relations will be completely replaced in the composed transformation.
We implement the transformation inheritance using<xsl:import> instruction of
XSLT, which is used to import the contents of one stylesheet into another. The dec-
larations in the imported stylesheet generated fromA are logically inserted into the
importing stylesheetB at the point where the<xsl:import> instruction appears. Since
imported declarations have lower precedence than the declarations that appear directly
in the importing stylesheet, rule templates defined in the importing stylesheetB can
150
4.5. Supporting Semantics of QVT Relations
override the templates of imported stylesheetA. Thus, all therelations, queriesand
functionsdefined inA can be used and overridden inB. While executing the XSLT
stylesheet ofB, the XSLT stylesheet ofA will be automatically imported.
4.5.8 In-place transformation
In application scenarios such as model refinement and refactoring, in-place (endoge-
nous) transformations become very popular. For an in-place transformation, the source
and target models are the same one during the execution, and the model elements can
be added, deleted and updated. Usually, only a small part of the original model is af-
fected by an in-place transformation, and most parts of the model remain unchanged.
If we address this kind of transformations as general source to target model transfor-
mations, we have to define copy rules to duplicate the preserved model elements from
the source models to the target. Since a non-trivial model could be very complex and
includes many sub-models, the number of copy rules could be huge.
QVT-R supports in-place transformations implicitly through its check-before-enforce
semantics. That is, if a relation does not hold, only the model elements affected by the
relation are modified to satisfy the relation, while the others remain untouched. In
order to support in-place transformations, we have developed a solution through the
following two steps:
1. define a relation as in a normal source-to-target transformation (both the source
and target models share the same metamodel);
2. explicitly specify the changes to the target domain pattern elements of the rela-
tion, such asinsert, remove, replace, etc.
Step 2 is particular to our approach. Instead of implicitly and automatically modifying
the model elements (of QVT-R), our approach requires that the designer explicitly
knows which elements of the target domain pattern are going to be modified, and
manually specifies the change operations on these elements.
151
4. QVTR-XSLT
<<Relation>>
PullUpAttribute
{when=clsnm=className; atnm=attributeName;}
oa : PrimitiveAttribute
{targetId = "atid" ,
xmiDiffOp = remove }
name = "atnm"
visibility = "atvs"
xmi:id = "atid"
na : PrimitiveAttribute
{targetId = "scid" ,
xmiDiffOp = insertTo }
name = "atnm"
visibility = "atvs"
xmi:id = "atid"
a : PrimitiveAttribute
<<Domain>>
: ClassModel
: Generalizationname = "clsnm"
c : Class
xmi:id = "scid"
sc : Class
<<Domain>>
: ClassModel
href = "ptp"
: Typehref = "ptp"
: Type
tsc : Class
tc : Class
general
Figure 4.8: In-place transformation example - relation PullUpAttribute.
Fig. 4.8 shows an example relation of an in-place transformation. It moves an
attribute from a class to its superclass. The name of the attribute is given by transfor-
mation parameterattributeName, and another parameterclassNamespecifies the name
of the class owning the attribute (see Fig.4.10). As described in the source domain
pattern of the relation, a classc and its primitive attributea, along with its superclass
scare located to satisfy thewhenclause. In the target domain pattern, an attributena
which duplicates all properties of attributea is insertedinto the superclasssc. This
changeof inserting is indicated as{targetid="scid", xmiDiffOp=insertTo}, wherescid is
the identifier of thescclass. Meanwhile the original attributea is deleted by theremove
operation tagged on attributeoa in the target domain pattern.
When an in-place transformation is executed, the objects marked with the change
operations will be collected into adifference modelthat records the modifications.
Then the source model is modified according to the records of thedifference model
to build a result model which then replaces the original source model. This process
is user transparent and runs automatically. In this way, the developers can focus on
developing relations concerned only with parts of a model that will be modified; there
152
4.6. Extensions to QVT Relations
is no need to deal with the other parts.
4.6 Extensions to QVT Relations
In order to improve the usability of QVT-R, we extend the language with the following
constructs : 1) transformation parameter; 2) relation alias name; 3) relation priority,
and 4) conditional relation call. Fig.4.9 shows the abstract syntax of the first three
extensions.
Transformation
Parameter +priority : Integer+alias : String
Relation
Type
parameter0..*
rule 0..*
type
1
Figure 4.9: Abstract syntax of QVT-R extensions
4.6.1 Transformation parameter
Unlike most of the graph transformation approaches, in which the execution sequence
of rules is specified with some additional control mechanisms, such as activity dia-
grams, the rule invocation order of QVT-R is implicitly defined by the relation call
expressions in thewhenandwhereclauses of the relations. In principle, the execution
unit of QVT-R is a transformation. We cannot manually select a single relation and
apply it to a specific part of the source model. To achieve a more accurate control of
the execution, external data may be needed. For example, if there is a transformation
that renames a class in a model, we need to indicate which class needs to be renamed
and pass the new name of the class to the transformation. The QVTRFP [130] also
puts forward the requirements (O5 of the optional specific requirements):
153
4. QVTR-XSLT
Submissions may support the consideration of external data that resides neither in
the source nor in the target model.
However, using transformation parameters to provide the external data is a reason-
able solution. According to the current QVT specification, a transformation only has
modelParameterswhich specify the typed models that serve as the source and target
models of the transformation. Therefore, we introduce the concept ofParameterto the
transformations. As shown in Fig.4.9, a transformation may have multiple parameters
of arbitrary types, that provide external data for a transformation.
In the light of using primitive domains as additional parameters for relations, we
consider also using primitive domains as the parameters for a transformation. Since no
primitive domain is allowed in the root relation (the first executed top level relation.
It has nowhenclause), we take the primitive domains defined in the root relation as
the transformation parameters. An example of the root relation is shown in Fig.4.10,
which defines two transformation parameters,attributeNameandclassName, of type
String. These two parameters will then be used in the relationPullUpAttribute, as
depicted in Fig.4.8.
<<Relation>>
ModeltoModel
{where=PullUpAttribute(scm,tcm);}
{isTopLevel}
<<PrimitiveDomain>>
className : String
<<PrimitiveDomain>>
attributeName : String
xmi:id = "cmid"
scm : ClassModel
xmi:id = "cmid"
tcm : ClassModel
<<Domain>>
: ModelRoot
<<Domain>>
: ModelRoot
Figure 4.10: Definition of additional transformation parameters.
In our approach, the transformation parameters are implemented as global variables
of the XSLT stylesheet, thus each relation (rule template) can access these parameters.
154
4.6. Extensions to QVT Relations
We therefore require that the name of a parameter is unique in the scope of the trans-
formation. The values of the transformation parameters are provided by aparameter
file, which we are going to discuss in Section4.8.1.
4.6.2 Relation alias name and priority
We introduce therelation alias nameto simple relation calls. As shown in Fig.4.9,
the alias attribute of the relation gives it an alias name. A group of relations can
share the same alias name if they perform similar functionalities. A relation call to the
alias name is semantically equivalent to call all relations of the group. It is required
that these relations have the same sequence of parameters and different source domain
patterns. Only the relation calls in thewhereclauses support this mechanism.
As an example, let’s look at the following relationAttributeToColumn, which is taken
from the classical UML to RDBMS transformation example [134]:
relation AttributeToColumn {
checkonly domainuml c:Class {};
enforce domainrdbms t:Table {};
primitive domain prefix:String;
where {
PrimitiveAttributeToColumn(c, t, prefix);
ComplexAttributeToColumn(c, t, prefix);
SuperAttributeToColumn(c, t, prefix);
}
}
where three relations,PrimitiveAttributeToColumn, ComplexAttributeToColumnandSuper-
AttributeToColumn, are called to convert different types of UML attributes to columns of
RDBMS tables. However, if we assign the same alias name, for exampleDoAttToCol,
to the three relations, then relationAttributeToColumncan be simplified to:
155
4. QVTR-XSLT
relation AttributeToColumn {
checkonly domainuml c:Class {};
enforce domainrdbms t:Table {};
primitive domain prefix:String;
where {
DoAttToCol(c, t, prefix);
}
}
In addition, we extend the metaclassrelation with an optionalpriority attribute
(modeled by an integer value), which is used for rule conflict resolution. In cases
where more than one relation is applicable, the one with the highest priority is actually
applied.
In our approach, we implement a relation as an XSLT rule template, while in gen-
eral the name of the relation becomes the value of themodeattribute of the template.
However, if the relation has an alias name, then we assign the alias name to themode
attribute, and the rule template is invoked through the alias name. In addition, the pri-
ority of the relation becomes thepriority attribute of the corresponding template. Simi-
larly, thepriority attribute is used to decide which template to invoke when<xsl:apply-
templates/> is called and there are several possible candidates.
However, in case of existing relation alias name and priority, a relation call to the
alias name chooses a relation from a group of relations using the following procedure:
• First select all the relations whose source domain pattern andwhenclause matches
the source model element passed by the relation call;
• If there is more than one, select those that have the numerically highest priority;
• If there are still several matching relations left, and they all have the same prior-
ity, the one that occurs last in declaration order will be chosen;
156
4.7. Model Query with QVT-R Graphical Notation
• If no relation matches the source model element, the designer can decide whether
the relation call processes each child of the source model element, or the relation
call is omitted.
4.6.3 Conditional relation call
We introduce the conditional relation call to improve the efficiency of rule selection.
As pattern matching andwhenconditions checking take a lot of time and resources, it
will be more easy to check some external conditions before invoking a relation.
As in normal programming languages, a conditional relation call takes the form:
if bexpthen RCall endif;
where thebexp is a boolean OCL expression, andRCall is a normal relation call. It
means theRCall will be invoked only if thebexpevaluates totrue.
We implement the conditional relation call as an XSLT<xsl:apply-templates/>
instruction contained in a<xsl:if/> expression:
<xsl:if test="$xexp">
<xsl:apply−templatesmode="Rcall" ...>
...
</xsl:apply−templates>
</xsl:if>
wherexexp =OCLtoXPath(bexp) is an XPath expression.
4.7 Model Query with QVT-R Graphical Notation
QVT-R only uses the graphical notation to specify transformation rules. The QVT
specification does not provide any facility to visually query models. Instead, QVT-R
heavily relies on the textual language OCL to define model queries. Of course, OCL’s
157
4. QVTR-XSLT
ability to navigate models and form collections of objects make it suitable as a query
language.
Alas, OCL suffers from several shortcomings for model querying. First, the stan-
dard OCL expressions are claimed to be too verbose, even defining simple queries
quickly leads to complex query statements [157]. One reason is the strong typing of
OCL. Type conversions are frequently used in the expressions. Secondly, OCL lacks
some features such as using wildcards likes "∗" or "?" to match textual attributes. It
also lacks basic statistical functions, such asavg(), max(). In addition, OCL expressions
are defined on the visual representations of metamodels and models, textually speci-
fying the connections between model elements and what properties they refer to are
tedious, difficult and error-prone. Overall, many users may find a visual programming
paradigm more accessible than a text-based one, as the former supports the “correct-
by-construction” editing, and only valid programs can be specified.
To overcome these limitations, supporting visual model querying is instrumental
for QVT-R to drive for success. Our query facility will help designers in the con-
structions of a query by graphically selecting model elements from the metamodels,
and give them a visual conception of the query. A graphical visualization facilitates
their intuitive comprehension of where a QVT-R rule will actually modify the models.
Meanwhile, features needed in model querying will be reinforced in the facility.
In this section, we present a graphical model query facility based on the checking
semantics and pattern matching of QVT-R. The query facility also borrows from QVT-
R the graphical notation. Thus the queries can be graphically specified, and become
executable by translation to XSLT programs.
4.7.1 Syntax of the query facility
A QVT-R transformation may contain a set ofqueries, each has an OCL expression
as the body. By evaluating the OCL expression, a query retrieves information from a
158
4.7. Model Query with QVT-R Graphical Notation
model. Very much like the role the source domain pattern plays in a relation, a query
uses the pattern matching mechanism to search for model elements that conform to the
structural pattern and attribute constraints given by the OCL expression. This inspires
us to see a query as a relation with only one domain pattern using the graphical nota-
tion. Naturally, our approach still depends on OCL, as the graphical notation mostly
coversstructural aspects of a query. Operations related to iteration and aggregation
will be specified textually either in OCL or XSLT-functions.
CollectionTemplateExp
Query
PropertyTemplateItem
Variable
Domain
TemplateExp
forAllSub : Boolean
ObjectTemplateExp
OclExpression
PrimitiveType
OclExpression
Property
DomainPattern
Pattern
Type
Parameter
Class
Predicate
Type
bindsTo
1
result1
referredProperty
when
0..1where
0..1
templateExp0..1
parameter0..*
bindsTo
0..1
rootVariable
0..1pattern 1
0..*
referredClass
value 1
type 1
part *
domain 0..1
predicate 0..*
conditionExp1
member 1..*
type 1
Figure 4.11: Metamodel of the model query
We define the abstract syntax of the graphical query facility using the metamodel
shown in Fig.4.11. The metamodel is adapted from the QVT Relations package [134]
by adding two metaclasses,QueryandParameter. The metaclasses in light yellow (or
light grey in black-and-white print) boxes are imported from the EMOF specification
[132]. In the metamodel, aqueryconsists of:
• a domaindefined by adomain patternthat consists of a set of linkedtemplate
159
4. QVTR-XSLT
expressions (templateExp), each of them can be anobject template expression
(objectTemp) or a collection template expression. The former specifies a pat-
tern that refers to a class of the corresponding metamodel. AnobjectTempmay
contain a collection ofproperty template items(propertyTemp) corresponding to
the properties of the referred class. A collection template expression specifies a
pattern that matches a collection of elements. Note thetemplateExpitself is also
an OCL expression, it may be hierarchically contained in othertemplateExps.
TheforAllSubattribute of theobjectTempindicates whether we want to search all
contained children at an arbitrary level of depth in the hierarchy of a model. A
templateExpor apropertyTempmay declare a variable andbind toit. We denote
all variables declared in the domain as the setVd. In addition, apropertyTemp
can be bound to an OCL expression which contains no variables.
• a whenclause is apatternthat consists of a set ofpredicatesseparated by semi-
colon ";". Here a predicate is abooleanexpression of the form of〈var〉〈op〉〈exp〉,
wherevar ∈ Vd, exp is an OCL expression which involves only variables defined
in thewhereclause or parameters, andop ∈ {=,<>,>,>=,<,<=}. These predi-
cates provide additional constraints on thetemplateExpsbound to the variables.
The relationship between the predicates is conjunction.
• a whereclause is also a set ofpredicates. Each of them defines a variable in the
form: 〈var〉 = 〈exp〉, wherevar is a free variable, andexp is an OCL expression
that only involves parameters, variables bound in the domain pattern or vari-
ables that have been defined in the preceding predicates of thewhereclause. We
denote all variables defined in thewhereclausen as a setVw.
• aset ofparametersused to pass values to the query, denoted asVp. A parameter
can be of primitive type or type of a class defined in a metamodel.
The set of all variables of the query denotes asV = Vp ∪ Vd ∪ Vw. Particularly,
160
4.7. Model Query with QVT-R Graphical Notation
a query may have aroot variablevarrt which binds to theroot objectTempthat ad-
heres to tag«domain», andvarrt ∈ Vd ∧ varrt ∈ Vp. Moreover, a query must define
a variablevarrst with name "result", which returns the result of the query, where
varrst ∈ Vd ∪ Vw.
<<Query>>
GetClassByName
{when=cnm=nm;}
<<Parameter>>
nm : String
name = "cnm"
result : Class
<<Domain>>
: Package
Figure 4.12: Example of the model query
Fig. 4.12 depicts a query example which acquires all classes of a UML model
that have the name given by the parameter. Following the style of QVT-R graphical
notation, a query is displayed inside a box, where its name shows in the middle top
of the box under the tag«Query», and thewhenandwhereclauses display also in
top part of the box, prefixed with "when=" and "where=", respectively. If there is
no whenclause, the "where=" prefix can be omitted. The domain pattern is shown
in the middle of the box as a special kind of object diagram, where an object or a
property may be decorated with a variable name. Note that in the diagrams a variable
bound to a property may contain additional quote-characters that are an artifact of the
visualization, not string delimiters. The small box with tag«Parameter» represents
a formal parameter and its type.
4.7.2 Semantics of the query facility
A query can be called from QVT-R relations, queries and functions. It finds parts
of models that fulfill given constraints specified in the query. We adapt the QVT-R
161
4. QVTR-XSLT
checking semantics and define the semantics of a query as: for each valid binding
of variables of the domain and the parameters, that satisfy thewhencondition, there
exists a valid binding of the result variablevarrst that satisfies the domain pattern and
thewherecondition.
The execution of a query starts from pattern matching. In a similar way as for a
QVT-R relation, the matching begins with the rootobjectTemp. If it has been bound
to an input parameter, that is to say∃ varrt · varrt ∈ Vp, then the search will start from
the model element specified by the parameter, otherwise the search will start from the
root of whole model. In the matching process, predicates specified in thewhenclause
act as additional constraints. If matching model elements are found, variables bound
in the domain pattern are instantiated, and then variables defined in thewhereclause
calculate their values. Finally, the value ofvarrst returns the result of the query.
4.7.3 Mapping domain patterns to XPath path expressions
As we have discussed previously, the graphical query facility supports complex object
patterns. In order to deal with such patterns, pattern matching becomes a core tech-
nique to implement the query facility. As XPath provides a powerful and convenient
way for pattern matching, to support the query facility, we map the domain pattern into
XPath path expressions
The mapping starts from theroot objectTemp, which may bind to aroot variable
varrt. We support two kinds of queries:
• A global model querymatches the entire model to retrieve all results fulfilling
the query. Ifvarrt 6∈ Vp ∨ ∄ varrt, that means theroot objectTempis not bound to
an input parameter, the pattern matching will search over the full model. So the
path expressionexpr begins asexpr="$"+"xmiXMI"+"//"+ℓe, whereℓe is the xmi
label of theobjectTemp’s referred class type, andxmiXMI is the global variable
representing the whole model.
162
4.7. Model Query with QVT-R Graphical Notation
• A local model query retrieves information from a given input model element.
In the case,varrt ∈ Vp, the pattern matching will search under the context of the
root variable. Thus we build the path expressionexpr starting from the variable
as expr="$"+varrt.
Then from the rootobjectTemp, say,o:C, whereC is the referenced type ofo, we
go down along the links to obtain otherobjectTemps, for example,b:B. Considering
the association between classC andB in the metamodel, three cases arise:
• Querying down the containment hierarchy: If the association is composition,
that’s to sayB is a child ofC, we get the label ofB by ℓb = xmiLabel(B), then
we add to the path expression achild step:expr = expr + "/" + ℓb. In case of the
forAllSub feature ofb is true, we want to query all descendant nodes, and then
the path expression becomes :expr = expr + "//" + ℓb.
• Querying up the containment hierarchy: On the other hands, ifB is the parent
of C, we add to the path expression aparentstep:expr = expr + ” /” + ”parent()”.
• Querying the normal references: If the relationship is a normal association
with nameasso, there must be a reference attributeαr with the same name
assoin the corresponding XML element ofo, and the referred elements can
be gotten by functionxmiRefs(), and then the path expression becomes:expr =
xmiRefs(expr + "/@" + asso).
If the objectTemp bis bound to a variablevarb, we construct an XSLT variable decla-
ration as<xsl:variable name=varb select=expr/>.
Now we consider thepropertyTempsof theobjectTemp b:Band the predicates de-
fined in thewhenclause. Letρ be apropertyTempreferred to a property of the classB,
there are two situations:
• if ρ is bound to a variablevarρ, and if there is a predicate in thewhenclause
that is related to the variable, we translate the OCL expression of the predicate
163
4. QVTR-XSLT
into an XPath boolean expressionxexp by the functionOCLtoXPath(), which is
specifically designed to map an OCL expression to an XPath expression. Then
we haveexpr = expr + ”[” + xexp + ”]". Otherwise if there is no such a predicate,
the expr will remain unchanged. Consequently an XSLT variable is defined as
<xsl:variable name=varρ select=expr+”/@”+ρ/>.
• if ρ is bound to an OCL expressionoexp, we getxexp= OCLtoXPath(oexp).
Thus, we haveexpr = expr + "[" + xexp + ”]”. In particular,oexp could be a
regular expression in our approach.
In this way, we traverse all linkedtemplateExpsand theirpropertyTempsto con-
struct path expressions, and instantiate every variable we meet on the way.
4.7.4 Generating XSLT functions for queries
We create an XSLT user-defined function for a query using the<xsl:function> instruc-
tion. For each parameter of the query, we generate a corresponding XSLT parameter
using the<xsl:param> construct. Inside the function body, we collect all variabledef-
initions instantiated from the domain pattern. Then, for each predicate in thewhere
clause that takes the form of〈var〉 = 〈oexp〉, wherevar is a free variable, andoexp is
an OCL expression, we map theoexp into an XPath expressionxexp using the func-
tion OCLtoXPath(), and generate an XSLT variable declaration for the predicateas
<xsl:variable name=var select=xexp/>. Finally, a<xsl:sequence> instruction will
return the value of theresultvariable. Furthermore, an OCLTupleexpression can be
used to return multiple values.
As an example, the following XSLT function is generated from the example query
shown in Fig.4.12. Here "my:" is the name space we give to XSLT user-defined
functions:
<xsl:function name="my:GetClassByName">
<xsl:param name="nm"/>
164
4.8. Tool Design and Implementation
<xsl:variable name="result" select="$xmiXMI//packagedElement
[@xmi:type=’uml:Class’][@name=$nm]"/>
<xsl:variable name="cnm" select="$result/@name"/>
<xsl:sequenceselect="$result"/>
</xsl:function>
4.8 Tool Design and Implementation
Our tool to support the graphical notation of QVT-R and the model query facility,
namely QVTR-XSLT, is designed as two parts: a QVT-R graphical editor and an XSLT
code generator. In addition, we have developed a collection of pre-defined transforma-
tions as part of the tool for the purpose of improving the interoperability of the tool,
and for transformation verification and validation. To implement the tool in a standard,
model-driven way, we first define a UML profile for QVT-R model.
4.8.1 A UML profile for QVT Relations
We adopt the "lightweight" method to implement the abstract syntax of QVT-R by
defining a UML profile. The QVT-R profile is designed based on the QVT-R meta-
model presented in Section4.2.1and the QVT-R semantics we intend to support. We
also consider supporting the graphical query facility. Following the standard UML pro-
file notation, the stereotype definition part of the profile is presented as a UML profile
diagram shown in Fig.4.13.
The root of the profile diagram is the stereotypeQVTRModel, which is extended
from UML model, to represent a QVT-R transformation model. In UML,modeland
packageserve as grouping units to contain and organize other model elements in a
hierarchy structure. A QVT-R model consists of a set ofMetaModels andTransforma-
tions. A transformation is a UML package that comprises ofFunctions, Relations and
Queries. The transformation stereotype has attributessourceNameand targetName
165
4. QVTR-XSLT
+sourceName : String [1..*]+sourceKey : String [1..*]+targetName : String [1..*]+targetKey : String [1..*]+isInPlace : Boolean+parameterFile : String+extends : String+output : TransforOutput+makeTrace : Boolean
<<stereotype>>
Transformation
[Package]
<<stereotype>>
QVTRModel
[Model]
+language : Language = OCL
<<stereotype>>
Function
[FunctionBehavior]
+position : Integer+typedModel : String
<<stereotype>>
Object
[InstanceSpecification]
<<stereotype>>
Where
[Constraint]
<<stereotype>>
When
[Constraint]
+kind : DomainKind
<<stereotype>>
Domain
[InstanceSpecification]
+sNumber : Integer
<<stereotype>>
Parameter
[InstanceSpecification]
+sNumber : Integer
<<stereotype>>
PrimitiveDomain
[InstanceSpecification]
+isTopLevel : Boolean+relName : String+priority : Integer
<<stereotype>>
Relation
[Package]
sourcetarget
<<enumeration>>
DomainKind
htmlxml
<<enumeration>>
TransforOutput
<<stereotype>>
Query
[Package]
+value : String
<<stereotype>>
PropertyItem
[Slot]
<<stereotype>>
MetaModel
[Package]
XSLTOCL
<<enumeration>>
Language
{ordered}
{ordered}
0..10..1
0..10..1
1..* 0..*
1..*
0..*0..*
0..*
target 1..*
source1..*
0..12
0..*0..*
0..*+slot
1..*
Figure 4.13: The UML profile for QVT-R
that record a set of source and target typed models, each of them corresponds to a
metamodel. In addition, we can define akeyfor a typed model to indicate its identity
property. In the case of EMF models, the key is usually thexmi:id attribute.
There are also other attributes in the transformation stereotype that play different
roles. In order to support a model-to-text (actually, to HTML) transformation, we can
set theoutputattribute to "html", otherwise, the output of the transformation will be
models in XML format. Theextendsattribute indicates from which transformation the
166
4.8. Tool Design and Implementation
current transformation inherits, and theparameterFileattribute is used to specify the
name of the parameter XML file. If themakeTraceattribute is set totrue, the code
generator produces an XSLT stylesheet that will generate trace information. To define
an in-place transformation, we have to set theIsInPlaceattribute totrue.
We map QVT-R relation to stereotypeRelation, which is also extended from UML
package. The stereotype has a boolean attributeisTopLevelto indicate if it is a top-level
relation, and an integer attributepriority to record the relation’s priority, which is 0 by
default. In addition, attributerelNamecan be used to assign an alias to the relation. In
our approach, a group of relations can share the same alias and have different matching
patterns. An alias can be used in relation calls. In this case, which concrete relation
will be actually invoked depends on whose source domain pattern is matched, and the
value of priority if there are more than one matched relations.
A relations owns twoDomains, and may contain somePrimitiveDomains, aWhen-
and aWhere clause. Thewhenandwherestereotypes are defined as extensions of UML
constraintto store OCL expressions. For the primitive domain stereotype, the attribute
sNumberindicates the order of this primitive domain appeared in the parameters of the
relation.
In the QVT-R metamodel shown in Fig.4.3, the DomainPatternmetaclass rep-
resents a special object diagram defined as nested object templates and/or collection
templates, along with their links for pattern matching and instantiation. We map the
metaclassTemplateExpinto stereotypeObject which is extended from UMLInstance-
Specification. In order to provide some support for thecollection template, the object
stereotype has apositionattribute to point out which element we want to match in
an ordered collection, and we define arest function to get the other members of the
collection except the one at thatposition. Furthermore, theobject stereotype has a
typedModelattribute to indicate which typed model this object belonges to, for the
purpose of supporting multiple models.
The root object template of a domain pattern is an instance of theDomain stereo-
167
4. QVTR-XSLT
type, which is a subclass of theobjectstereotype. Its attributekinddecides whether the
domain is the source or the target. Naturally, extended from UMLslot, the stereotype
PropertyItem represents thePropertyTemplateItemclass of the QVT-R metamodel. Its
valueattribute contains an OCL expression that assigns a value to the variable declared
as the name of the property item.
To support the graphical query facility, we define the stereotypeQuery. A query
may also include a domain pattern, awhenand awhereclauses, and someParame-
ters. Similar to the primitive domain stereotype, the parameter stereotype also has an
attributesNumberthat decides the order of the parameter when calling the query.
In the profile, aMetaModel is used to collect a set of simple class diagrams to define
the metamodel for a typed model. As shown in Fig.4.14, we use the most essential
fragments of the UML class model (approximately equivalent to EMOF metamodel)
as the meta-metamodel to define the metamodels. We support onlyClass, Property,
Generalizations andAssociation. Regarding the links among the objects, we define the
stereotypeLink, which represents an instance of an association.
Mapping UML to XMI
As discussed previously, a model is normally stored as an XML file in EMF UML,
Ecore or other XMI formats. For example, in EMF UML, aClassis serialized to an
XML fragment <packagedElement xmi:type="uml:Class"/>, which represents a
packagedElementnode with anxmi:typeattribute of value "uml:Class". As XSLT di-
rectly deals with XML fragments, it does not have any ”in-memory” model different
from the XML document itself. On the other hand, we specify QVT-R relations using
UML model elements defined in the metamodels, such as theClass. In order to gen-
erate correct XSLT code, there must be a way to specify the correspondences between
UML concepts and their XML presentations. It is called thexmi labelfor the UML ele-
ment. An xmi label consists of the node’s name and some particular attributes. For ex-
ample, the xmi label for theClassis "packagedElement[@xmi:type=’uml:Class’]".
168
4.8. Tool Design and Implementation
+aggregation : AggregationKind
AssociationEnd
Property
isAbstract : Boolean
Class
Boolean
IntegerString
Real
<<enumeration>>
PrimitiveType
<<stereotype>>
PropertyItem
[Slot]
<<stereotype>>
Link
[InstanceSpecification]
<<stereotype>>
Object
[InstanceSpecification]
<<stereotype>>
MetaModel
[Package]
Association
+href : PrimitiveType
Type
compositenone
<<enumeration>>
AggregationKind
Generalization
+value : String
UpperValue
+value : String
LowerValue
+classifier
0..*
+classifier
+definingFeature
+memberEnd 2
+ownedAttribute0..*
+general
+association
+type
0..*
+linkEnd
2
0..1
1..*
Figure 4.14: TheMetaModelpackage of QVT-R profile.
We define a functionxmiLabel()to get the xmi labels of model elements. For a
standard format such as EMF UML, the correspondences are already defined in the
specification of the standard. It is possible to calculate xmi labels with a standard
library. But for the other formats, the designers have to define the mappings for the
xmiLabelfunction themselves.
+node : String+xmiType : String+stereoType : String+xsiType : String
<<stereotype>>
XMIClass
[Class]
Figure 4.15: The stereotype for mapping UML to XMI
As shown in Fig.4.15, we introduce a stereotypeXMIClass to facilitate the defi-
nitions of the mapping. By applying the stereotype to a class in the metamodel, we
can input the corresponding XMI information. For instance, for the UMLClass,
169
4. QVTR-XSLT
its node attribute is set to "packagedElement", and the xmiType attribute is set to
"uml:Class". Thus, it is easy for thexmiLabel() function to generate the xmi label
for the element. Meanwhile, the class diagram is kept concise by hiding the XMI
information.
Supporting in-place transformations
+xmiDiffOp : xmiDiffType+targetId : String+resetAttName : String+resetAttValue : String
<<stereotype>>
XMIDiff
[InstanceSpecification]
insertBefore
insertNextinsertTo
resetAtt
replaceremove
<<enumeration>>
xmiDiffType
Figure 4.16: A stereotype for in-place transformation.
Instead of implicitly and automatically modifying the model elements (of QVT-R),
our approach requires that the designer explicitly knows which elements of the target
domain pattern are going to be modified, and manually defines the changes applied on
these elements.
The definition of the changes is carried out by applying a stereotypeXMIDiff to
the objectsof the target domain patterns. As shown in Fig.4.16, the stereotype has
an attributexmiDiffOp that specifies the kind of the changing operations, and atargetId
attribute to indicate the identity of the referred element. Since sometimes the order of
elements inside a model has semantic meaning, we define three kinds of operations for
creating an element:insertBefore, insertToand insertNext. They are used to insert a
new element before thetargetId element, insert into as the child element of thetar-
getIdelement, or next to thetargetIdelement, respectively. We also define thereplace
andremoveoperations, to replace or delete the corresponding model element. If the
operation isresetAtt, then the attribute of the model element with name specified in the
resetAttNamewill be set to the value given byresetAttValue.
170
4.8. Tool Design and Implementation
Defining the parameter file
Thetransformationstereotype has attributes to record the typed models that participate
in the transformation as model parameters. In our extensions to QVT-R, we also define
that the primitive domains specified in the root relation serve as additional transforma-
tion parameters. However, these parameters are formal parameters of the transforma-
tion. To provide the transformation with actual parameters, we use aparameter file,
whose name should be designated by theparameterFileattribute of thetransformation
stereotype.
For example, we can use the following XML file to provide actual parameters for
the transformation that owns the relations shown in Figs.4.8and4.10:
<?xml version="1.0" encoding="UTF−8"?>
<parameterRoot>
<className>Book</className>
<attributeName>volume</attributeName>
<TypedModel name=’xmiXMI’ file=’Library.uml’/>
<TypedModel name=’digDIG’ file=’Library.di’/>
</parameterRoot>
where we provide values for parametersclassNameandattributeName, which are de-
clared as primitive domains in root relationModeltoModel(see Fig.4.10).
In the Topcased [165] framework, a complete model consists of two models: a
UML model that contains the abstract syntax information, and a DI (diagram inter-
change) [75] model contains the concrete syntax (visual representation) information.
These two are technically different models because they conform to different meta-
models, and store in separate XML files. So in the parameter file, we declare two
typed models,xmiXMI anddigDIG, to represent the two XML files of a library model.
Thus, we can input the same string "xmiXMI, digDIG" to thesourceNameandtarget-
Nameattributes of thetransformationstereotype, as the transformation is an in-place
one.
171
4. QVTR-XSLT
Well-formedness constraints for the profile
In order to guarantee the generation of correct XSLT stylesheet, it is essential that
the transformation models can be checked for well-formedness. As an important part
of a profile, the well-formedness constraints provide a model with the static seman-
tics. In our profiles, we have defined more than twenty well-formedness constraints
using OCL. All these constraints fall into two categories: stereotype conformance con-
straints, which require a model element of the stereotype to have some properties,
and model consistency constraints, where different parts of a model must be mutually
consistent. Moreover, according to the seriousness of the problems they find, we cat-
egorize the constraints into two levels:error or warning. In the following, we discuss
some of the OCL constraints as examples:
• A relation has one source domain and one target domain (error).
contextRelationinv DomDiffKinds:
let doms:Set(QVTR::Domain)=self.ownedMember→select(oclIsTypeOf(QVTR::Domain))
→collect(oclAsType(QVTR::Domain))
in doms→one(kind=QVTR::DomainKind::source)
and doms→one(kind=QVTR::DomainKind::target)
• A QVT-R model should have at least one metamodel and one transformation (error).
contextQVTRModelinv QmodelhasMetaAndTrans:
self.ownedElement→exists(p|p.oclIsKindOf(QVTR::MetaModel))
and self.ownedElement→exists(p|p.oclIsKindOf(QVTR::Transformation))
• A transformation should have top-level relations (error).
contextTransformationinv TransHasTopRe:
self.ownedElement→select(oclIsKindOf(QVTR::Relation))
→exists(r|r.oclAsType(QVTR::Relation).isTopLevel)
• An object or link should be an instance of a classifier in the metamodels (error).
contextRelationinv RelObjHasClz:
self.ownedElement→select(oclIsTypeOf(InstanceSpecification))
172
4.8. Tool Design and Implementation
→collect(d|d.oclAsType(InstanceSpecification))
→forAll(ins|not ins.classifier.OCLUndefined())
• A non-abstract class of a metamodel is not referenced by any relation (warning).
contextClassinv ClsHasNoInstance:
not self.isAbstractimplies InstanceSpecification::allInstances().classifier→
asSet()→includes(self.oclAsType(Classifier))
The last constraint can be used to check whether every element of a metamodel has
been handled by at least one relation. If the check fails, some elements may be ignored
by the designers. With the help of CASE tools that have OCL execution environments,
we can validate these constraints against a transformation model at any time during
its design process. It is very important to guide the designers to achieve a correct and
complete transformation model.
4.8.2 QVT-R graphical editor
The concrete (graphical) syntax of QVT-R is supported by a QVT-R editor. Since we
have realized the abstract syntax of QVT-R with a UML profile, this editor can be
implemented in a UML CASE tool to minimize the effort needed to develop a new
tool from scratch, and meet the requirements for standardization and interoperabil-
ity. Theoretically, the editor can be based on any UML CASE tool, if it can: 1) edit
class diagrams and corresponding object diagrams, 2) support standard UML profiles
and the well-formedness checking of OCL constraints, and 3) output a model in XMI
format.
The current implementation of the QVT-R graphical editor builds on the top of
theMagicDraw UML [126], a popular UML modeling and CASE tool. So the users’
burden to get familiar with a new tool environment can be reduced. MagicDraw is
a commercial tool, but a free community edition is also available. It supports the
editing of all kinds of UML diagrams, definition of UML profiles, and validating of
173
4. QVTR-XSLT
Figure 4.17: The toolbar for the QVT-R graphical editor
OCL constraints. In addition, it provides a mechanism to allow quickly designing and
maintaining a new full features modeling language, through customized UML profiles
and diagrams.
Based on the QVT-R UML profile, we design a particular "QVT Relation Diagram"
and its toolbar using the MagicDraw diagram custom engine. As shown in Fig.4.17,
the toolbar contains the necessary buttons to graphically design relations and queries,
such asDomain, Object, Parameterfor query,Link, etc. Using these buttons, we can
select an element from a user-defined metamodel or the UML standard metamodel
though a pop-up window, and drop it into the diagram. Then we can set attributes and
tagged values for the element. When we draw a link between two objects, the corre-
sponding associations defined in the metamodels will show up in a pop-up window, so
we can select the one we want. With a text input box, we can edit and check the syntax
of the OCL expressions for thewhenandwhereclauses.
Furthermore, we can validate the design at any time during the design process by
just pressing the "check" button in the graphical editor. Then each constraint defined in
the profile will be evaluated against parts or the whole of the transformation model. El-
ements that violate the constraints (evaluating tofalse) are reported in a results window,
and also shown in diagrams surrounded by red boxes. Fig.4.18shows a screenshot of
the popup window for validation.
Using this graphical editor, we can define metamodels as simple class diagrams,
specify relations and queries using QVT-R graphical notation, edit functions in textual
174
4.8. Tool Design and Implementation
Figure 4.18: Validating the transformation model
style using OCL or XSLT, and finally save them as a transformation model in XMI
format. We feel that it is quite easy and user-friendly to design QVT-R rules in the
editor, because all objects and links are restricted by selecting from the source and
target metamodels, effectively providing a graphical domain-specific language. Such
syntax-directed editing should reduce the number of errors, as it only permits mostly
well-typed models.
Evaluating the syntax conformance As shown in the examples of Fig.4.23-4.29,
in our tool, a relation is displayed inside a UMLpackagebox, where its name is in the
middle top of the box with tag«Relation», and thewhenandwhereclauses are in the
top part of the box, prefixed with "when=" and "where=", respectively. Then the label
[isToplevel] follows if the relation is a top-level one. A domain patterns is displayed
as a special kind of object diagram, where the root object template is labeled with
tag«Domain». Note that a property variable in the diagrams may contain additional
quote-characters that are an artifact of the visualization, and not string delimiters. The
relation symbol is put between the two domain patterns, and the primitive
domains decorated with tag«PrimitiveDomain» are located just above the symbol.
The concrete graphical syntax of QVT-R is defined in page 39-46 of the specifi-
cation [134] through examples followed by explanations. It is said on page 40: "we
propose to use object diagrams with some extensions to specify patterns within a rela-
175
4. QVTR-XSLT
tion specification". In addition, page 46 states:
• Name of the relation. The name of the relation may appear anywhere in the
drawing page.
• where and when clause. These may appear as shown or may be hidden and
shown optionally or shown in a separate frame.
So even if at first glance our diagrammatic representation for relations looks a
little different from the example drawings given in the specification, we consider our
graphical representation conforming to the QVT-R standard.
4.8.3 XSLT code generator
Figure 4.19: The XSLT code generator
We developed the code generator using XSLT itself to realize the design ideas
described in the previous sections. The code generator reads in the XMI file of the
QVT-R transformation model produced by the graphical editor, traverses and analyzes
the model structure to collect information, parses the OCL expressions, and generates
176
4.8. Tool Design and Implementation
an XSLT stylesheet that implements the QVT-R transformation. The generated XSLT
stylesheet contains only pure XSLT code without extensions, so it can be directly exe-
cuted by any XSLT processor.
As shown in Fig.4.19, we have designed an user interface for the code generator.
It is programmed with Java and uses a Saxon 9 XSLT processor to execute the XSLT
programs of the code generator. Using the interface, we can load a transformation
model, select the transformation we want to generate XSLT stylesheet for, and indicate
if we like to produce a trace model.
In addition, we have developed atransformation runner, also in the form of a Java
program invoking the Saxon 9 XSLT processor, to facilitate the execution and analysis
of generated XSLT stylesheet. The transformation runner loads and executes an XSLT
transformation, displays the execution time, and generates the trace model if required.
4.8.4 A collection of predefined transformations
In particular, we developed a number of transformations and higher-order transforma-
tions as part of the tool, for the purpose of transformation validation and verification,
as well as for helping to exchange QVT-R rule and metamodel definitions with other
QVT tools. These transformations are defined using the QVTR-XSLT tool itself. They
can also sever as examples for the end user to learn how to use the tool. The following
transformations are included the collection:
• QVT-R graphical notation to textual notation: generates the textual representa-
tion from a transformation model designed in the QVT-R graphical editor. The
textual representation can be used for manually checking the transformation, or
as the input for other QVT-R engines, for example, medini QVT;
• Metamodel to XML Schema: generates XML Schemas from the metamodels
defined in a transformation model. XML tools can validate the source and target
models as XMI files against the XML Schemas;
177
4. QVTR-XSLT
• UML sequence diagram, state diagram, activity diagram to CSP: generates CSP
specifications to check trace equivalence or deadlock freedom of the UML dia-
grams.
• UML metamodel to Ecore, and Ecore to UML metamodel: facilitate the model
exchange between our tool and other QVT-R tools.
• Multiplicity to OCL: the generated OCL expressions can be used to check the
multiplicity conformance of a UML class model.
4.9 Case Studies
We have tested the viability of our approach and the practicability of the implementa-
tion tool with a set of case studies. A simple evaluation of the tool is given in the first
case study by comparing with medini QVT [117]. In the second case study, we use a
suite of popular queries to query the model of UML Superstructure.
4.9.1 Simple UML to simple RDBMS transformation
This case study is a slight variation of the well-known UML model to RDBMS trans-
formation taken from [134]. Also this example is relative simple, it is well suited to
demonstrate ideas and technical details of a transformation language [21]. For com-
parison purposes, we take themedini QVTas a reference implementation of QVT-R,
and execute the same transformation with it.
Using the QVTR-XSLT tool, we provide the transformation with appropriate meta-
models: we use the UML metamodel depicted in Fig.4.20as the source metamodel,
and a RDBMS metamodel shown in Fig.4.21as the target metamodel. In order to com-
pare with medini QVT, the metamodels are configured to support ecore models. For
the RDBMS metamodel, thenameproperty is the identifier (key), and eachforeignKey
refers to atable. Theid property is the identifier for the UML metamodel.
178
4.9. Case Studies
As shown in Fig.4.23-4.29, we design the UML to RDBMS transformation as
seven QVT-R relations:
• PackageToSchema: a package in the UML model corresponds to a schema in the
RDBMS model.
• ClassToTable: each persistent class of the package maps to a table with a primary
key and an identifying column in the corresponding schema.
• AttributeToColumn: deals with different kinds of attributes by invoking corre-
sponding relations.
• PrimitiveAttributeToColumn: attributes of primitive data types are translated into
columns of the corresponding table.
• SuperAttributeToColumn: invokes the relationAttributeToColumnto translate
attributes inherited from the class hierarchy.
• ComplexAttributeToColumn: an attribute of a complex data type maps to a set
of columns corresponding to all attributes of the class, which the complex data
type referred to, prefix the names of the columns with the name of the referred
class.
• AssocToFKey: an association between two persistent classes is mapped to a for-
eign key in the table corresponding to thesourceclass of the association, and the
foreign key refers to the table corresponding to thetargetclass of the association.
where the top-level relationPackageToSchema(Fig. 4.23) is the start point of the
transformation. It provides the context necessary to apply the subsequent relations.
Fig. 4.22depicts a screenshot of the transformation model.
The XSLT code generator of our tool reads in the transformation model, and pro-
duces an output XSLT stylesheet. As an example, the generated XSLT rule template
179
4. QVTR-XSLT
PrimitiveDataType
kind : String
Class
PackageElement
Association
Package
Attribute
name : Stringid : String
ModelElement
Classifier type
1
destination
1
forward0..*
general 0..1
source1
reverse
0..*
ownedElement 0..*
namespace 1
attribute
0..*
type : String
Column
name : String
ModelElementSchema
ForeignKey
Table
Key
1..*
column
1
rkey 0..1
refersTo11rkey 0..*
1..*
Figure 4.20: Simple UML metamodel Figure 4.21: Simple RDBMS metamodel
<<Relation>>
PackageToSchema
{isTopLevel}
name = "pn"
<<Domain>>
s : Schema
name = "pn"
<<Domain>>
p : Package
Figure 4.22: The transformation model Figure 4.23: The root relation
for relationClassToTableis illustrated in Listing4.1. The seven QVT relations of the
case study, along with a user-defined function that converts the UML primitive types
to the data types of RDBMS, and anxmiRefsfunction which retrieves elements of the
UML XMI model through the keys, translate to an XSLT stylesheet about 210 lines of
code (without producing trace information).
Transformation execution and evaluation. To test the transformation, we borrowed
the source model from theUML2RDBMScase study of the medini QVT tool package.
This simple ecore model describes the structure of a tiny library system with 6 classes
180
4.9. Case Studies
<<Relation>>
ClassToTable
{when=PackageToSchema(p,s);,where=prefix=cn; AttributeToColumn(c,t,prefix);}
{isTopLevel}
kind = "’Persistent’"
name = "cn"
<<Domain>>
c : Class
name = "cn+’_tid’"
type = "’NUMBER’"
cl : Column
name = "cn+’_pk’"
k : Key
name = "cn"
<<Domain>>
t : Table
p : Package s : Schema
rkey
namespace
column
rkey
<<Relation>>
AttributeToColumn
{where=PrimitiveAttributeToColumn(c, t, prefix);ComplexAttributeToColumn(c, t, prefix);
SuperAttributeToColumn(c, t, prefix);}
<<PrimitiveDomain>>
prefix : String
<<Domain>>
t : Table
<<Domain>>
c : Class
Figure 4.24: Class to table Figure 4.25: Attribute to column
<<Relation>>
AssocToFKey
{when=PackageToSchema(p,s);ClassToTable(sc,srcTbl); ClassToTable(dc,destTbl);,
where=fkn = scn+’_’+an+’_’+dcn;}{isTopLevel}
kind = "’Persistent’"
name = "dcn"
dc : Class
kind = "’Persistent’"
name = "scn"
sc : Class
name = "an"
<<Domain>>
a : Association
name = "fkn"
<<Domain>>
fk : ForeignKey
destTbl : Table
srcTbl : Table
p : Package s : Schema
source destination
refersTo
namespace
<<Relation>>
PrimitiveAttributeToColumn
{where=cln = if prefix = ’’ then an else prefix + ’_’ + an endif;sqltype = PrimitiveTypToSqlType(pn) ;}
name = "pn"
p : PrimitiveDataType
<<PrimitiveDomain>>
prefix : String
name = "cln"
type = "sqltype"
cl : Column
name = "an"
a : Attribute
<<Domain>>
t : Table
<<Domain>>
c : Class
type
attribute
Figure 4.26: Association to foreign key Figure 4.27: Primitive attribute to column
and 59 features in total. It conforms to our UML metamodel. Using the transformation
runner, we executed the generated XSLT stylesheets, both with and without producing
trace information, in a laptop of Intel M330 2.13 GHz CPU, 3 GB memory, and running
a Windows 7 home version. Table4.4shows the execution times, which include times
for loading and saving model files from/to disk.
In order to test the transformation in medini QVT, we first exported the definitions
of both source and target metamodels from the transformation model using the prede-
fined UML metamodel to Ecore transformation. Then theQVT-R graphical notation to
181
4. QVTR-XSLT
<<Relation>>
ComplexAttributeToColumn
{where=newprefix = prefix + ’_’ + an; AttributeToColumn(tc, t, newprefix);}
<<PrimitiveDomain>>
prefix : String
name = "an"
a : Attribute
<<Domain>>
t : Table
<<Domain>>
c : Class
tc : Class
type
attribute
<<Relation>>
SuperAttributeToColumn
{where=AttributeToColumn(sc,t,prefix); }
<<PrimitiveDomain>>
prefix : String
<<Domain>>
t : Table
<<Domain>>
c : Class
sc : Class
general
Figure 4.28: Complex attribute to columnFigure 4.29: Attribute in super class to col-umn
Table 4.4: Comparison of execution time (ms)
QVTR-XSLT medini QVT
with trace 22 90without trace 7
textual notationtransformation was used to generate the textual representation of the
transformation. Finally the ecore metamodels and the transformation in textual format
were imported into medini QVT tool, and executed on the same source model with an
empty target model in the same laptop. As shown in Table4.4, the execution taken
in total about 90 ms, of which 40 ms was used to evaluate the transformation, and
the other time was for parsing and analyzing the transformation, loading and saving
source, target and trace models.
The results from the QVTR-XSLT tool and the medini QVT were compared both
manually and automatically with an XSLT program. The generated target models from
both tools are identical. Furthermore, both trace models are semantically equivalent in
the sense that for each trace instance of relation in the medini QVT trace model, there
exists one relation instance in the QVTR-XSLT trace model, that both of them contain
same object references, and vice versa. List4.2 shows an excerpt of the medini QVT
trace model, and List4.3 for the QVTR-XSLT trace model. We find that our trace
182
4.9. Case Studies
<xmi:XMI xmlns:umlTOrdbms="urn:umlTOrdbms .ecore"><umlTOrdbms :PackageToSchema>
<p href="source.xmi#_pXZ9wKS6EduN8Krm−aC8vQ"/><s href="target.xmi#myPackage"/>
</umlTOrdbms :PackageToSchema><umlTOrdbms :ClassToTable>
<c href="source.xmi#_pXZ9waS6EduN8Krm−aC8vQ"/><t href="target.xmi#Library"/><p href="source.xmi#_pXZ9wKS6EduN8Krm−aC8vQ"/><s href="target.xmi#myPackage"/><cl href="target.xmi#Library_tid"/><k href="target.xmi#Library_pk"/>
</umlTOrdbms :ClassToTable><umlTOrdbms :AttributeToColumn prefix="Library">
<c href="source.xmi#_pXZ9waS6EduN8Krm−aC8vQ"/><t href="target.xmi#Library"/>
</umlTOrdbms :AttributeToColumn>......
</xmi:XMI>
Listing 4.2: Excerpt of medini QVT trace model
<Transformation name="umlTOrdbms" source="uml" target="rdbms"><relation name="PackageToSchema">
<obj name="p" href="_pXZ9wKS6EduN8Krm−aC8vQ"refname="myPackage" model="uml"/>
<obj name="s" href="myPackage" model="rdbms" op="c"/></relation><relation name="ClassToTable">
<obj name="c" href="_pXZ9waS6EduN8Krm−aC8vQ"refname="Library" model="uml"/>
<obj name="p" href="_pXZ9wKS6EduN8Krm−aC8vQ"refname="myPackage" model="uml"/>
<obj name="t" href="Library" model="rdbms" op="c"/><obj name="cl" href="Library_tid" model="rdbms" op="c"/><obj name="k" href="Library_pk" model="rdbms" op="c"/><obj name="s" href="myPackage" model="rdbms"/>
</relation><relation name="AttributeToColumn">
<primitiveDomain name="prefix" href="Library"/><obj name="c" href="_pXZ9waS6EduN8Krm−aC8vQ"
refname="Library" model="uml"/><obj name="t" href="Library" model="rdbms"/>
</relation>......
</Transformation>
Listing 4.3: Excerpt of the QVTR-XSLT trace model
model misses the information about names of model files, but theop="c" expressions
in our trace model indicate at which relation instance the particular object is created.
183
4. QVTR-XSLT
This feature could be helpful in debugging.
Since medini QVT is known as one of the two tools that faithfully implement the
standard of QVT Relations, the comparison results provide favorable evidence that the
QVTR-XSLT tool supports the basic semantics of QVT-R.
Regarding the performance issues, even though the source model is too small to
give sufficient evidence, we can still judge that our transformation runs faster than
medini QVT, especially in case of outputting no trace information. That is partly due
to the XSLT processor (Saxon 9.2) we used must be more powerful than the interpreter
of medini QVT. Another possible reason is that XSLT don’t need to build a different
in-memory model, and saving the time for converting between in-memory and storage
models.
4.9.2 Model querying examples
Basically, a query in the QVTR-XSLT tool consists of two parts: the diagram represen-
tation and the textual area, where the OCL expressions can be imput as thewhenand
whereclauses. So this tool allows us to run arbitrary queries with only OCL expres-
sions, that means QVT-R graphical queries are at least as expressive as the pure OCL
queries defined by the QVT specification. Now, the crucial question is, whether creat-
ing and/or understanding the QVT-R graphical queries is easier than using only OCL.
In order to find out, we have tested the graphical query tool with a suite of popular
queries discussed in [42; 159].
The queries are tested on the model of UML superstructure version 2.41. The
model is a typical EMOF model that includes 11 packages, 341 classes, and in total
about 9500 model elements stored in an XMI file of about 1.7 MB in size. We design a
QVT-R transformation to collect and execute these queries. This transformation takes
the UML superstructure model as the source model, and outputs a html file to show the
query results.
184
4.9. Case Studies
+#title : String
Head
+#td : String
TrTable
Html
Body
1..*
1
1..*
1
Figure 4.30: Target metamodel
<<Relation>>
QueryUML
{where=clsNum=CountClass();Display(uml,tb,’Number of classes’,clsNum);}
{isTopLevel}
#title = "’Queries on UML superstructure model’"
: Head
<<Domain>>
uml : UMLModel
<<Domain>>
htm : Html
tb : Table
: Body
Figure 4.31: Top-level relation
Figure 4.32: Display query result
Using the QVTR-XSLT tool, we configure the transformation with appropriate
metamodels: we use a slight variant of EMOF model as the source metamodel, and
a simple HTML metamodel shown in Fig.4.30as the target metamodel. The transfor-
mation includes two relations: the top-level relationQueryUML(Fig. 4.31) that starts
the transformation, and relationDisplay (Fig. 4.32) puts the result of a query into the
html model. The relationQueryUMLalso creates an empty html model, invokes the
queries from thewhereclause, and sends the results to relationDisplay. After the
queries are specified in the editor, we generate an XSLT stylesheet for the transforma-
tion using the code generator. The stylesheet is executed in thetransformation runner
that reads in the source model, and outputs the result html file, meanwhile it shows the
execution time.
185
4. QVTR-XSLT
4.9.2.1 The set of queries
The queries we discuss here are frequently used for model analysis and are of different
complexity and structure. The first three search the entire model to retrieve the results,
while the following three are local queries, which starts the matching from a context
model elements. The simple queries return a single value by element counting, more
complex ones require recursive query calls.
<<Query>>
CountClass
{result=cls->size();}
<<Domain>>
: Package
{forAllSub}
cls : Class
Figure 4.33: Count number ofclasses
<<Query>>
GetClsWithAssoNum
{result=cls->select(ownedAttribute.association ->size()=assoNum);}
<<Parameter>>
assoNum : Integer
<<Domain>>
: Package
{forAllSub}
: Association : Attributecls : Class
ownedAttribute
Figure 4.34: Classes with number of associations
Count elements of a given type: The first query is to retrieve the number of over-
all elements of a given type, say, classes, in a model. The queryCountClassshown
in Fig. 4.33 counts the number of classes contained in all packages. We setthe
forAllsub feature of thePackage to true. The OCL functionsize() is used to
count the number, then the result is returned by variableresult. The code generator
produces the following XSLT function for the query:
<xsl:function name="my:CountClass">
<xsl:variable name="cls" select="$xmiXMI//packagedElement[@xmi:type=’uml:Class’]"/>
<xsl:variable name="result" select="count($cls)"/>
<xsl:sequenceselect="$result"/>
</xsl:function>
186
4.9. Case Studies
where$xmiXMI is the global variable representing the whole model. If the query is
defined in pure textual OCL, we have to use theallInstances construct, such asClass.all
Instances()->size().
All classes with a given number of associations: The queryGetClsWithAssoNum
shown in Fig.4.34obtains a list of classes with a given number of associations.The
parameterassoNum passes the number to the query. The OCL expression in thewhere
clause uses theselectoperation to choose the classes which have that number of out-
going associations. The OCL expression is implemented by the following XPath ex-
pression:
<xsl:variable name="result"
select="$cls[count(ownedAttribute[@xmi:type=’uml:Property’]/@association)=$assoNum]"/>
This query can be used to check if modeling guidelines are adhered to. With such
a query one could find the classes which have too many or too few associations. A
reference definition for the query using OCL is given in [42]:
contextClass
def:getAssociationsFromClass():Set(Association)=
self.ownedElement→asSet()→select(a|a.oclIsTypeOf(Property)).
oclAsType(Property).association→select(a|not(a=null))→asSet()
contextPackage
def:getAllClasses():Set(Class)=
self.packagedElement→asSet()→select(t|t.oclIsKindOf(Class)).oclAsType(Class)→asSet()
def:getClassesWithNumberOfAssociations(NoA:Integer):Set(Class)=
self.getAllClasses()→asSet()→select(c|c.getAssociationsFromClass()→size()=NoA)
It is obvious that the OCL specification is more complicated, and relatively difficult to
understand, comparing to its graphical representation in our query facility.
Maximal depth of class inheritance: Similar to the previous one, this query can
also be used to check if modeling guidelines are followed. The depth of the class
187
4. QVTR-XSLT
<<Query>>
GetMaxDepth
{depths=cls-> iterate(c|CountSuper(c,0));
result=max(depths);}
<<Domain>>
: Package
{forAllSub}
cls : Class
Figure 4.35: Maximal depth of inheritance
<<Query>>
CountSuper
{cnum=num+1;supers=if sc.oclIsUndefined() then cnum else
sc->iterate(s|CountSuper(s,cnum)) endif;result=max(supers);}
: Generalization
<<Domain>>
c : Class
<<Parameter>>
num : Integer
<<Parameter>>
c : Class
sc : Class
general
Figure 4.36: Number of super classes
inheritance is a typical metric in object oriented modeling or programming. Fig.4.35
shows the queryGetMaxDepthspecified in the graphical notation. For each classc in
the setcls, the queryCountSuper(see Fig.4.36) is iteratively called to get a collect
of depth numbers. The queryCountSuperagain recursively calls itself to count the
number of super classes. A notable feature of our query facility is that a set of standard
functions defined in XPath can be mixed with OCL operations. As an illustration, we
directly use XPath functionmax here to get the maximal one in a collection instead of
its OCL counterpart.
The OCL specification for this query given in [42] consists of three user-defined
operations, in total 26 lines of complex OCL code. However, Dr. Ed Willink of the
GMT Consortium provides a more concise reference implementation for the query:
contextClass
def: depth() : Integer =
if superClass→notEmpty()then superClass.depth()→max()+1 else 0endif
def:GetMaxDepth(): Integer =
let allPackages : Set(Package) = self→closure(nestedPackage)in
let allClasses : Set(Class) = allPackages.ownedType→
select(oclIsKindOf(Class)).oclAsType(Class)in allClasses.depth()→max()
Textual pattern matching: One of the most frequent queries is to do a text search
for a given string over a model. However, regular expressions are still not supported
188
4.9. Case Studies
<<Query>>
FindName
name = "’Action*’"
result : NamedElement
{forAllSub}
<<Domain>>
p : Package
<<Parameter>>
p : Package
Figure 4.37: Find elements by name
<<Query>>
GetAttributeName
{not} : Association
name = "result"
visibility = "’public’"
: Attribute
<<Parameter>>
c : Class
<<Domain>>
c : Class
: Type
association
ownedAttribute
Figure 4.38: Getting attribute names
in the OCL specification. An example query might be "find all model elements whose
names begins with ”Action” in a package". Fig.4.37depicts this query. In the EMOF
model, theNamedElement is an abstract class. It is the superclass for all elements that
have names. In the corresponding path expression, we put a wildcard ”∗” just after the
”//” operator to match all elements. Since there is also a ”∗” in the string’Action*’
that is bound to thepropertyTempname, we take the string as a regular expression.
In the implementation, XPath functionmatches() is used to test whether the names
matches the regular expression:
<xsl:function name="my:FindName">
<xsl:param name="p"/>
<xsl:variable name="result" select="$p//∗[matches(@name,’Action∗’)]"/>
<xsl:sequenceselect="$result"/>
</xsl:function>
More complicated regular expressions can also be used in the queries for textual pattern
matching, either bound to thepropertyTemps, or as the arguments of thematches()
functions appearing in thewhereclauses.
Structural matching for existing and non-existing elements: The queryGetAt-
tributeNameshown in Fig.4.38gets a set of names of primitive attributes in a given
189
4. QVTR-XSLT
class. The query selects a primitive attribute by (1) it owns an element ofType; (2) it
does not have anassociationlink; (3) its visibility is public.
4.9.2.2 Experiments
Table 4.5: Results of the first three queries
Name Explanation Result Time
CountClass count all classes of the model 331 78msGetClsWithAssoNum(3) classes with a given number of asso. 30 65msGetMaxDepth maximal depth of class inheritance 10 15s
Using ourtransformation runner, we execute the queries on the model of the UML
superstructure in a laptop of Intel M330 2.13 GHz CPU, 3 GB memory, and run-
ning a Windows 7 home version. The results of the first three queries are shown in
Table4.5. For the queryGetClsWithAssoNum, we use 3 as the value for the parame-
ter, and the table only shows the number of classes found. As depicted in the table,
there are in total 331 classes in the model, 30 of them have 3 associations to other
classes. The maximal depth of class inheritance is 10. One of the inheritance paths is
Device�Node�Class�EncapsulatedClassifier�StructuredClassifier
�Classifier�Type�PackageableElement�NamedElement�Element. Inci-
dentally, this example illustrates the complexity of the UML metamodel.
The execution time includes loading and saving model files from/to the hard disk.
The performance and the memory needed are much dependent on the XSLT proces-
sor used. We can see from the results that the first two queries works well, and the
straightforward algorithm of the third query needs to be optimized.
4.10 Summary
Despite the fact that the QVT Relations offers graphical notation, most of the current
work on QVT model transformations adopt textual style languages. It is somehow
190
4.10. Summary
surprising because they operate on MOF metamodels that are graphically specified as
UML class diagrams. With the widespread use of UML, people are already used to
visually view software systems and software models as diagrams. Transformations
based on UML-like metamodels might be expected to continue the graphical tradition
of class diagrams and favor a graphical notation [173].
We believe that a good transformation language should take the advantage of both
textual and graphical notations, and keep a balance between these two presentation
styles. In view of this, the graphical notation of QVT-R provides a good candidate.
Complemented with textual OCL expressions, the graphical notation of QVT Relations
provides a concise, intuitive, and yet expressive way to define model transformations.
In this chapter we present our work on a practical model transformation approach
and tool to support the graphical syntax of QVT-R. In our approach, a QVT-R transfor-
mation is implemented as an XSLT stylesheet, where every relation maps to an XSLT
rule template. We support unidirectional non-incremental enforcement transformations
of QVT Relations. The features supported by the approach include transformation in-
heritance through rule overriding, traceability of transformation executions, multiple
input and output models, and in-place transformations. In addition, to improve the
usability of QVT-R, we extend the language with additional transformation parameter,
relation alias name and priority, as well as conditional relation call. We also pro-
pose a novel graphical model query facility, which is based on the checking semantics
and pattern matching of QVT Relations, and also borrows its graphical notation. The
model query facility can work seamlessly within the QVT-R transformations. How-
ever, we still cannot support all features of QVT-R, especially itscheck-before-enforce
semantics.
We have developed a tool, named QVTR-XSLT, for supporting the approach. Based
on a UML profile that implements the abstract syntax of QVT-R, the graphical editor of
the tool supports the definition of metamodels, specification of QVT-R transformations
and queries using the graphical notation. The code generator of the tool automatically
191
4. QVTR-XSLT
translates the QVT-R transformations into executable XSLT programs.
Our approach and tool are founded on the standards introduced by OMG and W3C,
and make use of well-known and commonly adopted CASE tools and languages. The
generated XSLT programs for the transformations can be directly executed under any
XSLT processor on any platform, and can be easily integrated into other applications
and systems. As there are already many industrial-strength XSLT processors, such as
SaxonandXalan, our transformations can efficiently process large-scale models.
The benefits of our tool are two-fold: provide QVT users with a practical tool
to specify and execute transformations in graphical notation, and meanwhile provide
XSLT users with a high-level, declarative method to design XSLT stylesheet. Using
the tool, we have successfully designed a set of complicated model transformations
to meet the development requirements of therCOS modeler, as we will discuss in the
next chapter.
192
Chapter 5
A UML Profile for rCOS
Integrating the rCOS method into UML opens up a powerful way to support CB-MDD.
The rCOS supplies UML with a precise semantics, additional modeling concepts for
component composition, formal consistency verification and refinement techniques,
and a design methodology based on correctness preserving model transformations. On
the other hand, the advantage of combining with UML is the possibility to specify
a system with a unified, standardized graphical notation, which improves common
understanding of models between developers and stakeholder involved in the develop-
ment of the system. Thus rCOS could potentially reach a wider user-base.
In addition, representing rCOS in UML opens the way to use many available UML
tools for rCOS, saving development effort and time. By using XMI, an rCOS model
can be seamlessly linked to other development tools. Thus the rCOS method can be
fully integrated into the whole development process of a software system, and enables
the interoperation and data exchange with other notations and tools, therefore facilitat-
ing and improving the reusability of models.
There are several mechanisms to integrate a formal method into UML. Because of
the crucial requirement for standardization in software development, we adopt a strat-
egy of customizing UML using its built-in extension mechanism. This mechanism is
carried out by using UML profiles [64] which describe how UML model elements are
extended to support a particular modeling method. The main concepts of UML profile
and the approach we use to define UML profile have been discussed in Section2.3.2.
In this chapter, we present a UML profile for rCOS, through which the rCOS tech-
niques and methodology can be applied to component-based software development in
a standard, model-driven way. We first briefly review the major concepts of rCOS us-
ing a metamodel in Section5.1. On the basis of the metamodel, Section5.2presents a
193
5. A UML Profile for rCOS
UML profile for rCOS, and defines the UML artifacts used in rCOS. In Section5.3, we
discuss implementation of the profile in a CASE tool and how the rCOS development
process is supported by the tool. We mention some related work in Section5.4 and
outline some conclusions in Section5.5.
5.1 A Metamodel of rCOS
As rCOS has been introduced in Chapter3, here we review only the major concepts and
features of the rCOS language using a MOF compliant metamodel, so as to facilitate
the definition of the rCOS profile. The description focuses on the syntactic aspects.
Using the standard metamodeling language MOF, we can represent each concept of the
rCOS language as a MOF element and enhance it with OCL constraints that preserve
its original semantical meanings in rCOS.
The rCOS metamodel consists of four packages:Type, Class, ComponentandRCOSP.
The latter three have dependencies on theTypepackage. TheRCOSPpackage defines a
Java-like textually specification language, which has been presented in BNF format in
Section3.2.1. We will not discuss this package in this section. To keep the metamodel
at an abstract level and not overpopulate it with unnecessary details, most attributes of
the meta-classes are hidden, for example, thenameof each model element.
5.1.1 Types and classes of rCOS
Types As illustrated in Fig.5.1, theTypespackage contains data types used in rCOS.
A typemay be aclass, which is the type of an object in a system, or may be aprimitive
type, such asBoolean, Integer, or String. A collective type, such asSet, is a collection
of elements whose type is already defined in the package. For example,Set(T)is the
type of sets of typeT. We define a set of operations, such asadd, containsandremove,
for thecollective typewith their standard semantics. For example, for a variables of
typeSet(T), the operations.add(a)equalss′ = s ∪ {a}, ands.contains(a)equalsa ∈ s.
194
5.1. A Metamodel of rCOS
add( a : Type )remove( a : Type )contains( a : Type ) : Booleanempty() : Booleansize() : Integer
CollectiveType
UnlimitedNatural
PrimitiveType
find( a : String )
Set
Type
Boolean
Integer
Double
String
Class
Char
Void
baseType
Figure 5.1: Types package of rCOS metamodel
For aSet swhere each element has an identifierid, the operations.find(a)denotes the
function that returns the element whoseid equals toa if there is one, or returnsnull
otherwise.
new()
Class
protectedprivatepublic
<<enumeration>>
Visibility
visibility : Visibility
Field
visibility : Visibility
Method
Expression
Parameter
Command
Type
body
0..1
init 0..1
1
type
extends
0..1
0..*out0..*in1 type
attribute 0..* 0..*
Figure 5.2: Class package of rCOS metamodel
Classes Like most OO languages, rCOS has its class model with the notions of
classes, associations or attributes, and inheritance, to represent the application domain
concepts. Fig.5.2 depicts the rCOS class metamodel. Aclasshas a distinct name,
195
5. A UML Profile for rCOS
and it can beextendedfrom a super class, so, there is no multiple inheritance. The
operationnew() creates a new object of the class.
A classdeclaration consists of two parts: a set offields (attributes) and a set of
methods. Fields define the static attributes of the class. They have avisibility annotation
(private, protected, or public), and their types are defined in the type package. A field
may have aninitial expressiondefining the allowable initial values. The language
neither offers attribute overriding nor multiplicity. Multiplicities can be modeled by
using thecollection types.
A method declaration consists of the method name, its value (in) parameters, re-
sult (out) parameters and the body. We can have different scopes of visibility for the
methods, by default they are public. Because rCOS is used as a specification language,
it allows a method to return a number of outputs. A methods can be inherited by a
subclass, and a method is allowed to be overridden in a subclass, but its signature,
i.e. types of parameters, should be preserved. The body of a method defines its data
functionality at different levels of abstraction, from apredicatespecified in the form
of UTP designpre ⊢ post to program code.
5.1.2 Components of rCOS
Thecomponentspackage, as shown in Fig.5.3, defines the component-based modeling
concepts of rCOS. An rCOSinterface, which is a syntactic notion providing an interac-
tion point for a component, is a declaration of a set offieldsandmethods. Particularly,
we define internal autonomousactions. An action, which likes a method without pa-
rameters, can be executed atomically in a state in which its guard condition holds. In
addition, an interactionprotocolof the interface is a set of finitetracesover theeventsof
method calls. In principle, regular expressions, finite state machines, or finite CSP pro-
cesses can be used to describe the traces. A protocol defines the permissible sequences
of method invocations from the environment when interacting through the interface.
196
5.1. A Metamodel of rCOS
Component
Interface
kind : ConnectorKind
Connector
rename
parallel
hideplug
<<enumeration>>
ConnectorKind
Protocol
Method
Action
Trace
Predicate
Field
Event
{sequence}
ProcessService
init 0..1
calls
1
interaction
1
compose
1..*
provided 0..*
implement 0..1
required 0..* internal0..*
1..*
1..* 0..*0..*
Figure 5.3: Components package of rCOS metamodel
Moreover, theinitial predicate specifies the allowable initial states of the interface.
A component may provide services that are defined by theprovided interfaces. The
component is responsible for implementing its provided interfaces, either by the com-
ponent itself or through some (interface) classes. On the other side, a component may
need to use the services provided by other components. These services are called re-
quired services and are represented asrequired interfaces. Similarly, the protocol of the
required interface specifies the requirements on how the required component should
provide the services. Obviously, the required protocol is determined by the protocol
of the provided interfaces. A component can also haveinternal interfacesthat declare
methods private to the component, and thus they can only be called from the provided
methods, the private methods themselves and the actions.
In rCOS, there are two kinds of components. Aservice component, component for
short, has provided interfaces, and optionally required interface. It is externally passive
and only interacts with its environment when a provided service is requested. On the
other hand, aprocess component, process for short, is active and has its own control
thread. A process has required interfaces only and it actively invokes services of other
components following its own flow of control so as to coordinate the behavior and pass
data among components.
197
5. A UML Profile for rCOS
The notion ofcomponent compositionis essential for a component-based design. A
new component can be composed hierarchically by usingconnectorsto connect exist-
ing components. In rCOS, we define the basic composition connectors forrenaming
interface methods,hiding interface methods to restrict environment access to provided
methods,pluggingthe provided interface of one component to the required interface
of another component, andparallel compositionof components.
Additionally, rCOS defines a set of notions to support component-based design.
A component without required interface is called aclosed component, otherwise an
open component. If there is no internal action in a component, it is called aprimitive
component. Thus, acomponent contractis just like aprimitive componentin which the
method bodies of the provided interfaces areguarded designs.
Contracts are important for the requirement specification and verification of the
correct design and implementation through refinements. In rCOS, each closed com-
ponent is semantically equivalent to a contract. In contrary, acomponent publication
defines as a component in which the body of each method is just a design of the data
functionality and there is a protocol defined for the provided interface. Publications
are declarative. They are more suitable for specification of components in system syn-
thesis [97].
5.2 A UML Profile for rCOS
In this section, we first briefly introduce the mapping from rCOS concepts to UML
model elements, then we discuss the models of class and interface, sequence diagram,
state machine and component, followed by presentation of the rCOS modeling archi-
tecture. In addition, we define the constraints of the profile using OCL. Here we de-
scribe the abstract syntax of the rCOS model using a mixture of EMOF class diagrams
and profile diagrams. In the following UML profile diagrams, an element in the light
yellow box represents a stereotype of rCOS, and the ones in the dark yellow boxes are
198
5.2. A UML Profile for rCOS
standard UML metamodel elements.
5.2.1 Mapping rCOS Concepts to UML
UseCaseComponent
UML
rCOS
InterfaceField Protocol
<<metaclass>>
StateMachine
<<metaclass>>
Property
<<metaclass>>
Operation
<<metaclass>>
Interface
<<metaclass>>
Component
<<metaclass>>
Constraint
<<metaclass>>
Interaction
<<metaclass>>
Class
<<metaclass>>
UseCase
Method
<<metaclass>>
Package
Class Command
body
Figure 5.4: Mapping from rCOS concepts to UML
As rCOS is a language for object-oriented and component based systems, by design
it shares a lot of features with UML. To define the rCOS profile, we first go through the
full set of rCOS concepts, and identify the most suitable UML model elements as their
base metaclasses. The selected UML model elements should have semantics which are
closest to the semantics of the domain concepts in order to get support from existing
UML tools and meet developer’s expectations on the semantics.
In fact, many rCOS concepts can be represented by UML model elements without
changing their original semantics. At most, we need to impose some additional con-
straints. For these rCOS concepts, we directly use UML concepts without introducing
stereotypes. Fig.5.4 illustrates the mapping from rCOS concepts (below the dashed
line) to UML metaclasses. The mapping is intuitive and straightforward, and we are
going to discuss the corresponding stereotypes later in this section. These stereotypes
are used throughout the entire model design and refinement process. For many of
the UML concepts mentioned here, analogous description may be extracted from the
OMG UML specification [135].
Representing rCOS views with UML diagrams. The rCOS itself does not define
any graphical notation for representing the model. The multiple viewpoints of rCOS
199
5. A UML Profile for rCOS
can be graphical represented using different UML diagrams. These diagrams not only
provide designers with a high-level intuitive understanding of the entire system, but
also can serve as a working platform to add new model elements, or refine the existing
elements selected from diagrams. That is the idea of "design by drawing".
The following diagram types are supported in the rCOS modeling. We reuses sev-
eral diagrams types from UML without any extension, and extend some of them.
• A UML use case diagram describes the business processes and services pro-
vided by the system, and their possible users - theactors.
• A UML class diagram displays the class definitions in the application domain,
and their relationships such as inheritance, association and containment. Fur-
thermore, for each (non-trivial) interface, we may also have a class diagram
to represent the interface’s main attributes and methods, its implementingcon-
troller class, and the relationships of the controller class with the domain classes.
We reuse the UML class diagrams without modification.
• For each rCOS protocol, a UMLsequence diagram can be adopted to present
the interactions between the external environment and an interface, or between
the interface and the other model elements, such as objects of domain classes,
or internal components. We define two kinds of sequence diagrams to support
both the OO and component-based design activities of rCOS. Moreover, a UML
protocol state diagram is used to present the dynamic behaviors of the inter-
face, here each transition is trigged by a method call to a method defined in the
interface.
• For each rCOS component that has sub-components, we use a UMLcomponent
diagram to describe the organization and the dependencies between the set of
sub-components, and how these sub-components are connected to the container
component. At the top-most level, a component diagram shows all the compo-
200
5.2. A UML Profile for rCOS
nents representing the use cases, and the possible relationship between them.
5.2.2 rCOS modeling architecture
The model-driven paradigm focuses on constructing of models instead of program-
ming code. While designing a large hierarchical application model, a fundamental
necessity is specifying its structure. A sound structure makes models more readable
and preserves their integrity easier over time.
UML defines the concepts ofmodel andpackage, which serve as grouping units
for other model elements. Since we need to serialize a model into an XMI file, a root
element for the model is necessary. A UMLmodel is the top level root element of a
model, and below it, thepackages. A package is used to group and organize model
elements and diagrams, and provides aname space for the grouped elements.
<<stereotype>>
ComponentModel<<stereotype>>
UsecaseModel
<<stereotype>>
ClassModel
<<stereotype>>
RCOSModel
<<metaclass>>
Package
<<metaclass>>
Model
classModel1usecaseModel 1 componentModel1
Figure 5.5: Overall structure of rCOS model
Fig. 5.5 depicts the overall structure of an rCOS model. We introduce the stereo-
type «RCOSModel» extending from UMLmodel to represent the root of an rCOS
model, and we define the stereotypes«ClassModel», «UseCaseModel» and«Component-
Model», all as extensions of UMLpackage. Thus an rCOS model consists of three
sub-models to specify different aspects of a system:
201
5. A UML Profile for rCOS
• Use case model, contains allactors, use cases and their relationships, along
with use case diagrams.
• Class model, contains all class definitions and their relationships, represented as
a set of class diagrams.
• Component model, contains a collection of components and their interfaces. It
also includes component diagrams to describe the relationships between compo-
nents, and sequence diagrams and state diagrams to specify the behaviors of the
components. At the top level, each component relates to a use case of theuse
case model. As a component itself can own other model elements, it may also
contain a set of internal components.
The rCOS model architecture also provides a basis for implementing an rCOS model
as aModel-View-Controller(MVC) style application. The MVC design pattern solves
the problems arising when applications contain a mixture of data access code, business
logic code, and presentation code. We can develop theclass modelinto a Model of
MVC, which is the domain-specific representation of the data upon which the applica-
tion operates. Thecomponent modelis implemented as theControllerof MVC, which
represents the application domain logic. Finally theuse case modelbecomes theView
of MVC, which typically forms a set of user interfaces. Similar to the basic idea of the
rCOS method, the MVC pattern isolates thedomain logic, domain datafrom input and
presentation(GUI), permitting independent development, testing and maintenance of
each [172].
5.2.3 Class and interface modeling
Like most OO program languages, rCOS has its concepts of class, method and field.
All the features have standard representations in UML. As one of the most impor-
tant UML diagrams, a class diagram is used to model the static structure of a system.
202
5.2. A UML Profile for rCOS
aggregation : AggregationKind
Association
<<stereotype>>
ObjectSequenceDiagram
Interface
isQuery : Booleanvisibility : VisibilityKind
Operation
Class
href : PrimitiveType [0..1]
Type
Classifierspecification : String
Constraint
<<stereotype>>
DesignOperation
[Operation ]
Property
<<stereotype>>
ContractInterface
[Interface]
compositenone
<<enumeration>>
AggregationKind
<<stereotype>>
ControllerCLass
Boolean
IntegerDouble
String
<<enumeration>>
PrimitiveType
protectedprivatepublic
<<enumeration>>
VisibilityKind
<<stereotype>>
ClassModel
<<stereotype>>
Protocol
[Package]
<<stereotype>>
Action
Parameter
type0..1
interface
end
2
guard
0..1
method
0..*
1
design
0..1
general 0..1
init
attribute
protocol 0..1
post 0..1pre 0..1
interaction0..1
1
Figure 5.6:ClassandInterfacemodels
Within the class diagram, we can define domain concepts asclassesand their rela-
tionships. The relationship can begeneralization, normal association, or composition.
Meanwhile, a UMLinterfacedefines a contract that represents a declaration of a set
of coherent public features and obligations. As shown in Fig.5.6, both class and
interface, as sub-classes of UMLclassifier, have similar structure, which includes:
• a set ofpropertiesthat present the structural features of a class/interface. A class
can only own properties of primitive types, and the properties of an interface can
be primitive types, or of types of classes defined in the model. Particularly, we
allow a limited amount of properties of primitive types on the interface for use
as guard conditions in related sequence diagrams.
• a set ofoperationsthat define the offered methods. An operation may own some
parameters, and its functionality can be specified by a pair of constraints aspre-
andpostconditions. In UML, a constraintis a conditional expression that can
be evaluated to aBooleanvalue. The pair of constraints specifies that if the
input parameters and the current state of the (instance of)classifiersatisfy the
precondition, then the invocation of the operation will make the postcondition
203
5. A UML Profile for rCOS
hold. An operation can be aquery(if its isQueryfeature sets totrue) that does
not change the system state. Thevisibility feature defines whether the operation
can be offered to the environment.
• a set ofinitial constraintsthat specify the allowable initial states when an in-
stance of a class is created.
As an interface is not instantiable, it can be realized by an instance of a class
through a UML interface realization. Such a class must fulfill thecontract of the
interface. That is, it must provide a public facade (attributes, operations, externally
observable behavior) that conforms to the interface [135]. In rCOS, we implement an
interface as acontroller class(use case controller) in OO design. A controller class is
a special class that initializes a system, creates permanent objects of the system, and
keeps the main flow of control of the system [12]. An rCOS«ObjectSequenceDiagram»
(will be discussed later) may be attached to a controller class to specify its behaviors.
This is the sequence diagram that is really used in the OO design of applying expert
pattern.
For supporting rCOS, we define stereotype«DesignOperation» as an extension of
UML operation to represent rCOSmethod. An additional constraint is introduced with
the namedesignto specify the static functionality of the method, and aguard con-
straint specifies the guard condition if the method has aguarded design. Meanwhile,
we introduce stereotype«Action» as a subclass ofdesign operationto support rCOS
actionsthat can be executed atomically in a state in which its guards holds, and change
the system states. Moreover, we define stereotype«ContractInterface» to represent an
interface with an behaviorprotocol.
5.2.4 Component modeling
The rCOS employs components to specify hierarchical structuring, reuse, and evolu-
tion of large and complex models. Supported by required and provided interfaces,
204
5.2. A UML Profile for rCOS
<<stereotype>>
RCOSSequenceDiagram
[Interaction]
<<stereotype>>
ServiceComponent
<<stereotype>>
ProcessComponent
InterfaceRealization
<<stereotype>>
RCOSComponent
[Component]
<<stereotype>>
ComponentModel
<<stereotype>>
ContractInterface
<<stereotype>>
ContractInterface
<<stereotype>>
ControllerCLass
Usage
<<stereotype>>
RCOSUseCase
[UseCase]
StateMachine Collaboration
<<stereotype>>
Protocol
[Package]
CallEvent
0..1
0..*
0..1
interaction 0..1
0..*
component
provided 0..1
client
realizingClassifier0..1
0..*
0..1
required
0..1
supplier
protocol
0..*
supplier client
0..1
1
contract
Figure 5.7: Modeling rCOS component
components are composed together via the composition operators, and can be visual-
ized using component diagrams.
UML offers more complex concepts than rCOS to specify components, their con-
necting and realization. A detailed discussion of UML components is out of the scope
of this thesis. In order to encode rCOScomponentsandcompositionin a compact
way, while supporting the semantics of rCOS, we define the rCOS component model,
shown in the UML profile diagram of Fig.5.7, which consists of:
• ContractInterface: Mapped from rCOSinterface, a contract interface provides
an interaction point for a component, and defines the static portion of an rCOS
interface contract. For ease of layout of the diagram, the samecontract interface
element appears twice in Fig.5.7.
• Protocol: A contract interface has aprotocol that specifies the traces of invoca-
tions to the methods of the interface. A protocol is a UML package that contains
a state machine, a collaborationand a set ofcall events. A call event is an in-
vocation to an operation of the contract interface, resulting in the execution of
205
5. A UML Profile for rCOS
the called operation. Especially, a collaboration owns a UMLinteractionde-
fined as anRCOSSequenceDiagram. The rCOS defines separate protocols for
the provided and required interface of a component. For a provided interface,
we usually have both a sequence diagram and a state machine as its protocol,
but only a state machine is attached to a required interface in order to calculate
interface composability.
• RCOSComponent: We map an rCOScomponentto the abstract stereotype
«RCOSComponent» as an extension of UML meta-class component, and we de-
fine the stereotypes«ServiceComponent» and«ProcessComponent» to represent the
two kind of components in rCOS. A component itself may also have an rCOS se-
quence diagram to specify the interactions between its internal sub-components.
Moreover, we define stereotype«RCOSUseCase» to represent use cases in rCOS,
each of them is modeled by an rCOS component.
In the component model, we realize the connection between a component and its pro-
vided interface using a UMLinterface realization. A UML usage, a specializedde-
pendencyrelationship, is used to link a required interface to its owner component.
Meanwhile, theinternal interfaceis directly owned by a component.
<<stereotype>>
Delegation
[Dependency]
<<stereotype>>
Composition
[Dependency]
<<stereotype>>
ComponentModel
<<stereotype>>
RCOSComponent
<<stereotype>>
ContractInterface
<<stereotype>>
ContractInterface
Port
0..*
supplier
1
0..*
provided 0..1
client 1
supplier
1
required
0..1
client
1
0..2
0..*
Figure 5.8: Realizing component composition
206
5.2. A UML Profile for rCOS
Component composition As shown in Fig5.8, extended from UMLdependency,
we define two stereotypes«Composition» and «Delegation» to support the following
two kinds of component compositions:
• Horizontal assembly: A provided interface from one component is plugged to
a required interface of another component using a«Composition». The requests
from the required interface are passed to the provided interface. The two compo-
nents are composed at the same level of the hierarchical structure. One required
interface may need several provided interfaces, and one provided interface can
be plugged into multiple required interfaces. The rCOSconnectors, if they are
implemented as simpleopen components, compose components horizontally.
• Hierarchical assembly: If a component has internal sub-components, we use
UML port as the interaction points to the internal parts. Using the stereotype
«Delegation», an interface of a sub-component can be associated to a port of
the container component. A request to the provided interface of the owning
component reaches the port first, and it is then forwarded to a provided interface
of a sub-component. Requests originating from a sub-component pass through
its required interface to a port of the owning component, and then pass to the
required interface of the owning component. The composition process can reach
arbitrary depth. The hierarchical assembly also providesname spacefor the sub-
components, that means the full name of a sub-component is decided by all its
hierarchical owning components.
In both cases, the composability between the components must be checked to ensure
thestatic(types) anddynamic(behavior) correctness of the composition.
Component realization Realization of a component means realization of the ser-
vices provided by the component through its provided interfaces. In UML, there are
207
5. A UML Profile for rCOS
three ways to realize the provisions of a component, either using methods of the com-
ponent itself, or by its sub-components or using a realizing classifier.
In the rCOS component model, for a component that does not own any sub-component
(called anatomic component), its provided interface is realized by acontroller classif
it is a closed component, or realized by the methods of the component if the component
is open. For a composed component, all requests will be forwarded and realized by the
provided interfaces of the internal sub-components. Each method call is processed
according to therun-to-completionsemantics. The component that sends a call event
through its required interface has to wait until the component owning the provided in-
terface is ready to receive the call, and then delegate it to an implementing object or a
sub-component. Only one method call is processed at a time.
Figure 5.9: An example of component composition
componentProcessSale {provided interface SaleP
by CashDesk.CashDeskP {...}required interface BankR
by Payment.PaymentR {...}
composition : CashDesk | Payment[(CashDesk.CashDeskR
<< Payment.PaymentP)]
componentCashDesk{provided interface CashDeskP {...}required interface CashDeskR {...}
}
componentPayment {provided interface PaymentP {...}required interface PaymentR {...}
}}
Listing 5.10: Textual de-scription in RCOSP
Fig. 5.9 depicts an example component diagram, and its RCOSP counterpart is
shown for comparison in Listing5.10. The componentProcessSalecontains two inter-
nal components,CashDeskandPayment, and the provided interface ofPaymentplugs
into the required interface ofCashDesk. Through theports anddelegations, all in-
vocations to the provided interfaceSalePare forwarded to the provided interface of
componentCashDesk, and the required services of interfacePaymentRare delegated
208
5.2. A UML Profile for rCOS
to BankR, the required interface of componentProcessSale. In this example, compo-
nentProcessSalerealizes the rCOSparallel compositionof CashdeskandPayment, with
CashDeskR = PaymentP andCashDeskP ∩ PaymentR = ∅. In other words, compo-
nent ProcessSaleis the result of componentPaymentplugged intoCashDesk, denoted
asCashDesk ≪ Payment , through thehierarchical assembly.
5.2.5 rCOS sequence diagram
interactionOperator : OperatorKind
CombinedFragment
<<stereotype>>
ComponentSequenceDigram
<<stereotype>>
RCOSSequenceDiagram
<<stereotype>>
ObjectSequenceDiagram
Interaction
critical
breakloop
seqnegpar
optalt
<<enumeration>>
OperatorKind
InteractionFragment
ConnectableElementMessageOccurrence
InteractionOperand
MessageLifeline
InteractionUse
Constraint
Interface
Component
Operation
{ordered}
{ordered}
CallEvent
Actor
Class
refersTo
1
coveredBy 1..*
covered1..*
operation
message
1..*
fragment 1..*
fragment 1..*
lifeline
2..*
guard 0..1
sendEvent
message
receiveEvent
message.
operand 1..*
represents
event
Figure 5.11: rCOS sequence diagram
UML sequence diagram provides powerful and well-defined constructs to rigor-
ously model complex flows of control. It has become one of the most important tools
in scenario-based requirements engineering, as it can be used to capture and elicit dy-
namic and functional behaviors of a system in a very readable but also quite formal
way. As shown in Fig.5.11, a sequence diagram is defined as a UMLInteraction
which includes:
• a set oflifelines, each representing a participant taking part in the interaction. A
participant could be anactor, an object (of a particularclass), an interface, or
209
5. A UML Profile for rCOS
a component. When a lifeline represents an object or a component, we call it
object lifelineor component lifeline, respectively.
• a set ofmessages, each specifying a communication from a sender lifeline to
a receiver lifeline through a pair ofsendand receive events. The send event
occurs before the receive event. These events correspond to the invocation of an
operation. In our model, we allow onlysynchronous message callsto operations
defined in an interface or a class.
• an ordered set ofinteraction fragments, each representing a piece of the interac-
tion. The fragments cover lifelines from top to bottom in a time sequence. There
are three kinds of interaction fragments:
– message occurrence: specifies the occurrence of the pair of events caused
by an operation call.
– combined fragment: expresses varied kinds of conditional control flows. A
combined fragment consists of one or moreinteraction operands, which
may also contain message occurrences and combined fragments. An inter-
action operand can owns a constraint as itsguard condition. The type of
a combined fragment is decided by itsinteraction operatorfeature. In to-
tal there are 12 different types of interaction operators defined in the UML
specification. The operators considered in our model arealt, loop, opt,
par, critical, break, negandseq. Discussions about the meaning of these
operators can be found at Section6.1.1.2.
– interaction use: a shorthand for copying the contents of the referred inter-
action to where the interaction use is. The referred interaction is usually
defined in its own sequence diagram. Interaction uses allow reuse of exist-
ing sequence diagrams, and decomposition of a complex sequence diagram
into simpler ones.
210
5.2. A UML Profile for rCOS
In order to combine both OO design and component-based design, rCOS has de-
fined two kinds of sequence diagrams,object sequence diagramsandcomponent se-
quence diagrams. As shown in Fig.5.11, the abstract stereotype«RCOSSequenceDi-
agram» has subtypes of«ObjectSequenceDiagram» and«ComponentSequenceDiagram»,
that satisfy the following well-formed conditions, respectively.
1. Object sequence diagram:
• There is one lifeline representing anactor, and all other lifelines represent
objects or (interfaces of) components.
• Messages aresynchronous callsto an operation provided by the type of the
target lifeline, or a constructor/create messages.
• A message flow starts with a message from the actor to a single component,
from components to components or objects, or from objects to objects, but
never from objects to components.
Therefore, an object-sequence diagram can contain both component and object
lifelines.
2. Component sequence diagram:
• One lifeline represents anactor, and all other lifelines represent (interfaces
of) components.
• All receive events occur on the lifelines representing components.
• Each message is a method call to an operation defined in the provided in-
terfaces of the component represented by the target lifeline.
• There should be acompositionrelation between two components if there is
a message between them in a sequence diagram.
• No create messages exists in the diagram.
211
5. A UML Profile for rCOS
The static semantics, i.e. well-formedness of the rCOS sequence diagrams, including
the above conditions, is defined by a set of OCL rules. These rules are used to auto-
matically check the well-formedness conditions and the structural consistency of the
UML model: for example, the object creation event on a lifeline must precede all other
events on the lifeline, and a fragment must include both the sender and the receiver of
any event occurring in the fragment.
The behavior semantics of UML sequence diagram can be described as a set of
positive traces and a set of negative traces. Positive traces define valid behaviors and
negative traces define invalid behaviors (see Sec. 14.3.11 of [135]). Here a trace is a
sequence of event occurrences. In our model, a trace can be simplified to a sequence
of calls to the operations defined in the classifier.
5.2.6 State machine diagram
Figure 5.12: Protocol state machine
The reactive behaviors of rCOS components are specified by state machines which
are represented as UML state diagrams. In our model, we use the UML protocol state
machine (PSM) that covers all the basic concepts of state machine, such as states, tran-
sitions, events, etc., which are used in rCOS modeling. As a variant of state machine, a
212
5.2. A UML Profile for rCOS
PSM is always defined in the context of a classifier (interface or class). It is used to de-
fine the usage protocol, expressing the allowed call sequences on the operations of an
interface. A distinctive feature ofPSM is that a transition is associated with a precon-
dition (guard) and a postcondition, but not with any action, and the internal transition
triggers cannot be used any more [135]. Thus a protocol state machine describes the
offered services and not the way they could be implemented.
As shown in the metamodel of Fig.5.12, aPSM includes:
• a set ofverticeswhich are abstraction of nodes in a state machine. A vertex
hasincomingandoutgoingtransitions, and it may either be apseudostateor a
state. If a state containsregions, it is called acompositestate, otherwise it is
a simplestate. In our case, a composite states is always anorthogonalstate,
which means there are more than one regions inside the state. These regions
are calledorthogonalregions, and they execute concurrently with interleaving
semantics. For pseudostates, we support thejunction, which is used to chain
together multiple incoming transitions and produce an outgoing transition, and
the choice, which results in the splitting of the multiple outgoing transitions
according to the dynamic evaluation of the transition’s guard conditions. Since
UML allows a model element to be associated with a set of constraints, we use
this to addstateandcritical constraints to a vertex for the purpose of labeling it.
For convenience, if vertexA has an outgoing transition to vertexB, we callB
theoutgoingvertex ofA, conversely,A is theincomingvertex ofB.
• aset ofprotocol transitions, each representing a directed relationship between a
source vertex and a target vertex. A transition represents a single atomic com-
munication event. It may have apre- and apostcondition, and it may trigger
a referred operation that isobservableand changes the system state. A transi-
tion is enabled if its precondition evaluates totrue and its source state is active.
Then the target state must reached under the postcondition by the execution of
213
5. A UML Profile for rCOS
the referred operation. Note that there can be transitions without referred oper-
ation calls and without any guards, as well as transitions that only have a guard
specified, but no operation calls. In addition, a transition without precondition,
post-condition and referred operation is atau transition, which can be executed
automatically and does not change the system state.
• a set ofregionswhich containverticesandtransitions. For each region, aninitial
pseudostate defines its starting point, and afinal statesignifies the completion of
the region. Note that the first transition referred to by an operation cannot start
from the initial pseudostate. A transition to a composite state means a transition
to the initial pseudostates in each of its regions, all theorthogonalregions are
active at the same time, and each region has its own thread of execution. Comple-
tion of the orthogonal regions represents completion of the enclosing composite
state. Afinal statein the region directly owned by the state machine signifies the
completion of the state machine.
The semantics forPSM, as described in the UML specification, isrun-to-completion:
a transition completes only after its referred operation completed. Thus, while exe-
cuting an operation, no other operation calls can be processed by thePSM. Thereby,
ignoring the execution of the transitions which do not call operations, the semantics is
captured by a set of traces of operation calls, each starting from theinitial state, going
along the outgoing transitions, and finally reaching thefinal state of thePSM.
5.2.7 Visual diagram modeling
The multiple viewpoints of rCOS can be graphically represented using different UML
diagrams. The graphical representations are essential parts of an rCOS model. At im-
plementation level, currently an rCOS model is built on top of Topcased [165], that
is an open-source toolkit and runs on the Eclipse platform as a plug-in. Supported by
Topcased, a complete rCOS model consists of two parts: a UML model that contains
214
5.2. A UML Profile for rCOS
the abstract syntax information we have described previously in this section, and aDI
(diagram interchange) [75] model that contains the concrete syntax (visual representa-
tion) information.
+presentation : String
SemanticModelBridge
+id : String+offset : String
EdgeObjectOffset
+position : String
GraphConnector
+viewport : String
Diagram
+position : String+size : String
GraphElement
+key : String+value : String
GraphProperty
UMLElement
+text : String
Waypoints
GraphNode
SubDigram
DIModel
ElementRef
GraphEdge
modelRef
0..1
0..*+semanticModel 0..1
+model
+anchor 2
+graphEdge
+property
0..*
+model
0..* +href
+anchorage0..*
+element
1..*
0..*
+href
1..*
1..*
Figure 5.13: Metamodel of diagram interchange (DI)
UML 2.0 Diagram Interchange (DI) [75] is a standard proposed by OMG for dis-
playing models on a two-dimensional canvas such as a monitor. Fig.5.13 depicts
the DI metamodel used in rCOS modeling. Here, a DI model may contains several
subDiagrams, which are mechanisms to collectDiagrams. The main concepts of the
metamodel areDiagram, GraphNode, GraphEdge, and their superclass -GraphElement.
The last one includes information such aspositionandsizeof the element. ADiagram
is the topmost graph element for an independent graph or diagram, and it can recur-
sively contains all other graphic elements. TheGraphNodesandGraphEdgesare linked
by theGraphConnectors. A graph connector is the connection point owned by a graph
node and defines the position for graph edges to link. A graph connector may be served
for more than one graph edges, while every graph edge exactly anchors to two graph
connectors.
A graph element is related to an element in the UML model through theElementRef
of a SemanticModelBridge. The appearance of the graph element is decided by the
215
5. A UML Profile for rCOS
presentationproperty of theSemanticModelBridge. TheDIModel andSubDiagramcan
also relate to their semantic correspondences.
In case of rCOS model, each sub-model, such as rCOS use case model, class model
or component model, is represented as aSubDiagram. Inside a diagram, UML model
elements are represented intuitively. For example, in a component diagram, compo-
nents and interfaces are represented by graph nodes, while interface realization, usage
and composition are represented as graph edges. For a sequence diagram, lifelines are
represented by graph nodes and messages are graph edges. Meanwhile the Topcased
tool is responsible for the concrete representation of a graph element. For instance,
the tool has to know that a node representing a component should be visualized as a
rectangle with its name in the upper compartment.
5.2.8 Profile constraints
An important part of a profile is the static semantics that is defines as the well-formedness
constraints. These rules are used to automatically check the well-formedness and the
structural consistency of a model. The constraints are typically specified by OCL and
embodied as a set of OCL rules to theconstraintsproperty of the owner stereotype.
This allows treating constraints as other model elements. They can be handled using
usual modeling mechanisms, such as copying, moving around in the model, or refac-
toring into a separate module etc.
All these constraints can be divided into two categories: profile conformance con-
straints, that require a model conforming to the profile, and model consistency con-
straints, where different viewpoints of a model must be mutually consistent. For static
consistency of an rCOS model, we at least check the follows:
• all types used in the fields, method parameters, and method bodies are correctly
defined in rCOSTypespackage;
• all method invocations occurred in the state machines, sequence diagrams, and
216
5.2. A UML Profile for rCOS
method bodies only callmethodsdefined in the correspondinginterfaceor class,
with matched in & out arguments and types.
A conformance constraint is evaluated between an rCOS model and the stereotypes
of the profile. For example, an rCOS sequence diagram can only have synchronous
method calls. In the following, we discuss some of the profile conformance constraints
as examples.
• An rCOS model consists of ause case model, a class model and acomponent
model.
contextRCOSModelinv modelHs3Pt:
self.usecaseModel→size()=1and self.classModel→size()=1and self.componentModel→size()=1
• An rCOS component sequence diagramhas at most one lifeline representing an
actor, and the others represent component interfaces.
contextComponentSequenceDiagraminv comSeq1Act:
lifeline.represents.type→select(oclIsTypeOf(uml::Actor))→size()<=1
and lifeline.represents.type→select(not oclIsTypeOf(uml::Actor))
→forAll (oclIsTypeOf(uml::Interface))
• An event of rCOS sequence diagram must be a call event.
contextMessageinv eventIsCall:
owner.getAppliedStereotype(’rCOS::RCOSSequenceDiagram’)→notEmpty()
implies receiveEvent.oclAsType(uml::OccurrenceSpecification).event
→forAll (oclIsTypeOf(uml::CallEvent))
5.2.9 Profile implementation
We have developed a CASE tool, calledrCOS modeler[97], which provides a de-
velopment environment for rCOS, and we implemented the rCOS profile in the tool.
The tool supports rCOS methodology with user friendly interfaces and integrated re-
finement and verification facilities. It also realizes the well-formedness and structural
217
5. A UML Profile for rCOS
consistency checking using an OCL engine. The tool is based onTopcased[165] and
developed in Java as a plug-in to Eclipse IDE. Topcased provides a graphical environ-
ment for designing UML diagrams, editing metamodels, specifying OCL constraints,
and model verification and validation. The following steps are included in the process
of developing the rCOS profile:
Figure 5.14: Definitions of rCOS profile
Defining the profile. In theUML Editor of the Eclipse platform, it is straightforward
to use the design decisions made previously to design the rCOS UML profile as a stan-
dard EMF model. The screenshot of Fig.5.14shows a part of the profile definitions.
218
5.2. A UML Profile for rCOS
It includes a set of admitted constructs and other restrictions, a set of stereotypes and
tag values that can be used. In addition, we define a library model that realizes all
rCOS primitive and collective types. Thus, using the XMI interchange mechanism, the
profile and library model, together with models to which the profile have been applied,
can be output as XMI files and reused (imported) by other tools.
Customizing user interfaces. However, additional functionality may need to be de-
veloped in the process of implementing a profile in practice. This comes from the
fact that it is more efficient for end-users to work in a user-friendly graphical interface
when dealing with complex models and developing steps.
Specifically, modeling elements applied with an rCOS stereotype will be shown
with the name of the stereotype in the UML diagrams, such as«RCOSUseCase» in
use case diagrams, or«ServiceComponent» in component diagrams. The menu icons
in the editing palette of the diagrams have to be restricted to the allowable items for
rCOS modeling. For example, the icon used to draw an asynchronous message will
not show in the edit panel of the sequence diagrams. Moreover, we need additional
items in the popup menus to navigate among different views of a complex model,
and to support stepwise and incremental design by invoking model transformations in
different development stages. The customized user interface clarifies the usability of
the rCOS modeler by enabling the user to drag and drop the correct model elements to
appropriate views, and offering a convenient way to guide the user to do the designs.
This work of customizing user interfaces is done by developing a set of Java classes
and descriptive XML files. Deployed as Eclipse plug-ins, these artifacts extend and
customize UML diagram editors of Topcased. The plug-ins limit and/or add menu
items in editing palettes and popup menus of various views. They also contribute to
OCL well-formedness checking by indicating the elements that failed in the validation
and pointing out the causes.
219
5. A UML Profile for rCOS
Implementing well-formedness constraints. Theoretically, a stereotype can also
contains constraints written in OCL. A tool can read out these constraints and check
the target model. But actually it is quite difficult to perform complex checking in
a controlled series of steps using this approach. In the current version of the rCOS
modeler, a part of the constraints is embodied in Java classes, and the checking of the
OCL constraints is also invoked and controlled by the Java code. The user only needs
to click on the "Validate the model" button in the main control toolbar of the tool.
The validation of an rCOS model has proven useful in finding errors in the model.
All problems and possible inconsistencies will have to be checked and resolved before
other tasks such as refinements or transformations are performed on a model.
5.3 Supporting rCOS Development
The rCOS methodology supports the model-driven development process from require-
ments model through object-oriented design to a component-based model. In this sec-
tion, we discuss how the rCOS methodology can be supported by the rCOS modeler
that implements the rCOS profile.
5.3.1 Requirements modeling
As shown in Fig.5.15, the rCOS modeling process starts from creation of an empty
rCOS model. Then we capture the business domain concepts with aconceptual class
diagram, and the business processes are described as a set ofuse cases. For each
use case, a component is created, along with an empty sequence diagram (for short,
SeqDin the figure) that has only two lifelines representing the actor and the provided
interface of the component. Through adding a message to the sequence diagram, a
corresponding method of the interface is automatically produced. Then, we can specify
the data functionality of the method usingRCOSP.
220
5.3. Supporting rCOS Development
Create empty rCOS model
Design domain class diagram
Create use case
Specify data functionality
Generate state diagram
Add message to SeqD
Validate model
Create empty usecase diagram
Create top component diagram
Add an operation to interface
Create empty usecase SeqD
Create component
Run FDR2 model checker
Check OCL rules
Generate CSP
User Modeler
more usecases
more messages
Figure 5.15: Requirements modeling in the rCOS modeler
After that, a state machine can be automatically generated from the sequence dia-
gram of the interface using the sequence diagram to state machine transformation. At
the end of this stage, we get a requirements model that includes aconceptual class
diagramin which classes do not have methods, ause case diagramto depict the use
cases of the system, a top-levelcomponent diagramwhere each use case is modeled
as a component, and a set ofsequence diagramsto describe the interactions of the
use cases. Also, each method of a provided interface has an rCOS designpre ⊢ post
that describes the computations on the domain classes. Through checking the OCL
well-formedness rules defined in the profile, along with type checking of the method
specifications, the static consistency of the requirements model can be ensured. More-
over, we can generate CSP specifications for the sequence diagrams, state diagrams (if
they had been manually modified) and the functionality specifications, and then check
the dynamic consistency of the model in the FDR2 model checker [41].
221
5. A UML Profile for rCOS
5.3.2 Object-oriented design
Start OO design Generate controller class
Generate object SeqD
create new method in domain class
Generate new lifleline and message in object
SeqD
Check validity
User Modeler
Select part of method design to apply expert
pattern
Open object SeqD
Apply structural
refinement rules
Open class diagram
moremore
Figure 5.16: OO design in rCOS modeler
From acorrect requirements model, we start the object-oriented design in which
the rCOS object-oriented refinement rules are applied to optimize the model’s data
structures and functionality specifications. First, a controller class is generated for
each provided interface, and then from its use case sequence diagram, an initial object
sequence diagram is created by replacing the interface lifeline with a lifeline represent-
ing the controller class.
Then the expert pattern of responsibility assignments is used interactively to re-
fine the model. From a message of the object sequence diagram, we open the design
specification of the corresponding method, and select a fragment of it to delegate to an
object of a domain class. After checking the validity of the selection, the tool provides
candidate target objects for user to choose, and creates a new method in the domain
class, replaces the selected fragment with a method call to the new method, and up-
dates the sequence diagram by adding a corresponding lifeline and a message. This
design process is depicted in Fig.5.16. For class diagrams, we can apply the set of
222
5.3. Supporting rCOS Development
rCOS structural refinement rules [82]. However, the expert pattern can be also ap-
plied on a class in the class diagrams. In this case, it automatically refines all method
specifications of the class by replacing navigation paths with method calls.
At the end of the OO design, we get an OO design model which includes a set of
refinedobject sequence diagramsand adesign class diagram.
5.3.3 Component-based model design
Figure 5.17: Component-based design in the rCOS modeler
From the object sequence diagram of a component’s controller class, a set of ob-
ject lifelines is selected and translated into a new component, which becomes a sub-
component of the original component. Meanwhile, the original sequence diagram and
component diagram are updated accordingly, and a new sequence diagram and a state
machine (SDin the figure) are generated for the new component. By repeating this pro-
cess, a component is decomposed into a composition of a number of sub-components
within the component, and the connection and interaction of these sub-components are
illustrated by a component diagram and a component sequence diagram, respectively
223
5. A UML Profile for rCOS
[107]. After that, by applying the rCOS component composition operators, the com-
ponents of the system can be hidden, renamed, plugged or composed to optimize the
architecture of the component model for better implementation and deployment. The
component-based design process is depicted in Fig.5.17.
Through two stages of interactive, stepwise refinements, we get a component archi-
tecture model which refines (implements) the requirements model. The final component-
based model still contains all artifacts of the requirements model (except that the do-
main class diagram now becomes the design class diagram), and all the object sequence
diagrams of the OO design model. Thus the modeling architecture itself provides a
certain degree of traceability for the developing process.
5.3.4 Code generation
After finally all constructs in the model have been refined, the model can then be used
for code generation. We have established the principal mapping from rCOS to the Java
programming language, and with the help of a few annotations (mostly on the libraries
supplied by the tool), we can generate the Java packages automatically. The code
generator can easily be adapted to generate code for other object-oriented languages.
5.4 Related Work
UML profiles provide a standard extension mechanism for defining modeling lan-
guages. A certain number of UML profiles have already been defined, either for
generic purposes, or to deal with specific technologies. Among the others, OMG has
proposed a set of standard UML profiles, such as SysML [128], which is for speci-
fying, analyzing and designing complex systems; and MARTE [129], which supports
specification of real-time and embedded systems. In the field of requirements engineer-
ing, a profile [83] is designed to allows the KAOS model to be represented in UML.
Moreover the authors of [146] try to combine the power of SysML and Modelica [146]
224
5.4. Related Work
to enable an integrated modeling and simulation of system requirements and design.
In [11], a UML profile is proposed to describe distributed and asynchronous software
components using UML 2 diagrams for both architectural and behavioral specifica-
tions.
A UML profile should provide all the semantic expressiveness and precision of the
modeling language in order to use UML to describe the needed conceptual models, and
the profile must be easily adapted to meet the continuous changes in order to introduce
new features [151]. Unfortunately, many UML profiles in the literature cannot entirely
fulfill these two requirements. To improve this situation, Selic in [151] proposed a
systematic approach that establishes some guidelines to ensure a correct domain meta-
model definition and suggests how a correct mapping between the domain metamodel
and the UML metamodel can be defined. The authors of [64] also propose some sim-
ilar guidelines for the UML profile definition. In [102], a set of design patterns for
defining profile was proposed. These works provide the foundation for the approach
we use in defining the rCOS profile.
Many works have been done on the integration of formal methods and MDD [53;
68; 123]. Modeling languages must have formally defined semantics, and the multiple
views of a complex model need to ensure their consistency. In this perspective, most
of the works focus on translating modeling views into a formal specification, thus the
formal semantics of the model is defined, and existing analysis tools of the formal
language, such as type-checkers, theorem provers, and model checkers, can be used
in the proof of the desired properties. Among the others,Z, B, CSP, Petri netsare
the most often chosen target languages. We cite the work of [88] that proposed a
metamodel-based transformation of UML models to B constructs. Similarly, there
is an MDE based transformation approach for generatingAlloy specifications from
UML class diagrams and backwards [17]. Different from those, our work is mainly
concerned with the integrated tool supports for the stepwise, incremental development
of models by applying the formal refinement calculus of rCOS. In other words, we are
225
5. A UML Profile for rCOS
more interested in development and evolution of models, than just formally checking
and verifying of models.
There are also some integrated modeling frameworks which are based on formal
methods. In [109], a development methodology applying the SOFL formal language in
industrial software practice was proposed. The system development process consists
of three separate activities: requirements specification, design, and implementation.
A SOFL specification is first constructed in a structured way usingCondition Data
Flow Diagram(CDFD) with formal textual constraints, and then the specification is
transformed to an object-oriented design and finally to the implementation. CDFD
is an intuitive and powerful graphical notation, but it is not an OMG standard. In
the IFAD VDM++ (an object-oriented extension of VDM-SL) toolbox [9], UML is
used to provide the structural, diagrammatic overview of a model while VDM++ is
used for specifying the detailed functional behavior of the model. However most of
these frameworks lack automatic support for transformations from high-level models
to low-level models, and component-based design is not explicitly addressed.
In [40], a previous version of the rCOS profile was proposed as the center part
of the rCOS modeler. The rCOS profile described in this chapter is a refinement and
improvement of the previous one. In the current rCOS profile, we clearly separate
the rCOS concepts from UML metamodel concepts, and explicitly define rCOS com-
ponents composition in both horizontal and vertical ways. In addition, we define the
sequence diagrams and protocol state machines used in rCOS modeling, present the
architecture and other artifacts of rCOS models, and add more OCL well-formedness
constraints. We hope these changes facilitate rCOS model refinements and transforma-
tions, and achieve interoperability and exchangeable among different UML tools for
rCOS modeling.
226
5.5. Summary
5.5 Summary
This chapter reflects part of our efforts to move rCOS from a formal theory to a practi-
cal domain-specific modeling language in the field of component-based model driven
software development. We present our UML profile with necessary stereotypes, tagged
values and constraints in order to represent the main concepts of rCOS in UML and
support the development methodology of rCOS. We adopt a systematic approach in the
design of the profiles, starting from building a domain metamodel to capture the basic
concepts of rCOS, and then mapping them into stereotypes, attributes and constraints
of the profile in a traceable way. Linking with UML gives rCOS the power of the stan-
dardized graphical notation and tool support for system and software modeling, thus
increases the usefulness of rCOS; while integration with rCOS supplies UML models
with a precise semantics, additional modeling concepts for components composition,
formal consistency verification and refinement techniques, and a development method-
ology in the application domain of the component-based model-driven development.
We implement the profile in the rCOS modeler, a CASE tool for rCOS. Based on
the rCOS profile, the tool focuses on supporting the rCOS development methodology
with a user friendly interface. We describe the concrete steps of how a model is de-
veloped in the rCOS modeler. The tool implements the rCOS refinement rules, such
as expert pattern and structural refinements, as correctness preserving model transfor-
mations. Some of these transformations will be discussed in detail in the following
chapter.
However, a method can be really successful only if a great number of users are
convinced of its capability to perform in industrial software projects. Use of UML to
support rCOS may help achieve this object.
227
Chapter 6
Enabling Model Transformations of
rCOS
The rCOS prompts an iterative and incremental development methodology that com-
bines object-oriented and component-based design and analysis techniques. The de-
velopment process goes through the stages of requirements elicitation, object-oriented
design, logical component-based design, and through to coding. This process leads to
a sequence of models, evolving in their levels of details, and models in later develop-
ing phases are constructed from those in earlier phases. The development process is
driven by model transformations: producing anobject-oriented design modelfrom the
requirements model, acomponent-based design modelfrom the object-oriented design
model, and finally aplatform specific modelor runtime model. Moreover, models of
other formal languages may need to be generated in order to verify the original designs
in the tools of these formal languages.
However, the only way to get a full return of MDD promises of faster, less costly
software development, is automating any model-driven software development proposal
[19]. In this sense, implementing the rCOS model transformations in CASE tools is
considered as one of the keys for the success of rCOS method. The work of this
chapter focuses on the following four transformations that are repeatedly used in the
development process of rCOS:
Requirements model to OO design model Starting from a requirements model in
which a set of component interfaces represents use cases, and a set of system sequence
diagrams specifies the scenarios of the use cases, the transformation automatically
transforms such a model into an initial design model by generating a protocol state
228
machine for each interface from its sequence diagrams, deriving a controller class as
an implementation of the interface, and converting adesignp ⊢ R of an interface
method into aguarded designg&p ⊢ R for the corresponding method in the controller
class. Thus the method specifications of the controller class ensure that the behavior
defined by the sequence diagrams is fully complied with. The transformation takes
into account the concurrency and critical area of the respective diagrams. The gener-
ated model can sever as the starting point for the detailed object-oriented design, such
as applying the expert pattern. Therefore the transformation helps to bridge the gap
between requirement models and detailed OO design models.
Functionality delegation (expert pattern) The functionality delegation is offered
as the expert pattern transformation. However, it is quite a challenge to automate the
expert pattern. One reason is that the data functionalities are textually specified, and
they are attached to a model which consists of both a UML semantic model and its
graphical representation model. Execution of the transformation means three of them
have to be synchronously modified. Currently, we implement the core algorithm of the
transformation in Java.
In rCOS modeler, this work of applying expert pattern is done interactively in the
view of sequence diagram. We choose a message, open the corresponding method
specification, and select from it a consistent fragment that may contain a number of
navigation paths. The tool checks the validity of the selection, calculates the possible
classes that the selected fragment can be delegated to, and allows the user to pick one
as the target class. A new method is then created in the target class, while the selected
fragment, after appropriate alteration to the navigation paths, becomes the specification
of the new method. The selected fragment in the original specification is replaced by a
single method call to the new method. Any necessary variables, which are not local to
the fragment, are passed as parameters to the new method.
In addition a message is newly created in the sequence diagram to represent a call
229
6. Enabling Model Transformations of rCOS
to the new method. The new message is inserted immediately after the reception of the
chosen message, going from the original receiver to the lifeline represented the target
class. This lifeline may already exist in the sequence diagram, or have to be newly
introduced.
The rCOS modeler allows stepwise incremental application of the expert pattern
transformation. As a result, the original system sequence diagram, which consists of
only two lifelines, is refined into an object sequence diagram that has additional object
lifelines and messages. Meanwhile, the conceptual class diagram is refined to a design
class diagram by adding methods to classes of the expert objects. The component
diagrams and the state machine diagrams are not changed by the OO refinement.
OO design model to component-based modelStarting from a detailed OO design
model, this work is carried out by the object sequence diagram to component sequence
diagram transformation. The user selects a number of objects lifelines from an object
sequence diagram to transform into a new component by applying the transformation.
In the sequence diagram these selected lifelines are collapsed to a new lifeline rep-
resented the new component, and messages within these lifeline are internalized and
hidden. Only the messages from other components to the newly formed entity remain.
The composition (plugging) relationships of the new component with other existing
components will be illustrated in a component diagram, and a new sequence diagram
and a state machine are generated for the new component as its protocol.
Repeating this process until all of the object lifelines turn into components, the
object sequence diagram becomes a component sequence diagram. As the result, a
component-based model is generated, consisting of a set of component diagrams and
component sequence diagrams. In the model a component represented a use case is
refined into composition of a number of (sub-)components.
230
Component composition The transformation realizes the basic composition oper-
ators that we have discussed in Section3.3.2. In the rCOS modeler, we invoke the
transformation in the view of component diagram after selecting one or several com-
ponents.
• Rename method: rename interface methods of componentK . A new component
Kn will be created as a container ofK . All the method signatures,SDs (sequence
diagrams),PSMs (protocol state machines) ofK .pIF andK .rIF will copy to Kn
after accordingly adjustment to the new names. Requests to the interface ofKn
will be delegated toK , as specified in the method body ofKn .
• Hide method: restriction on the environment to access the provided methods of
componentK . We also create a container componentKn , and copy all method
signatures,SDs, PSMs of K to Kn after filtering out the hidden methods. Sim-
ilarly, the specification of a method inKn defines as a method call to the corre-
sponding method inK .
• Parallel composition: We realize the algorithm defined in Definition10 for par-
allel composition of components, for example,K1 and K2 . First the provided
and required interfaces ofK1 and K2 may plug to each other if some of their
methods have the same signatures. Then a new container componentKn is gen-
erated, and method signatures ofK1 and K2 are copied toKn after hiding the
plugged methods. In addition, we generate the protocol forKn . TheSDof the
protocol includes apar combination fragment, in which there are two operands
that respectively contain theSDs fromK1 andK2 . Similarly, thePSMof proto-
col comprises of a composition state in which each orthogonal region contains a
PSMfrom one of the composed components.
• Plug components: plugging the provided interfacepIF of one component to the
required interfacerIF of another components. The composability of these two
231
6. Enabling Model Transformations of rCOS
interfaces will be checked:
1. Signature: TherIF has at least one of the same method signatures aspIF .
Let pIFs denote the union of the provided interfaces plugged to therIF ,
then for each method inrIF , there is not more than one method with the
same signature inpIFs .
2. Protocol: Let PSMp be the protocol state machine of a suppositional inter-
face asdisjoint unionof thepIFs, we generate the execution traces from the
PSM of therIF , and execute the traces in thePSMp. The execution should
not be blocked. Moreover, we can also translate the two state machines to
CSP, and check the dynamic consistency of them in the FDR2.
The transformation will update the component diagram, generateSDs andPSMs
for the new interfaces.
These transformations are defined in the graphical notation of QVT-R using the
QVTR-XSLT tool, and integrated into the rCOS modeler. The design and implemen-
tation details of therequirements model to OO design modeland theOO design model
to component modeltransformations are discussed in Section6.1and6.2, respectively.
That is followed by a case study of a sale management system in Section6.3. We
discuss related work in Section6.4and give some conclusions in Section6.5.
6.1 From Requirements Models to Design Models
Capturing and specifying requirements has been recognized as the first step of rCOS
development. In the resulting model of requirements,domain class diagramsare used
to represent structural concepts and their relationships, anduse casesdescribe the ser-
vices provided by the system. Typically, we model a use case as acomponent, where
its interfaceprovides the methods through which the actors of the use case interact
232
6.1. From Requirements Models to Design Models
with, and the interactions are specified as system sequence diagrams. The data func-
tionality of a method is specified as an rCOS design that describes the computations
on the domain classes.
In the subsequent analysis and design stage, UML state machines are defined as
part of the protocols for modeling the reactive behaviors of the components. A state
machine is essentially executable, and can be validated and tested through simulated
executions. Furthermore, a component interface, along with its protocol, is imple-
mented by acontroller classthat is responsible for receiving or handling system events.
The controller class is then used for thedetailed object-oriented design, and translated
to executable program code, or taken as an input for the succeedingcomponent-based
design. Thus, it is important that the controller class fully complies with the semantics
introduced by the original system sequence diagrams. One way to achieve this is to
provide guarded designs to methods of the controller class as in general a class does
not have a behavior protocol.
Manually designing state machines and the implementation classes, especially for
complex systems, is a difficult and error-prone task. Automation of this process pro-
vides considerable help for the users. It allows the designers who are not very technical
to concentrate on using sequence diagrams to express behavioural requirements, and
automatically get other artifacts to begin the work of the next stage.
The following transformations are included in the process:
1. Synthesis a protocol state machine (PSM) for an interface from its system se-
quence diagrams (SD);
2. Labeling the protocol state machine by attaching every vertex withstateand
critical tokens;
3. Generation of a controller class as an implementation of the interface.
The controller class contains attributes of primitive types and their initial values, as-
233
6. Enabling Model Transformations of rCOS
sociations to the domain classes, invariants, and a set of methods duplicated from the
interface. In addition, a pair of pre- & post-conditions, for example,pren and postn ,
is generated for each method that triggers transitions in the state machine. These con-
ditions are used to ensure that the behavior defined by the corresponding sequence
diagrams is fully complied with. After merge with the designpre ⊢ post of the same
method of the interface, a guarded designg & (p ⊢ R) can be produced for the method
of the controller class, whereg = pren , p = pre andR = post ∧ postn .
A range of interaction operators of UML sequence diagram, such asalt, opt, seq,
neg, loopandbreak, are considered in the transformations. In particular, we support
par and critical, which provide the ability to specify concurrent and safety critical
requirements. Usinginteraction usesthat refer to other sequence diagrams, we can
describe complex interactions in the limited space of a single sequence diagram.
6.1.1 From sequence diagrams to protocol state machines
The transformation requires that: given a system sequence diagramSD, and a generated
PSM, a call event to an operation of the interface in theSD becomes a transition of
thePSM that is triggered by the same operation, and all valid traces of theSD, after
restriction to the calling ofnon-queryoperations, are the traces of thePSM.
The transformation is specified as anin-placeQVT-R transformation in which the
metamodels forSD andPSM are defined in Section5.2.5and Section5.2.6, respec-
tively. The transformation starts from relationInteractionToVertexshown in Fig.6.1.
The source domain pattern (left) of the relation matches an interactionseq, and locates
the corresponding lifelinelfl through the predicatelflnm=transLife lineName
in thewhenclause, wheretransLifelineName is the name of the interface lifeline.
Then the target domain pattern (right) creates a new protocol state machinesm with a
topmost regionreg, an initial pseudostateinitS and a final statelastS. Since in a
UML protocol state machine, the first transition referred to by an operation can’t start
234
6.1. From Requirements Models to Design Models
Figure 6.1: Starting theSD to PSMtransformation
from the initial pseudostate, we add a state calledfirstS with name "Init", as well
as a transitionfirstTr leading to the state from the initial pseudostate. One concrete
example of theInit state is shown in Fig.6.3.
In thewhereclause of the relation, we assign values to all item names and iden-
tifiers. The queryGetRecFragretrieves all receivingmessage occurrencesandcom-
bined fragmentscovered by thelfl in a top-down order along the lifeline. Relation
FragmentToStateconstructs corresponding states and transitions in the regionreg.
In the following, we discuss how the transformation deals with different kinds of
interaction fragments. We mostly use examples to illustrate the translation of each
construct. The left-hand side of each figure shows the inputSD, and the generatedPSM
is shown on the right.
6.1.1.1 Message occurrences
For the message occurrence of a receiving event, the relationReceiveEventToState
shown in Fig.6.2is applied. The source domain pattern (left) of the relation matches a
235
6. Enabling Model Transformations of rCOS
Figure 6.2: Rule formessage occurrenceFigure 6.3: Applying rule formes-sage occurrence
message occurrencefr with a call event and a connected operationop. As parameters
of the relation, theprimitive domainscondi andupperS are theguard conditionand
the name of the parent state, respectively. In thewhereclause, a unique namestnm is
defined asupperS + cpos, wherecpos is the position of thefr in the list of all current
fragments. Then the target domain pattern (right) constructs a new statest, assigns its
name tostnm, and adds a transitiontran that starts from the previous state and goes to
the statest. The transition refers to operationop. By invoking relationSetConstrain
from thewhereclause, a precondition is attached to the transition if there is one. This
straightforward strategy ensures that all traces of aSDare also traces of the generated
PSM. Fig.6.3shows the transformation of a simple sequence diagram by applying this
relation.
6.1.1.2 Combined fragments
A combined fragment contains one or more interaction operands, which in turn may in-
clude more message occurrences and combined fragments. For most of the combined
fragments, we generate for each a pair of pseudostates (kinds ofjunction or choice)
representing the starting and finishing of the construct, along with the transitions be-
tween these two pseudostates to represent the control flows of the combined fragment.
One of the exceptions is thepar, which results in orthogonal regions enclosed with a
236
6.1. From Requirements Models to Design Models
composite state. After transforming the combined fragment itself, the contents of each
operand need to be recursively processed.
• alt: The interaction operatoralt is used to designate choice between two or more
operands. It allows modeling of the classic "if-then-else” logic. Each operand
is given a guard constraint that if it is evaluated totrue, then that operand is the
operand to follow. Note that, in general, there will be an "else" alternative where
its guard is evaluated totrue when none of the guards in the other operands
is evaluated totrue. If no guard is given, one of the operands will be non-
deterministically chosen to execute.
As shown in Fig.6.4, an alt fragment is handled simply by introducing a
sequential branch for each operand in the generatedPSM, starting with achoice
pseudostate. The guard constraint of an operand becomes the precondition of
the corresponding transition outgoing from thechoice. By introducing anot()
function, the precondition of the "else" branch is the negation of the disjunction
of all other guards in the enclosingalt fragment. After the contents contained in
the operands are translated, all sequential branches end in ajunctionpseudostate.
In the generated state machine diagrams, a larger solid circle represents a
junctionpseudostate, a smaller solid circle represents aninitial pseudostate, and
achoiceis represented as a diamond-shaped box.
Figure 6.4: Applying rule foralt Figure 6.5: Applying rule forbreak
237
6. Enabling Model Transformations of rCOS
• break: The breakcombination fragment is used to model a scenario that if its
guard istrue, its operand is chosen to execute, and then the remainder of the
enclosing interaction will be ignored. Otherwise the break operand is ignored
and the rest of the enclosing interaction will be chosen. The model in Fig.6.5
shows the result after applying the rule forbreak. The construction starts with a
choicepseudostate, and a transition from the content of the operand to the final
state is added.
• loop: A loop combination fragment represents the iterative application of its
operand, and it is executed until the guard evaluates tofalse. The loop in the
SD of Fig. 6.6 is transformed into thePSM which first starts with ajunction
pseudostate, and goes along atau transition to achoicepseudostate where the
guard is evaluated. Note that as we defined in Section5.2.6, a protocol transition
may not have a referred operation, or a postcondition.
Figure 6.6: Applying rule forloop Figure 6.7: Applying rule foropt
• opt: Theopt operator is used to model a sequence that, when a certain condition
is satisfied, will occur; otherwise, the sequence does not occur. It represents a
simple ”if-then” statement. For anopt fragment (see Fig.6.7), two branches are
created, one includes the optional fragments in the operand and one skips them.
• par andcritical: Thepar combination fragment is used to model a parallel com-
position of the fragments of its operands. The behavior of the operands can be
238
6.1. From Requirements Models to Design Models
interleaved in any order as long as the ordering imposed within each operand
is preserved. Each operand in thepar represents a thread of execution done in
parallel. Thepar and thealt operators are quite similar in nature. Both have
more than one operands to represent branches of control flows. The difference
is that thepar branches are executed simultaneously whereas only one of thealt
branches is executed.
Thecritical operator is closely related topar fragment. It defines a critical area
in which the traces of execution cannot be interleaved by other messages, and
that can only happen when thecritical fragment and the other messages belong
to different operands of the samepar fragment. Thecritical operator is important
in modeling a sequence of behaviors that must be contiguously handled.
Fig. 6.8 gives an example of apar fragment with acritical fragment. A
par fragment leads to a composition state containing two or moreorthogonal
regions. This preserves the traces of thepar because the UML semantics for or-
thogonal regions is interleaving of events from different regions. Inside a region,
we generate a state machine for each operand of thepar. These state machines
each have aninitial pseudostate and afinalpseudostate. All state machines of the
orthogonal regions arriving at thefinal states activates the transition leaving the
composite state. For acritical fragment, we generate twojunctionpseudostates
to mark the start and end of the critical area. These two pseudostates will be
labeled with critical tokens in the subsequent steps to ensure their semantics are
preserved.
• neg: The neg fragment is used to model the negative traces that are defined to
be invalid. We simple removes thenegoperator and its content. This is because
negative behavior shall not be implemented by the state machine. We only map
the positive behaviors of a sequence diagram to the protocol state machine.
• seq: Theseqoperator introduces a weak behaviors of the operand. Since we only
239
6. Enabling Model Transformations of rCOS
Figure 6.8: Applying rules forpar andcrit-ical Figure 6.9: Applying rule forref
generatePSMfor one lifeline, and the sequence is already decided by the order
of the messages along the lifeline, this operator do not bring any new semantics.
We simply add twojunctionpseudostates to indicate the start and the end of the
combined fragment in the generatedPSM. Fig.6.9depicts an example using the
weak sequencing operator.
6.1.1.3 Interaction uses
An interaction use is shown as a combined fragment where the operator is calledref.
It can refer to an interaction which in turn contains other interaction uses, and this
process can be recursive. However, aref cannot contains an interaction use which
refers to the interaction itself to avoid infinite loops. As shown in Fig.6.9, a pair of
junctionpseudostates is generated to indicate the start and end of the interaction use,
and then the referred interaction is subsequently processed.
Redundant constructs of the generatedPSM, e.g., the two adjacentjunctionpseu-
dostates in Fig.6.9, can be optimized to make thePSMmore concise (and better read-
able for humans).
240
6.1. From Requirements Models to Design Models
6.1.2 Labeling protocol state machines
From the generatedPSM, we are going to construct the specification for the controller
class. Therefore we have to calculate the conditions for triggering a transition, in-
cluding its source state, precondition, and thecritical constraints. Since UML allows
a model element to be associated with a set of constraints, we use this to attach this
information to the vertices.
We introduce astate variableof type, for simplicity,string, for each region of the
PSM to represent the current state of the region. The state variable of the upper-most
region by default is named as "state" (actually "_state" in the model). In addition,
We introduce acritical variable that holds a boolean value{ON,OFF} for each region
generated from apar fragment withcritical areas.
This labeling process is carried out by traversing thePSMto label each vertex with
tokens referred to the state- and critical variables. In the following, we discuss the rules
for labeling constructs of thePSMusing examples.
• Labeling simple states: A simple state is labeled with a token that sets its re-
gion’s state variable to the name of the state. For example, the stateS_1_1 in
Fig. 6.10is labeled withstate="S_1_1".
• Labeling pseudostates: If all its incoming vertices are labeled, we give a pseu-
dostate a state token that is a disjunction of thepredicatesfrom the incoming
vertices. Eachpredicateis a conjunction of the incoming transition’s precondi-
tion and the incoming vertex’s state label. As shown in Fig.6.10, the junction
state is labeled as(state="Init" and not(c)) or state="S_1_1", wherec
is the guard condition of theopt fragment in Fig.6.7.
• Labeling composite states: A composite state is provided with aprestatetoken
that represents the enter condition, and astatetoken which represents the exit
condition. Theprestatetoken is labeled in the same way as the pseudostates, and
241
6. Enabling Model Transformations of rCOS
Figure 6.10: LabeledPSM fromFig. 6.7 Figure 6.11: LabeledPSMfrom Fig.6.8
thestatetoken indicates all its contained regions reach the final states. Fig.6.11
shows an example of the labeled composite state.
• Critical labeling : If a composition state is generated from apar fragment with
critical areas, critical tokens are given to the regions and related states:
– Region labeling: Each region is given a critical label that indicates the
critical variables of all other orthogonal regions should beOFF. For exam-
ple, as shown in Fig.6.11, theregion_1_1 is labeled with a critical token
critical_1_2=OFF.
– State labeling: Recall that a critical area in aSDbecomes a pair ofjunc-
tion pseudostates in thePSM. We label the outgoing vertex of the start-
ing junction pseudostate with a token to turn on the critical variable of
the region, and the incoming vertex of the endingjunction pseudostate a
token to turn off the critical variable. As shown in Fig.6.11, the state
S_1_1_1_1 is labeled withcritical_1_1=ON, and the stateS_1_1_1_2
with critical_1_1=OFF.
242
6.1. From Requirements Models to Design Models
• Final state labeling: If there is atau transition from a vertex to thefinal state,
we label the vertex withstate="Final", cf. stateS_2 in Fig. 6.10.
By recursively applying the above rules, aPSMis gradually transformed into a labeled
protocol state machine. The transformation completes when no more rules can be
applied.
6.1.3 Generation of controller classes
Given an interfaceI and itsPSM, an implementing controller classC meets the follow-
ing requirements:
• an operation ofI becomes an operation ofC, with the same signature and func-
tionality definition (if any), and the operation ofC may contain additional guard
and post conditions;
• a property of primitive type becomes a property of same type inC;
• a property of class type becomes an association fromC to that class, and the
name of the association is the same as the property’s;
• all initial constraints andinvariantsof I become those ofC;
• all traces of thePSMcan be executed inC without being blocked by the guards
and preconditions of called operations.
Implementing the structure of the interface in the controller class is straightforward.
In the subsection, we focus on the implementation of the dynamic behavior defined in
the protocols. Taken as input an interface with a labeled protocol state machine, we
generate initial constraints, add pre- and postconditions to the operations, and create
actions that can be automatically executed.
243
6. Enabling Model Transformations of rCOS
6.1.3.1 Adding initial constraints
The state and critical variables introduced in the labeling process become attributes of
the controller class, and they have to be initialized when the class is instantiated. For
example, the following initial constraints derived from Fig.6.11are added to the class
declaration
state ="Init " ∧ state_1_1="Init"∧ state_1_2="Init"∧ critical_1_2=OFF ∧ critical_1_1=OFF
6.1.3.2 Deriving comprehensive pre- and postconditions for transitions
A transition may already hold a precondition representing the guard of the correspond-
ing operand. In order to get the comprehensive pre- and postconditions for a transition,
we have to consider the source and target vertices of the transition. For the precondi-
tion, we include the state tokens on the source vertex and all its parent states, as well
as the critical tokens for the source vertex and all its parent regions. For deriving post-
condition from the target vertex, we consider only the tokens on the vertex itself, since
we assume that the execution of the referred operation will not change the state and
critical variables. For example, the following pre- and post-conditions are generated
for transitionm in Fig. 6.11:
pre: (state_1_1="Init"∧ critical_1_2=OFF)∧ state="Init"
post: state_1_1’="S_1_1_1_1"∧ critical_1_1’=ON
While the pre- and post-conditions for transitionf are:
pre: (state_1_2 ="Init "∧ critical_1_1 =OFF) ∧ state ="Init "
post: state_1_2 ’="Final "
It is obvious that the invocation off cannot immediately follow the invocation ofm, as
the variablecritical_1_1 has been turned on in the postcondition ofm. This preserves
the semantics of thecritical fragment defined in the sequence diagram of Fig.6.8.
244
6.1. From Requirements Models to Design Models
6.1.3.3 Generating guards and postconditions for operations
In this step, we compose the individual pre- and postconditions of transitions referred
to the same operation together to obtain a complete guarded design for the operation.
The guard of the operation is the disjunction of all transition’s preconditions, and we
use "if-then-else" expressions to compose the transition’s postconditions. For example,
let m1 andm2 be two transitions of interface operationm, pr1, pr2 andpst1, pst2 are the
pre- and postconditions of the two transitions, respectively, and[p ⊢ R] be the design
of them. We get the following specification for operationm of the controller class:
m(){ (pr1 ∨ pr2) & [p ⊢ R]; pst1 � pr1 � (pst2 � pr2 � skip) }
or we write it as:
m(){ guard: pr1 ∨ pr2
design: [p ⊢ R];
if pr1 then pst1 else if pr2 then pst2 else skip }
6.1.3.4 Creating actions
Additionally, we create actions to simulate the entry of a composite state, and the
completion of a state machine. An action may need to be generated to activate each
region of a composite state, i.e., if the system is in theprestateof the composite state,
then the state variables of its regions will be set to "Init". For instance, we create the
following action for Fig.6.11:
action_1 (){ guard: state ="Init "
design: [⊢ state_1_1’="Init "∧ state_1_2 ’="Init "] }
If there is a transition from a vertex to thefinal state, and the transition has only a
precondition and does not refer to an operation, we generate an action to complete the
state machine (or region) under this precondition. Consider thePSM in Fig. 6.6, it
needs the following action:
action_1_2(){ guard: (state ="Init " ∨ state="S_1_1")∧ not(c)
design: [⊢ state’="Final"] }
245
6. Enabling Model Transformations of rCOS
6.1.4 An example : clinic reception
The example describes the patient reception process at a clinic. A patient arrives at
the clinic and stops first at the reception desk. The staff here welcomes the patient and
checks if he has been recorded in the clinic’s system (with key information such as
name). For a new patient, the staff creates a unique patient ID. Then the staff creates
a patient ID card, and a label showing the waiting number. Both the card and the
label need to be printed out, and printing of the ID card must immediately follow the
creation of the card. With the ID card and the label, the patient is sent to a specific
doctor’s waiting queue. If the patient had visited the clinic before, the staff only needs
to produce a label, print it out, and send the patient to the waiting queue.
Figure 6.12: Use case and component for clinic reception
Figure 6.13: Interface and controller class for componentReception
246
6.1. From Requirements Models to Design Models
Figure 6.14: System sequence diagram for interfaceReceptDesk
As shown in Fig.6.12, the case study is represented as use caseReceptionand
modeled by a component with interfaceReceptDesk. The left hand side of Fig.6.13
defines the properties and operation signatures of the interface, where we also specify
the functionality. For example, the methodwelcomeis specified as:
public welcome(string name) {
if found(name)then isNew’=false else isNew’=true }
where found is an abstract function to check whether the patient is in the clinic’s
database. We omit all other functionality definitions to save space.
The system sequence diagram shown in Fig.6.14describes the scenario of the use
case. TheisNew condition of thealt fragment determines whether the patient is a
247
6. Enabling Model Transformations of rCOS
Figure 6.15: Protocol state machine for interfaceReceptDesk
newcomer. We use apar fragment to express that the staff can creates either the ID
card or the label first; both of them need to be printed. Acritical operator is used to
ensure that the ID card is printed immediately after its creation.
Applying the transformations discussed previously, we first transform the sequence
diagram into aPSM, as illustrated in Fig.6.15. After labeling it, we generate the con-
troller classReception_Ctr. The right hand side of Fig.6.13depicts the structure of
the class, while the class initializing constraints and the operation specifications are
listed below. Note that in the specification of operationwelcome, part of the function-
ality definition is copied from the interface method. Noaction is generated for the
example.
initial : _state ="Init " ∧ _state_2_2_1="Init "∧ _state_2_2_2="Init "
∧ _critical_2_2_2 =OFF∧ _critical_2_2_1 =OFF
248
6.1. From Requirements Models to Design Models
public welcome(string name) {
guard: _state ="Init "
design: if found(name)then isNew’=false else isNew’=true;
if _state ="Init " then _state ’="S_1"else skip }
public createID (string name) {
guard: ( isNew)∧ (_state ="S_1")
design: if ( isNew)∧ (_state ="S_1")then (_state ’="S_2_1")∧
_state_2_2_1’="Init "∧ _state_2_2_2’="Init "else skip }
public createIDcard (int id ) {
guard: (( _state_2_2_1="Init ")∧ _critical_2_2_2 =OFF) ∧ _state ="S_2_1"
design: if (( _state_2_2_1="Init ")∧ _critical_2_2_2 =OFF) ∧ _state ="S_2_1"
then _state_2_2_1’="S_2_2_1_1"∧ _critical_2_2_1 ’=ON else skip }
public createLabel (int id ) {
guard: ((( _state_2_2_2="Init ")∧ _critical_2_2_1 =OFF) ∧
_state ="S_2_1")∨ ((not(isNew))∧ (_state ="S_1"))
design: if (( _state_2_2_2="Init ")∧ _critical_2_2_1 =OFF) ∧ _state ="S_2_1"
then _state_2_2_2’="S_2_2_2_1"else
if (not( isNew)) ∧ (_state ="S_1")then _state ’="S−2_1"else skip }
public printIDcard (int id ) {
guard: (( _state_2_2_1="S_2_2_1_1")∧ _critical_2_2_2 =OFF) ∧ _state ="S_2_1"
design: if (( _state_2_2_1="S_2_2_1_1")∧ _critical_2_2_2 =OFF) ∧ _state ="S_2_1"
then _state_2_2_1’="Final "∧ _critical_2_2_1 ’=OFF else skip }
public printLabel (int labno) {
guard: ((( _state_2_2_2="S_2_2_2_1")∧ _critical_2_2_1 =OFF) ∧ _state ="S_2_1")
∨ (_state="S−2_1")
design: if (( _state_2_2_2="S_2_2_2_1")∧ _critical_2_2_1 =OFF) ∧ _state ="S_2_1"
then _state_2_2_2’="Final "
else if _state ="S−2_1" then _state’="S−2_2"else skip }
public waitQueue(int labno) {
guard: (_state_2_2_1="Final "∧ _state_2_2_2="Final ")∨ _state="S−2_2"
design: if (_state_2_2_1="Final "∧ _state_2_2_2="Final ")∨ _state="S−2_2"
then _state ’="Final " else skip }
249
6. Enabling Model Transformations of rCOS
Validation : We focus on the specifications concerning the parallel and critical areas.
Let S be a software system that implements the controller class, then:
• after the execution ofcreateID, S is in a state where both the guards ofcreateI-
Dcard andcreateLabelare satisfied, and each of them may be invoked;
• if the createIDcardis executed,S is in state ofcritical_2_2_1=ON, where nei-
ther thecreateLabelnor theprintLabel can be invoked until the execution of
printIDcard, which turns the critical variablecritical_2_2_1 to OFF;
• if the createLabelis executed first,S is in a state where either thecreateIDcard
or theprintLabelcan be performed;
• the guard ofwaitQueuerequiresS in a state ofstate_2_2_1="Final" and
state_2_2_2="Final", that can only be met after both theprintLabelandprint-
IDcard are executed.
Thus we can say that the behavior introduced by thepar and critical fragments of
Fig. 6.14is followed by the systemS.
6.2 From OO Design- to Component-Based Models
In the stage of OO design, the functionality specification of the methods is refined by
decomposition and assignment of responsibilities to corresponding objects, obtaining
a detailed OO model of object interactions represented by object sequence diagrams.
This object sequence diagram refines the sequence diagram of the component (use
case) in the requirements model. For the purpose of reusability, maintenance, and
more importantly, distributed and independent deployment, the OO model needs to be
abstracted to a model ofinteractions of a number of components, that is graphically
represented as acomponent sequence diagramdefined in the UML profile for rCOS.
250
6.2. From OO Design- to Component-Based Models
This section presents the design and implementation of a transformation from a
model of object interaction to a model of component interaction. It requires user inter-
actions. In each step of interaction, the user decides which objects will be turned into
a component, then the transformation is automatically performed. During the transfor-
mation process, a new component is generated, interfaces of the component are iden-
tified from the messages of the object sequence diagram, and a component sequence
diagram is also abstracted from the object sequence diagram by hiding the messages
inside the generated component. Meanwhile, protocols for the new component are
also produced, and component diagrams are modified to represent the relationship of
the components.
Through a finite number of transformation steps with valid selections on the OO
model, the object sequence diagram is entirely transformed to a component sequence
diagram in which the lifelines represent only components. Also, a complete compo-
nent diagram is generated. The transformations of the OO design of all components
thus, one by one, obtain a correct refinement of the initial model of requirements ar-
chitecture to a component-based design architecture in which each component in the
requirements model becomes a composition of a number of components.
However, we need to define the criteria for the selection of objects to form a com-
ponent as the validity conditions of the selection. The tool will check the validity
conditions. We describe the principles of the selection and the validity of selection,
as well as the generation of a component from the selected lifelines below. For the
corresponding algorithms and their explanation, we refer to AppendixB.
6.2.1 Selection of object lifelines
The transformations start with an object sequence diagram and a design class diagram.
First, from the object sequence diagrams, the user selects a set of object lifelines that
she intends to make into a component, and one object lifeline is designated as the
251
6. Enabling Model Transformations of rCOS
controller objectof the selection by the user. This lifeline is also called thekey lifeline
in the rCOS modeler. The principles for picking such a control object not only depend
on checkable conditions of the object but also on design considerations of reusability,
maintainability, and organization of the system being modeled. The major checkable
condition is that this object should be apermanent objectin the sequence diagram. This
means it should have existed before the start of the execution of the sequence diagram
(specified by the precondition of the first message), and it should not be destroyed
during the execution (rCOS does not have destructor methods). This also includes
software objects representing the control of physical devices, such as barcode readers,
controllers of printers, lights, and operating system objects, such as the system clock.
Then the selection of further objects should be made by the user with consideration
of the following conditions and principles:
1. any object lifeline that is a receive end of a creation event from an lifeline that is
already included in the selection must be selected;
2. the objects in the selection must bestrongly connected, i.e. for any lifelineℓ in
the selection there is at least one message path from the controller object toℓ;
3. consider the low coupling and high cohesion principle so that the selected life-
lines have more intensive interaction with each other than with lifelines outside
the selection;
4. lifelines that represent objects which will be deployed on different nodes of a
distributed system should not be included in the same selection.
The first two conditions are must condition and can be easily checked. The third
condition is a desirable principle, and the fourth is a platform dependent condition.
Correspondingly, the first two can be used to automatically extend a selection. The
latter two can never lead to an inconsistent model, but to a model that does not capture
the intentions correctly.
252
6.2. From OO Design- to Component-Based Models
6.2.2 Validating the lifeline selection
Given an object sequence diagramD, we define some notation for describing the vali-
dation of a selection. We useD.linesto denote the set of all lifelines ofD, D.messages
the set of messages, and messages inD.messagesare represented bym[ℓi, ℓj ] for an
message fromℓi to ℓj . That means the object ofℓi invokes a methodm defined in the
object ofℓj . Create-messages indicate constructor invocations.
Let D.selection⊆ D.linesbe a selection, andℓc the designated controller object,
and defineD.rest= D.lines− D.selection. Further, we define
IntraM = {m[ℓi, ℓj ] : ℓi, ℓj ∈ D.selection} Intra-messages among
the selected lifelines
InM = {m[ℓi, ℓj ] : ℓi ∈ D.rest∧ ℓj ∈ D.selection} Incoming messages to
the selected lifelines
OutM = {m[ℓi, ℓj ] : ℓi ∈ D.selection∧ ℓj ∈ D.rest} Outgoing messages from
the selected lifelines
OutsideM = {m[ℓi, ℓj ] : ℓi, ℓj ∈ D.rest} Messages outside
the selected lifelines
A lifeline ℓ in sequence diagramD can be either an object lifeline, denoted bytype(ℓ) =
Class, or a component lifeline, denoted bytype(ℓ) = Component. Now we define the
conditions below for checking the validity of a selection.
1. All lifelines selected must be object lifelines
∀ℓ ∈ D.selection· type(ℓ) = Class
2. The controller objectℓc must be a permanent object. This is done by checking it
is not on the receive end of an object creation message.
∀ℓ ∈ D.lines· (create[ℓ, ℓc] 6∈ D.messages)
253
6. Enabling Model Transformations of rCOS
3. The transformation starts with those lifelines that directly interact with the actor,
then those directly receiving message from the lifelines that have been made into
component lifelines. Therefore any incoming message to the currently selected
ℓc should be from either the actor or a component lifeline
∀m[ℓ, ℓc] ∈ InM · (type(ℓ) = Actor∨ type(ℓ) = Component)
4. Creation messages can only be sent between lifeline inside the selection or be-
tween objects outside the selection
∀ℓi, ℓj ∈ D.lines· (create[ℓi, ℓj] ∈ IntraM ∨ create[ℓi, ℓj] ∈ OutsideM)
5. Any incoming message to the selection is received either by the controller object
or by a lifeline which has a direct path of messages from the controller object
∀m[ℓi, ℓj] ∈ InM · (ℓj = ℓc ∨ ∃m[ℓc, ℓj] ∈ IntraM)
6. The lifelines of the selection must be strongly connected, meaning that for any
selected lifelineℓ, there must be a path of messages from the controller object
m[ℓc, ℓ1], m1[ℓ1, ℓ2], . . . , mi[ℓi, ℓ]
The algorithm to calculate the set of strongly connected lifelines from the con-
troller object can be found at AppendixB.1.
Notice that Conditions 4&6 are closure properties required of the selection, and that the
initial object-sequence diagram of a use case in rCOS always has a use case controller
object that satisfies Conditions 2,3&5. Using induction on the number of lifelines,
these conditions all together ensures existence of a valid selection for any well-formed
sequence diagram that contains object lifelines. Every OO sequence diagram can be
translated into the trivial component sequence diagram which internalizesall object
lifelines into the controller.
254
6.2. From OO Design- to Component-Based Models
6.2.3 Generating a component from selected lifelines
If the selection passes the validity checking, the transformation will be executed to
generate the target models, otherwise an error message is fed back to the tool user. The
transformation is specified in the QVT relational notation. For ease of understanding,
we describe the specification in terms of the relation between the source model and the
target model, similar to the pre- and postcondition specification of a program.
Given a source sequence diagramD, that is an object sequence diagram, and a
valid selectionD.selection, letD’ denote the target sequence diagram of one step of the
transformation. For a lifelineℓ in D (or D’ ), we useop(ℓ, D) (respectivelyop(ℓ, D’)) to
denote the set of method names of the type class ofℓ in D (respectivelyD’ ), type(ℓ, D)
the type of the lifelineℓ in D (respectivelytype(ℓ, D’) in D’ ), andpIF the provided
interface of the component thatℓ represents if the type ofℓ is a component. For a
component lifelineℓ in D (or D’ ), rIF denotes the its required interface. We now
describe the relation betweenD andD’ as the conjunction of the following predicates.
1. The controller objectℓc in D is changed to a component lifeline inD’
ℓc ∈ D.selection∧ type(ℓc, D) = Class
∧ ℓc ∈ D′.lines∧ type(ℓc, D′) = Component
2. An incoming message to the selection inD becomes an invocation to the inter-
face methods ofℓc in D’
∀m[ℓi, ℓc] ∈ InM · (m[ℓi, ℓc] ∈ D’.messages∧ m ∈ pIF(ℓc))
Notice that the order of the messages and fragments are not to be changed.
3. All the intra-object interactions in the selection inD are collapsed, more pre-
cisely hidden inside the componentℓc
∀m[ℓi, ℓj] ∈ IntraM · (ℓi, ℓj 6∈ D’.lines∧ m[ℓi, ℓj] 6∈ D’.messages)
255
6. Enabling Model Transformations of rCOS
4. All the outgoing messages from the selection become outgoing messages from
the component thatℓc represents inD′, with the order and fragments preserved,
and they become the required methods of the component
∀m[ℓi, ℓj] ∈ OutM · (m[ℓc, ℓi] ∈ D’.messages∧ m ∈ rIF(ℓc))
5. No lifelines and messages outside the selection are changed
∀m[ℓi, ℓj] ∈ OutsideM· (m[ℓi, ℓj] ∈ D’.messages)
From the definition of the resulting sequence diagramD’ , its static counterparts, the
components can be defined. The change for the component diagram can be specified
in a similar way. The protocols of the provided interfacepIF(ℓc) and the required
interfacerIF(ℓc) of the newly constructed componentℓc in D’ will be generated.
Next, we give an intuition into how the relations defined above can be directly put
to use through QVT-Relations.
6.2.4 Implementation
Using the QVTR-XSLT tool, the transformation is specified as three transformation
models to do the following work:
1. validate the lifeline selection;
2. generate a component from the selected object lifelines with provided/required
interfaces and corresponding operation signatures, plug the new component to
other existing components;
3. update the corresponding sequence diagrams, component diagrams, state dia-
grams and class diagrams in light of the above changes;
4. generate a new sequence diagram and a new state diagram as the protocol for the
new component;
256
6.2. From OO Design- to Component-Based Models
5. update the corresponding visual representations of the above diagrams.
In total, the transformation contain 105 relations, and 45 functions and queries.
About 6300 lines of XSLT code are generated for implementation of the transforma-
tion.
<<Relation>>
ObjToComLifeline
{when=LifelineToCom(lfl,com);}
<<Domain>>
seq : Interaction
com : Component
name = "propnm"
xmi:id = "propid"
: Property
name = "propnm"
xmi:id = "propid"
: Property
<<Domain>>
tseq : Interaction
name = "lflnm"
xmi:id = "lflid"
: Lifeline
name = "lflnm"
xmi:id = "lflid"
lfl : Lifeline
lifeline
ownedAttribute
represents
represents
lifeline
type
Figure 6.16: A relation to generate a component lifeline
Fig. 6.16illustrates a QVT-R relation which converts an object lifeline to a com-
ponent lifeline. Under the root objectseq tagged with label«Domain», the source
domain pattern of the relation includes aLifeline lfl with its representingProperty.
And the target domain pattern has a similar structure.
When the relation is executed, the source domain pattern is searched in the source
model. If a match is found, thelifelineand thepropertyare bound to instances of source
model elements, and the variables defined within them are instantiated with values
coming from the attributes of the instances. The target domain pattern of the relation
acts as a template to create objects and links in the target model. In this example, the
target domain pattern creates alifelineobject and apropertyobject. Both objects own a
nameand anxmi:id attributes. These two attributes get values from the variables bound
to the corresponding elements of the source domain pattern. Moreover, theproperty
257
6. Enabling Model Transformations of rCOS
object of the target model now has an associationtype that is set to the component
com, which is bound (and possible created) by the relationLifelineToComin thewhen
clause.
6.3 Case Study
The Common Component Modelling Example (CoCoME) [5; 39] describes a trading
system that is typically used in supermarkets. Similar to the example used in Sec-
tion 2.3, this case study originated from Larman’s book [103]. It deals with the various
business processes, such as processing sales at cash desks, handling payments, and
updating the inventory. The system maintains a catalog of product items and records
the amount of each item available. It also keeps the historical records of sales, each of
them consists of a number of line items with the product item and the amount sold.
In this section, we use the rCOS modeler to design a simplified version of this sys-
tem, focusing on stepwise application of the transformations described in the previous
sections to refine an initial requirements model into a component architecture design.
6.3.1 Requirements modeling
Using the rCOS modeler, we first abstract the domain concepts of the system and their
relationships into a domain class diagram, as shown in Fig.6.17.
In this case study, there can be many use cases, depending on what business pro-
cesses the client wants the system to support. One of the use cases,process sale(see
Fig. 6.18), describes the check out process: a customer takes the products she wants
to buy to a cash desk, the cashier records each product item, and finally the customer
makes the payment. The use case is modeled by a componentProcessSalewith the
interfaceCInter, depicted in Fig.6.19.
The scenario of the use case is described by a system sequence diagram that is
then created for interfaceCInter. To model the check out process, we add combined
258
6.3. Case Study
Figure 6.17: Domain class diagram of CoCoME example
Figure 6.18: Use caseProcessSale Figure 6.19: ComponentProcessSale
fragments and messages to the sequence diagram, while the corresponding method
signatures will be automatically generated in the interface. In addition, we input the
RCOSPspecification for each method in a textual window below the diagram editor.
The completed sequence diagram is shown in Fig.6.20, and the method signatures and
properties of the interfaceCInter are depicted in Fig.6.21.
The followingrCOSP code is input for the methods of interfaceCInter:
public startSale () {
var Date date = clock. date ();
[ ⊢ sale’ = Sale. new(false, date )]
}
259
6. Enabling Model Transformations of rCOS
Figure 6.20: Sequence diagram forCInter Figure 6.21: Interface ofProcessSale
public enterItem (Barcode code,int qty) {
[ qty > 0 ⊢ true];
[ ∃Item i: store . catalog . contains ( i )∧ i.barcode = code⊢ true];
[ ⊢ line’ = LineItem.new(code, qty)];
[ ⊢ ∃Item j: store.catalog. contains ( j )∧ j.barcode = code∧ line.subtotal ’ = j . price ∗ qty];
[ ⊢ sale.lines . add(line )]
}
public finishSale () {
var double sum;
sum:=0;
for (LineItem l : sale . lines ) {
[ ⊢ sum’ = sum + l.subtotal]
};
[ ⊢ sale.total ’ = sum]
endsum;
[ ⊢ sale.complete’ =true]
}
public cashPay(double a; double c) {
[ a >= sale . total ⊢ sale.pay.makePay(a, (a− sale . total ))];
[ ⊢ store.sales . add(sale )];
260
6.3. Case Study
[ ⊢ ∀ LineItem l:∀ Item p: sale.lines . contains ( l )⇒ store.catalog. contains (p)⇒
(p. barcode = l . barcode⇒ p.stock’ = p.stock− l. quantity )];
[ ⊢ c’ = a − sale. total] }
whereaddandcontainsare functions defined for the collection types.
Applying thesequence diagram to state diagram transformationdiscussed in Sec-
tion 6.1.1, we generate a protocol state machine for interfaceCInter, as illustrated in
Fig. 6.22.
Figure 6.22: Protocol state machine forCInter
Through checking the OCL well-formedness rules defined in the rCOS profile and
type checking the interface method specifications, we can ensure the static consistency
of the model. In addition, we can check the dynamic consistency of the model by
generating a CSP specification for the model, and do the checking in the FDR2 model
checker. Thus, we get a ”correct” requirements model that consists of aconceptual
class diagram, a use case diagramwhere a use case is modeled as a component with
a provided interface, asequence diagramand aprotocol state machineto describe the
261
6. Enabling Model Transformations of rCOS
behavior of the use case. Also, each method of the interface has an rCOS design to
specify its data functionality.
6.3.2 Object-oriented design
Figure 6.23: The controller class for interfaceCInter
To start the object-oriented design, we must first transform the requirements model
into an initial design model. This is done by first labeling the protocol state machine,
and then generate a controller classProcessSale_Ctrwhich implements the interface
CInter, as shown in Fig.6.23. As we will continue to the component-based design
stage, we don’t generate guarded designs for methods of the controller class, but just
copy the method specifications from the interface. Meanwhile, from the sequence
diagram of the interface, an initial object sequence diagram for the controller class
is created by replacing the interface lifeline with a lifeline representing the controller
class.
Then we apply theexpert pattern transformationinteractively to refine the object-
262
6.3. Case Study
Figure 6.24: Interactively applying expert pattern
oriented design of the model. From the view of the object sequence diagram, we open
the rCOS specification of a message’s corresponding method, select a fragment of it,
and delegate to an object of another class. For example, as shown in Fig.6.24, we select
the fragment ”[∃Item i : store.catalog .contains(i) ∧ i .barcode = code ⊢ true];” from the
specification of messageenterItem, and choose ”Design delegation...” from the popup
menu. The tool analyzes the selection, and provides a candidate target object to assign
the responsibility, e.g.store in the figure. After we input the name of the method
that will be created to perform the delegated responsibility, e.g.findItemhere, the
execution of the transformation replaces the selection part with ”store.findItem(code);”,
and creates a methodfindItemin classStoreas follows:
public findItem (Barcode x3) {
[ ∃ Item i: catalog . contains ( i )∧ i.barcode = x3⊢ true] }
Accordingly, the object sequence diagram is changed into the one shown in Fig.6.25.
263
6. Enabling Model Transformations of rCOS
Note that a new lifelinestoreof typeStoreis created, and a new message that invokes
methodfindItemis also added to the diagram.
Figure 6.25: The object sequence diagram after applying expert pattern
As another example, for messagefinishSale, we select the following fragment from
its method specification:
var double sum;
sum:=0;
for (LineItem l : sale . lines ) {
[ ⊢ sum’ = sum + l.subtotal]
};
[ ⊢ sale.total ’ = sum]
endsum;
We delegate the selection to objectsaleof classSaleas a methodupdateTotalthat will
be generated to calculate the total value of a sale. Now, the specification for method
finishSaleis refined to :
public finishSale () {
sale . updateTotal ();
[ ⊢ sale.complete’ =true] }
264
6.3. Case Study
Figure 6.26: The object sequence diagram after OO refinement
Figure 6.27: Design class diagram of CoCoME example
Finally, after applying the expert pattern to each of the messages, the object se-
265
6. Enabling Model Transformations of rCOS
quence diagram of classProcessSale_Ctris refined to Fig.6.26, and the domain class
diagram of Fig.6.17is therefore changed to a design class diagram shown in Fig.6.27.
Meanwhile, the method specifications for classProcessSale_Ctrare refined to:
public startSale () {
var Date date = clock. date ();
[ ⊢ sale’ = Sale. new(false, date )]
}
public enterItem (Barcode code,int qty) {
[ qty > 0 ⊢ true];
store . findItem (code);
[ ⊢ line’ = LineItem.new(code, qty)];
line . setSubTotal (store , qty, code);
sale . addLine(line )
}
public finishSale () {
sale . updateTotal ();
sale . setComplete()
}
public cashPay(double a; double c){
sale . makePay(a);
store . addSale(sale );
store . updateStock(sale );
[ ⊢ c’ = a − sale . total]
}
Accordingly, in total 8 methods are newly created in the class model:
public Store :: addSale(Sale x1) {
[ ⊢ sales.add(x1)]
}
public Store :: upDateStock(Sale x2) {
[ ⊢ ∀ LineItem l:∀ Item p: x2.lines. contains ( l )⇒ catalog.contains(p)⇒
(p. barcode = l . barcode⇒ p.stock’ = p.stock− l. quantity )]
}
266
6.3. Case Study
public Store :: findItem (Barcode x3) {
[ ∃Item i: catalog . contains ( i )∧ i.barcode = x3⊢ true]
}
public Sale:: updateTotal () {
var double sum;
sum:=0;
for (LineItem l : lines ) {
[ ⊢ sum’ = sum + l.subtotal]
};
[ ⊢ total’ = sum];
endsum
}
public Sale:: setComplete() {
[ ⊢ complete’ =true]
}
public Sale:: addLine(LineItem x5) {
[ ⊢ lines. add(x5)]
}
public Sale:: makePay(double x1) {
[ x1 >= total ⊢ pay.makePay(x1, x1− total)]
}
public LineItem:: setSubTotal (Store x1,int x3, Barcode x2) {
[ ⊢ ∃Item j: x1.catalog.contains( j )∧ j.barcode = x2∧ subtotal’ = j . price ∗ x3]
}
6.3.3 Component-based design
Based on the object-oriented design model which contains a set of object sequence
diagrams, we start to produce a component-based model by using theobject sequence
diagram to component sequence diagram transformationin a stepwise, incremental
manner.
We work on an object sequence diagram similar to the one shown in Fig.6.26.
267
6. Enabling Model Transformations of rCOS
It consists of six lifelines. The leftmost one represents theactor, and followed by
lifelines proce, sale, line, storeandpay, representing respectively the objects of class
ProcessSale_Ctr, Sale, LineItem, StoreandPayment. Based on our understanding of
the case study, and the sequence- and class diagram, we decide to apply the object- to
component sequence diagram transformation three times.
Figure 6.28: Select lifelines to become a component
In the first we deal with the lifelineproce, which is directly interacting with the
actor. Since lifelinessaleand line are created by theproce, three of them have to be
in the same component. As shown in Fig.6.28, we select these three lifelines from
the sequence diagram, click on the ”Lifelines to Component (single component)” from
the popup menu. As we mentioned before, the tool will check whether the selected
lifelines can be transformed to a component, and try to decide thekey (controller)
lifeline itself. Here theproceservers as the key lifeline. If it can’t decide the key
lifeline, a popup window will appear to ask the user to choose one. By the way, if
we select all the lifelines of the diagram, and click on the ”Lifelines to Component (by
partition)” from the menu, these lifelines will be automatically divided into several
groups, and each group is translated into a component.
However, if the selection is not valid, an error message will be displayed. For
268
6.3. Case Study
Figure 6.29: Validation error message
instance, if we choose lifelinessale, line andstore to become a component, the tool
will pop up an error message, as shown in Fig.6.29.
The first execution of the transformation translates the three selected lifelines into
a service componentCOM_proce, and changes the sequence diagram to the one shown
in Fig.6.30, where lifelineprocenow represents the new component, and lifelinessale
andline, along with their internal messages, are removed from the diagram.
The resulting componentCOM_proce, as shown in the component diagram of
Fig.6.31, is a sub-component ofProcessSale, and connects to the latter through a port.
This diagram is therefore a ”child” component diagram of Fig.6.19, for the purpose
of showing the internal structure of componentProcessSale. ComponentCOM_proce
has a provided interfaceConInter_proceand a required interfaceRInter_proce. The
definitions for the component, including the operation signatures of the interfaces, is
shown in Fig.6.32. In here, the two removed lifelines,saleandline, become properties
(rCOSfields) inside the componentCOM_proce.
For the second and third transformations, we select the lifelinesstoreandpayfrom
the sequence diagram of Fig.6.30, and turn them into componentCOM_storeand
COM_pay, respectively. As the result, we obtain the component sequence diagram
shown in Fig.6.33, in which all lifelines represent components, except the onerep-
resenting the actor. Accordingly, the component diagram is changed to the one de-
269
6. Enabling Model Transformations of rCOS
Figure 6.30: The sequence diagram after the first transformation
Figure 6.31: Component diagram after first transformation
picted in Fig.6.34, in which the provided interfaces of componentsCOM_storeand
COM_payare plugged to the required interface of componentCOM_proce, and the last
270
6.3. Case Study
Figure 6.32: Definitions of componentCOM_proce
component realizes the functionality of componentProcessSale. TheRCOSPcounter-
part of the component diagram is shown for comparison in Listing6.35.
Figure 6.33: Component sequence diagram for componentProcessSale
271
6. Enabling Model Transformations of rCOS
Figure 6.34: Component diagram forProcessSale
componentProcessSale {provided interface CInter
by COM_proce.ConInter_proce {/∗Method∗/...protocol {...}
}composition : COM_proce|COM_store|COM_pay
[(COM_proce.RInter_proce<< COM_store.ConInter_store),
(COM_proce.RInter_proce<< COM_pay.ConInter_pay)]
componentCOM_proce {public LineItem line;public Sale sale;provided interface ConInter_proce {...}required interface RInter_proce {...}
}componentCOM_store {
provided interface ConInter_store {...}}componentCOM_pay {
provided interface ConInter_pay {...}}
}
Listing 6.35: ComponentProcess-Salein RCOSP
Protocols of components. We also automatically generate rCOS protocols for the
interfaces of the newly created components. For a provided interface, the protocol
consists of a sequence diagram and a protocol state diagram. For example, theprovided
protocolfor componentCOM_storeis shown in Figs.6.36& 6.37. But for a required
interface, we usually provide it with a protocol state machine, as the one shown in
Fig. 6.38 for the required interfaceRInter_proceof componentCOM_proce. This
state machine defines the possible sequence of method invocations.
Through applying the object sequence diagram to component sequence diagram
transformation three times, we have successfully developed the OO design model of
CoCoME into a component model. In the model, a component of use case is decom-
posed into, and realized by a composition of a number of sub-components within the
component, and the connections and interactions of these sub-components are illus-
trated by a component diagram and a component sequence diagram, respectively. In
addition, each component in the model has its provided/required interfaces, as well
272
6.3. Case Study
Figure 6.36: SD ofCOM_store Figure 6.37: PSM ofCOM_store
Figure 6.38: PSM for the required interface of componentCOM_proce
as protocols, each consists of a sequence diagram and a state diagram, to define the
behaviors of the component.
273
6. Enabling Model Transformations of rCOS
6.3.3.1 Applying rCOS component operators
Starting from the component model, rCOS component composition operators, such as
renaming, plugging, andparallel composition, can be applied to optimize the structure
of the model, or build new components from the existing ones.
For the component diagram of Fig.6.34, we contemplate combining the compo-
nentsCOM_storeand COM_payinto a single component for the purpose of better
deployment. First we remove the«Composition» connections between the required
and provided interfaces, then select these two components, and choose the ”Compose
components” from the rCOS popup menu, as shown in Fig.6.39.
Figure 6.39: Apply component composition
Applying the composing operation generates a new componentCOM_pay_SHde-
picted in Fig.6.40. It has a single provided interface. As the interfaces ofCOM_store
andCOM_payare disjoint from each other,COM_pay_SHis the result of thedisjoint
unionof that two components. Its provided protocol is shown in Fig.6.41& 6.42.
In the next step, selecting the ”Plug components” from the rCOS popup menu, we
274
6.3. Case Study
Figure 6.40: Result of component composition
Figure 6.41: Sequence diagram for componentCOM_pay_SH
plug the provided interface ofCOM_pay_SHinto the required interface ofCOM_proce.
The tool will check the composability of these two interfaces:
• Method signatures: Both interfaces have at least one identical method signature.
It is obvious that all the method signatures of the two interfaces are identical.
• Behavior protocols: We generate the following CSP processPR from the PSM
275
6. Enabling Model Transformations of rCOS
Figure 6.42: PSM for componentCOM_pay_SH
of the required interfaceRInter_proceshown in Fig.6.38:
PR = (findItem!→ PR) � moreItem� (makePay!→ addSale!→ updateStock!→ SKIP)
From the PSM shown in Fig.6.42, also we produce the CSP processPC for the
provided interfaceConInter_pay_SHof componentCOM_pay_SHas follows:
PC = (PC1 ‖| PC2); SKIP
PC1 = (findItem?→ PC1) � moreItem� (addSale?→ updateStock?→ PC )
PC2 = makePay?→ PC
It can be proved in FDR that the parallel composition of these two processes
PC ‖ PR is deadlock free. Thus, the method invocation traces specified in the
protocol of interfaceRInter_proceare accepted by the provided protocol of
COM_pay_SH, and the interactions of the two components will not be blocked.
Fig. 6.43shows the resulting component diagram for theProcessSale. We also list
its RCOSPcounterpart in List6.44.
276
6.4. Related Work
Figure 6.43: Optimized component diagram forProcessSale
componentProcessSale {provided interface CInter
by COM_proce.ConInter_proce {...}
composition : COM_proce|COM_pay_SH[(COM_proce.RInter_proce
<< COM_pay_SH.ConInter_pay_SH)]
componentCOM_proce {...provided interface ConInter_proce {...}required interface RInter_proce {...}
}componentCOM_pay_SH {
provided interface CInter_pay_SHby COM_store.ConInter_store,
COM_pay.ConInter_pay {...}composition : COM_proce|COM_pay
[(COM_store || COM_pay)]
componentCOM_store {provided interface ConInter_store {...}
}componentCOM_pay {
provided interface ConInter_pay {...}}
}}
Listing 6.44: Optimized compo-nent model inRCOSP
However, starting from a verified requirements model shown in Fig.6.18-6.21, we
have, step by step, developed a model of component architecture as depicted in the
component diagram of Fig.6.43, through incremental applying the rCOS transforma-
tions of requirements model to OO model, functionality delegation, object sequence
diagram to component sequence diagramandcomponent compositions. The correct-
ness of the component model is ensured as these transformations implement rCOS
refinement principles. Based on the component model, one can generate program code
for the components and accordingly deploy them to form a software system.
6.4 Related Work
The transformation from scenario-based interaction diagrams to state-based models is
one of the key activities in OOAD [169]. It allows designers to concentrate on model-
ing requirements, and automatically get executable and simulatable state models which
277
6. Enabling Model Transformations of rCOS
are required in design processes. Algorithms that transform scenarios into state ma-
chines are often called synthesis algorithms. Many approaches have been proposed to
address the algorithms. Amyot and Eberlein [16], and Liang et al. [108] have evaluated
more than twenty of them. However, most of the works date back before UML 2.0.
The scenario languages they used lack control constructs, such as combined fragments
and interaction uses introduced in UML 2.0 sequence diagrams. Scenarios are writ-
ten in isolation and their relationships are not specified [170]. Therefore, the problem
that mainly captured researchers’ attention is how to decide the relationships between
different scenarios. These approaches require a significant additional modeling effort
from the user [170].
The work of [72] deals with most combined fragments of UML 2.0, such asalt, opt,
loopandpar, but leaves out theinteraction uses. The transformation is defined through
graph transformations based on concrete syntax. In [182], an algebraic framework for
synthesizing statecharts from UML 2.0 sequence diagrams was proposed. Only three
operators (seq, alt andloop) are supported, and the approach takes sequence diagrams
in textual format as inputs. The aforementioned [170] usesinteraction overview di-
agrams, instead ofinteraction uses, to specify relationships between scenarios. This
is the only work we have seen that supports the interaction overview diagrams. Most
work in this area focus on the synthesis algorithms, whereas the integration in indus-
trial practice remains implicit [70; 79].
Our SD to PSMtransformation is similar to the ones described at [72; 170] in that
we support most of the combined fragments of UML 2.0, including theinteraction
uses. Particularly we translateparallel into PSM’s orthogonal regions, and we support
critical fragments. We integrate multiple scenarios of a single interface throughinter-
action uses, and our transformation generates UML protocol state machines suitable
for the definition of contract protocols.
Our approach to label the state machines is similar to the techniques used in [81],
where state variables are introduced to represent the current configuration. The system
278
6.4. Related Work
controls a single variable which represents the message sent by a system object in the
current step. Then the current state of the system automaton can be represented by the
variable, ranging over its states. In our approach, we define a state variable for each
region of thePSM, and simply use the name of a state as the value of the state variable.
However, the algorithm we used to label the state machines is unique as we consider
hierarchical state- and critical variables. Elkoutbi et al. [56] proposed a way to label a
state machine with pre- and postconditions of the underlying class, and [48] proposed
atechnique to construct state models from contract specifications, i.e. operations spec-
ified with pre- and postconditions, for the purpose of contract inspection, animation
and simulation. We consider these two works as the inverse of our approach, since we
generate contract specifications from state machines. In addition, the work of [143]
also generates class contracts, as a pre- and post-condition for each operation, from a
protocol state machine with state invariants. The invariants are manually added to each
state of the state machine. Our approach uses labeledPSMsto generate the contracts,
and the labels are automatically produced from the sequence diagrams.
As a natural step of model driven development, object-oriented models are further
evolved to component-based models to get the benefits of reusability, maintenance,
as well as distributed and independent deployment. Surveys of approaches and tech-
niques for identifying reusable components from object-oriented models can be found
in [25; 167]. Based on the principle of “high cohesion and low coupling”,researchers
try to cluster classes into components. The basic ideas are: calculate the strength of
semantic dependencies between classes and transform them into the form of weighted
directional graph, then cluster the graph using graph clustering or matrix analysis tech-
niques [167]. Using clustering analysis, components with high cohesionand low cou-
pling are expected to be obtained in order to reduce composition cost.
Particularly, since use cases are applied to describe the functionality of a system,
the work of [153] focuses on applying various clustering methods to cluster use cases
into several components. In [59], the static and dynamic relationships between classes
279
6. Enabling Model Transformations of rCOS
are used for clustering related classes in components, where static relationship mea-
sures the relationship strength, and dynamic relationship measures the frequency of
message exchange at runtime. COMO [105] proposed a method which measures inter-
class relationships in terms ofcreate, retrieve, updateanddelete(CRUD) operations
of model elements. It uses a dynamic coupling metric between objects to measure
the potential number of messages exchanged. All the above approaches are based on
clustering algorithms, which makes them much different from our approach, where
transformations are applied at thedesign stageby a human.
Identifying reusable components from object-oriented models is considered to be
one of the most difficult tasks in the software development process [59]. Most existing
approaches just provide general guidelines for component identification. They lack
more precise criteria and methods [44]. Because of the complexity of source infor-
mation and the component model itself, it is not advisable for component designers to
manually develop component-based models from object-oriented models [167]. Alas,
there are almost no (semi)-automatic tools to help designers in the development pro-
cess [153].
Sequence diagrams have of course already been used informally in UML-based
modeling since their conception. Recently, [80] presents a rigorously defined variant
called “Life Sequence Charts” with tool support to use them for system design. The
focus there is however not on component modeling, but giving a formal semantics to
sequence charts for synthesis.
The rCOS approach of refinement driven development has long been studied in the
rCOS group. In [39], we have studied this top-down development process, carried out
by hand, for the CoCoME case study. Our process is motivated by an industrial CASE
tool, MASTERCRAFT [111]. There, the focus is on the design and refinement of the
relational method specifications using the rCOS language. In [180], we have discussed
an informal approach to using transformations for rCOS, and a variant of treating se-
quence diagrams in particular. Apart from general discussion, QVT Relations trans-
280
6.5. Summary
formations for the MODELMORF engine using custom metamodels for sequence- and
class diagrams were given as a proof of concept. Based on this experience, we set out
on a more formal quest forprovably correctmodel transformations.
In the work of [37], the functionality specification of a transition is specified in
terms of a design as a pair of pre-/postconditions, and an integrated specification of
methodm is defined as disjunction of the functionality specifications of all transitions
that may react to invocation ofm. The approach integrates the state machine with a
class and gives complete behavior definitions for the methods. In [41] we provide full
model- and code generation for the approach. The transformation for the generation
of method bodies presented in this chapter is also based on this approach, but with an
extension to support concurrency and critical constructs.
Application of the expert pattern in the rCOS modeler was also discussed in [158].
The work is carried out in the view of class diagrams with a similar algorithm, but
updating of the corresponding sequence diagrams is not considered.
In this chapter, we have formalized the desired outcome in the style of OCL formu-
las on input- and output models, and the transformations themselves are also syntacti-
cally checked using OCL. However, the correctness of the formulation with respect to
the logically defined refinement relation between the input- and output models still re-
quires a formal proof. To this end, our colleagues have already studied the automated
generation of proof obligations for object-oriented refinements [113]. For transfor-
mations on the component level, we do not expect proofs to be dynamic, but rather
that a transformation can be proved correct once, and then just checking a syntactic
precondition on the input for input validation.
6.5 Summary
The purpose of our work in the thesis is automating the rCOS correctness preserv-
ing transformations and integrated them into tool support. We present four of them
281
6. Enabling Model Transformations of rCOS
in this chapter. These transformations are not isolated. They sequentially cover all
phases of component-based, model-driven development of rCOS. We discuss in detail
two of the transformations which bridge the gap between requirements models and
OO design model, and between the OO design model and component-based model.
The first transformation automatically processes system sequence diagrams into con-
troller classes with method guards which enforce the semantics of sequence diagrams,
through an intermediate step of generating protocol state machines. The second one,
the object sequence diagram to component sequence diagram transformation, improves
the component-based model-driven software design in practice by allowing the seam-
less combination of object-oriented and component-based techniques.
These transformations are defined in the graphical notation of QVT Relations us-
ing the QVTR-XSLT tool. The QVT-R specifications are then automatically trans-
formed to executable XSLT programs, and integrated into the rCOS modeler. Many
new features found in sequence diagrams and protocol state machines of UML 2.0 are
supported by the transformations. The rCOS modeler that implements the transforma-
tions discussed here can be downloaded with examples fromhttp://rcos.iist.
unu.edu/.
282
Chapter 7
Conclusions and Future Work
This chapter summarizes the work of the thesis, discusses the limitations and proposes
future work.
7.1 Conclusions
MDA is current a mainstream approach to component-based software design through
raising the level of abstraction, separation of concerns and software reuse. In MDA, a
software system is developed based on model construction, validation/verification, and
composition in a development process, either top down waterfall or bottom up synthe-
sis. Model transformations play the key role in the process. In the top down process,
a transformation refines the source model by adding more design and implementation
details, and in the bottom up process a transformation composes a number of source
models for architecture refinement. Model transformations can also be used to abstract
models for the purpose of formal verification.
However, for correct construction of a software system, model transformations
should be semantic preserving. To support incremental development, model trans-
formations have to be compositional. This requires that models, model compositions
and transformations are precisely defined using formal modeling languages. Further-
more, the MDA approach can be effectively useful only when automated tool support
is available, especially the automation of the model transformations.
The work presented in this thesis is on supporting a MDA development process
using automated model transformations. To complement MDA with a precise seman-
tics and a meticulous development methodology, we adopt the rCOS in the research.
It provides a precise multi-view modeling notation for object and component systems,
283
7. Conclusions and Future Work
a formal semantics for model verification and validation, and a comprehensive refine-
ment calculus that implements as correctness preserving model transformations. The
rCOS development process is driven by applying these model transformations.
It is challenging and important to investigate these transformations on both theo-
retical and practical grounds, and automate them into software tools. Development of
such a tool requires understanding of formal methods to correctly encode the require-
ments and algorithms, such as applications of different design patterns. It is not enough
to only provide a library of the transformation implementations, more importantly, the
tool should provide guidance on which rule is most suitable in current state. It is also
difficult to support consistent and correct checking of the transformations.
In this thesis, we tackled this challenge by developing a novel model transforma-
tion approach and its implementation tool to support the graphical syntax of QVT
Relations, the OMG’s standard high-level declarative model transformation language.
With the help of this tool, we designed and implemented a set of model transformations
proposed in rCOS refinement calculus, and integrated them into the rCOS modeler, a
CASE tool for rCOS development. In particular, we presented an approach to automat
the transformation from object-oriented models to component models, so the object-
oriented design and component-based techniques can be seamlessly combined in the
development process. We also support the transformations of requirements model to
OO design model, functionality delegation, and component composition. To standard-
ize rCOS method and facilitate the application of these transformations, we defined a
UML profile with necessary stereotypes, tagged values and constraints to represent the
concepts of rCOS in UML, and to support the development methodology of rCOS.
In the following, we summarize the works we consider as the major contributions
of the thesis:
A model transformation approach and tool. In Chapter4, we presented a practi-
cal model transformation approach to support the graphical syntax of QVT-R through
284
7.1. Conclusions
mapping to XSLT. In our approach, we specify a transformation as a set of QVT-R
relations between the elements of source and target metamodels using the graphical
notation of QVT-R. Then the transformation is implemented as an XSLT stylesheet,
where every relation maps to an XSLT rule template. Since QVT-R relies heavily on
the use of OCL, we designed a way to map OCL into XPath, a sub-language of XSLT,
by mapping OCL’s types, expressions and operations into semantic equivalent XPath
constructs.
We support unidirectional non-incremental enforcement transformations of QVT-
R. The features of our approach include transformation inheritance through rule over-
riding, traceability of transformation executions, multiple input and output models,
and in-place transformations. To improve the usability of QVT-R, we extended the
language with additional transformation parameter, relation alias name and priority,
as well as conditional relation call. We also proposed a novel graphical model query
facility, which is based on the checking semantics and pattern matching mechanism of
QVT-R, and also uses the graphical notation. The model query facility can work seam-
lessly within QVT-R transformations. In addition, we have developed a collection of
pre-defined transformations for improving the interoperability of the tool, as well as
for transformation verification and validation.
The tool for supporting the graphical notation of QVT-R and the model query fa-
cility, named QVTR-XSLT, is designed as two parts: a QVT-R graphical editor and
an XSLT code generator. To build the tool in a standard, model-driven way, we pro-
posed a UML profile to represent the abstract syntax of QVT-R. With a user-friendly
user interface, the graphical editor of the tool supports the definition of metamodels as
simple UML class diagrams, the specification of QVT-R transformations and queries
using the graphical notation. The code generator can automatically translate a QVT-R
transformation into executable XSLT programs. To evaluate our approach and tool, we
presented a case study and compared the transformation execution traces and results
with a popular QVT-R tool known as a faithful implementation of the QVT-R standard.
285
7. Conclusions and Future Work
Our approach is founded on the OMG and W3C standards, and makes use of well-
known and commonly adopted languages and CASE tools. It is quite easy and user-
friendly to design QVT-R rules in the editor, because all objects and links are restricted
by selecting from the source and target metamodels, effectively providing a graphical
domain-specific language. Such syntax-directed editing can reduce the number of er-
rors, as it only permits mostly well-typed models. The generated XSLT programs
for the transformations can be directly executed under any XSLT processor on any
platform, and can be easily integrated into other applications and systems. As there
are already many industrial-strength XSLT processors, such asSaxonandXalan, our
transformations can run fast and efficiently process large-scale models.
The QVTR-XSLT tool can be applied to a wide variety of source-to-target and
in-place model transformations. Many transformation scenarios, such as platform in-
dependent model (PIM) to platform specific models (PSM) transformations, or the
transformations of UML models to models of formal languages (such as CSP), are
well supported. Data transformation in data engineering is another potential applica-
tion field for the tool. Using the tool, the structures of the XML data can be described
concisely by metamodels, and the mappings between the data can be specified by re-
lations of QVT-R using the high-level graphical notation. In addition, the tool can
be used in the fields of semantic web and ontologies, often there is a need to convert
between different knowledge models, which are also in XML formats.
Since at the present time practical tool supports for the graphical notation of QVT-
R is scarce, our approach and tool mark a useful attempt to bring the language to
practice. Most importantly for the work of the thesis, the tool is able to meet the high
demands for the implementation of rCOS model transformations, and thus has been
used in design of these transformations.
A UML profile for supporting rCOS method and development methodology. In
Chapter5, we proposed a UML profile with which the rCOS techniques and method-
286
7.1. Conclusions
ology can be applied to component-based software development in a standard model-
driven way. The rCOS profile provides rCOS with the power of the OMG UML stan-
dardized graphical notation and tool supports for system and software modeling, while
it supplies UML with a precise semantics, additional modeling concepts for compo-
nents composition, formal consistency verification and refinement techniques, and a
design methodology based on correctness preserving model transformations in the ap-
plication domain of the component-based model-driven development. Linking with
UML increases the usefulness of rCOS, and thus greatly helps the end users to model
a syntactic correct rCOS application.
We use a systematic approach to design the rCOS profile, starting from building
the domain metamodel to capture the basic concepts of rCOS, then mapping them
into stereotypes and their attributes, and adding the OCL well-formedness constraints,
while considering the support of rCOS development. In addition, we defined the ar-
chitecture and parts of an rCOS model, such as class, interface, component, sequence
diagram and state machine diagram, to model the views of reactive behavior, inter-
action, class structure and component composition, and to facilitate the definition of
rCOS model transformations.
We implemented the profile in a CASE tool –rCOS modeler. Based on the rCOS
profile, the tool focuses on supporting the rCOS development process with a user
friendly interface. It integrates the rCOS refinement rules, such as expert pattern and
structural refinements, as correctness preserving model transformations. We also pro-
posed an interactive, stepwise procedure to develop rCOS models in the rCOS modeler
through applying the refinement transformations.
Design and implementation of a set of rCOS model transformations. The rCOS
has a rather comprehensive refinement calculus. We design and implement a set of
the refinement rules as model transformations using the QVTR-XSLT tool, and in-
tegrate the transformations into the rCOS modeler. In Chapter6, we presented four
287
7. Conclusions and Future Work
of the refinement transformations that are frequently used in different stages of rCOS
development:
• Requirements model to OO design model:This transformation converts a re-
quirements model into an initial OO design model by synthesizing a protocol
state machine from the system sequence diagrams of a use case component, and
deriving a controller class as an implementation of the component. We translate
the rCOSdesignsof the component methods intoguarded designsfor the meth-
ods of the controller class, thus the semantics introduced by the sequence dia-
grams are faithfully preserved by the controller class. The transformation takes
into account the concurrency and critical area of the respective diagrams. The
generated model can sever as the starting point for the detailed object-oriented
design, such as applying the expert pattern. Therefore the transformation helps
to bridge the gap between requirement models and OO design models.
• Functionality delegation:This is also called theexpert patternof responsibility
assignment, one of the most important rCOS OO refinement rules. It refines a
functionality specification into object interactions, based on a given class struc-
ture, thus a particular responsibility is assigned to an appropriate object that
knows the required data. In this transformation, first a fragment of a method
specification is selected, either manually by the user or automatically by the tool,
and then the selected part is evaluated to find a suitable target object to delegate
to. Execution of the transformation synchronously modifies the model by creat-
ing a new method in the class of the target object to compute the delegated task,
replacing the selected fragment with a method call to the new method. Mean-
while, the corresponding sequence diagram is accordingly updated by adding
a new lifeline representing the target object, and a new message representing
the method call. Through stepwise incremental applying the expert pattern, the
sequence diagrams of use cases are gradually refined into object sequence dia-
288
7.1. Conclusions
grams, and the concept class diagram of the requirements model is accordingly
refined into a design class diagram.
• OO design model to component-based model:Through using the object se-
quence diagram to component sequence diagram transformation, an OO design
model can be automatically transformed into a component-based model for the
purpose of reusability, maintenance, and more importantly, distributed and inde-
pendent deployment. In the transformation, a number of objects selected from
an object sequence diagram is turned into a new component. The interfaces of
the component are identified from the messages of the sequence diagram, and
a component sequence diagram is abstracted from the object sequence diagram
by hiding the messages and lifelines inside the generated component. Mean-
while, a protocol for the new component, which consists of a sequence diagram
and a state machine, is also produced, and component diagrams are modified to
represent the relationships of the components.
Through a finite number of transformation steps with valid selections on the
OO model, the object sequence diagram is entirely transformed to a component
sequence diagram in which the lifelines represent only components. Also, a
complete component diagram is generated. Thus, we obtain a correct refinement
of an OO design model to a component-based architecture model in which each
component of the requirements model becomes a composition of a number of
components.
• Component composition:The transformation realizes the basic rCOS composi-
tion operators, includingrenaminginterface methods,hiding services of a com-
ponent,plugging a provided interface into a required interface, andparallel
compositionof components. The transformation will check the composability
of components, create a new component, update the corresponding component
diagram, and generate protocols for the newly created components.
289
7. Conclusions and Future Work
Particularly, we discussed the design and implementation details of therequire-
ments model to OO design model transformationand theOO design model to component-
based model transformation.
7.2 Limitations of Current Study
However, our approaches and tools are still not perfect. Some of the problems and
limitations are as follows:
Not all features of QVT-R standard are supported. We still cannot support all fea-
tures of QVT-R, especially itscheck-before-enforcesemantics. One reason is the com-
plex requirements covered by the QVT specification, such as incremental transforma-
tions, bidirectional transformations, model synchronization, and many of the features
that are implicit in a declarative language. Because of our limited resources, a full im-
plementation of the QVT-R is certainly an ambitious undertaking. As far as we know,
no existing QVT tool supports all these features.
Another reason is that our approach is based on XSLT techniques by mapping
constructs of QVT-R into constructs of XSLT. One advantage of this approach is to
provide a clear correspondence between a QVT-R transformation and its XSLT im-
plementation, so it is possible to debug the XSLT code, find errors, and easily trace
back to where the errors occurred in the QVT-R specification. But compared to other
approaches such as using a QVT-R interpreter, the ability to support the semantics of
QVT Relations is somehow weaker. Some of the restrictions are listed in the following:
• Relation domains: QVT-R supports multiple domains in a relation, that means,
it can have multiple source and target models. In our approach, we can define
multiple typed models for a transformation, but restrict to one source model and
one target model in a relation;
290
7.2. Limitations of Current Study
• Transformation directions: As one of its key features, QVT-R allows to specify
bidirectional transformations. Transformations can be executed in any direction
by selecting one of the typed models as the target in the running time. In our
approach, the generated XSLT stylesheet is unidirectional, and the source and
target models are decided at the design stage;
• Check-before-enforce semantics and in-place transformation: The semantics
of QVT-R ensures that before creating a new object, it is checked whether an ex-
isting one that satisfies the constraints of the relation can be reused. In this way,
QVT-R supports creating new, and modifying existing, target model elements.
Thus the in-place transformation is implicitly supported by the semantics, and
no additional definition is needed. In our approach, we create all target model
elements in a transformation, and we have to explicitly define an in-place trans-
formation as a set ofchangesto the source model.
• OCL support : In QVT-R, thewhen- andwhere-clauses can contain arbitrary
expressions of extended essential OCL. Our approach supports a subset of OCL.
An OCL expressions is evaluated in the context of a QVT relation, allowing
source domain pattern elements, properties, links and variables to be navigated
and referenced.
Correctness of the QVT-R implementation is not formally proven. Both the QVT
standard and our implementation are extremely complicated. In addition, as many
other OMG standards, the QVT specification fails to provide a precise semantics for
its languages, not even with a reference implementation. All these make the formal
proof another ambitious undertaking. As we focus on the design and implementation
of a practical model transformation approach and tool support, we consider this task
of formal proof beyond the scope of the thesis.
Alternatively, we validate our implementation through testing. We take themedini
291
7. Conclusions and Future Work
QVT as a reference implementation of QVT-R, execute a set of transformations in our
tool and the medini QVT, and compare the trace models and resulting models. The
comparison results show that the basic semantics of QVT-R is correctly supported by
our tool. However, more systematic testing is desirable.
The rCOS profile does not fully support rCOS component model. In rCOS,coor-
dination compositionis defined as parallel composition of processes and components.
The composition operators include not only theconnectorsthat we have already de-
fined in the rCOS profile, but also thecoordinators(coordinating processes), which are
used to coordinate a number of components, and exchange data between them. How-
ever, the support for coordinators is not considered in the current version of the rCOS
profile. It is because we lack the experience of using the coordinators in case studies,
and the definition of coordination composition itself is still improving intermittently.
Moreover, in the rCOS profile, we realize theconnectors(except theplugging) using
only hierarchical assemblythat results in composite components. However, the rCOS
connectors can be also implemented as simple open components that connect to the
original components through thehorizontal assembly.
Generation of proof obligations is not supported. The rCOS development is driven
by applying refinement rules in a stepwise way. This process produces a succession
of models with increasing complexity and details as they approximate the implemen-
tation system. It must be ensured that there exists refinement relationships between
these models, i.e. a more concrete model satisfies its more abstract ancestor. The
use of proof obligations is an effective way to enhance the confidence. As the rCOS
refinement calculus is implemented as model transformations, application of such a
transformation can also generate proof obligations to verify properties of the models.
However, the transformations discussed in the thesis do not include the generation of
the proof obligations. In fact, the problem was explored by our colleagues in [113]
292
7.3. Perspectives for Future Work
using the theorem prover Isabelle/HOL, and has been partially automated in the rCOS
modeler [158].
7.3 Perspectives for Future Work
There is still a long way to fulfill our vision on the design and implementation of the
rCOS tool set out in [111]. A main challenge is still in the automation of the model
transformations of rCOS [97]. We already have a set of transformations for users
to invoke from the menus of the rCOS modeler, and have proposed a development
procedure for using these transformations. But more rCOS model transformations
need to be developed to support the full development process.
For example, we can improve the low level design by using more design patterns
[65], such as theattribute encapsulationand class decomposition (high cohesionand
low coupling). The rCOS refinement calculus also includes a group of simple struc-
tural refinement rules [110], referred as ”small-step” refinements, e.g. adding classes,
attributes, methods, decomposition and composition of classes, promoting methods
from subclasses to super classes, etc. These rules are worth implementing in the rCOS
modeler. In addition, we are going to do more work on transforming the component-
based models into particular platform specific models, such as web applications.
To ensure correctness of these model transformations, we plan to explore the possi-
bility to generate proof obligations from the transformation specifications using higher-
order model transformations. The proof obligations are expressed in the form of OCL
expressions, which can be verified in the framework of rCOS modeler, along with other
OCL constraints defined in the rCOS profile. Future work also includes applying the
rCOS modeler to more middle and large scale case studies, for the purpose of promot-
ing the usefulness and ease of use of the tool, and evaluating its practical applicability
in real software projects.
Of the possible topics for continuing the work on QVTR-XSLT tool, we consider
293
7. Conclusions and Future Work
to migrate the QVT-R graphical editor to an open source UML CASE tool. The cur-
rent editor is built on the top of MagicDraw UML, a commercial CASE tool. Based
on an open source platform, our tool could reach a broader user base. Interestingly,
after boot-strapping our approach, we could now also use the tool to rewrite the code
generator in QVT-R, instead of directly implementing it in XSLT. Moreover, we want
to explore more possible usages of the tool, such as for model conformance checking,
in which, given a source and a target model, a QVT-R relation can also be used to
check if it holds between the two models.
Nowadays, we are still far away from a widespread adoption of model-driven ap-
proaches for general software development, but the paradigm has gradually attracted
the attention of the public and the industry [63]. As methodologies and tools are get-
ting matured, more and more research and development projects will appear in the
field. Hopefully, the ideas and techniques presented in this thesis will stimulate and
help further research in the domain of component-based and model driven develop-
ment. And we will continue working in this direction.
294
References
[1] AndroMDA.org. http://www.andromda.org/.55
[2] Borland Together, Visual Modeling for Software Architecture Design.
http://www.borland.com/us/products/together/index.html.111
[3] Eclipse Model To Model (M2M) project. http://www.eclipse.org/m2m/. 16,
112, 113
[4] SmartQVT - A QVT implementation. http://sourceforge.net/
projects/smartqvt/. 111
[5] The Common Component Modeling Example, volume 5153 ofLNCS. Springer,
2008.258
[6] J. Abrial. The B-book: assigning programs to meanings. Cambridge University
Press, 2005.8
[7] J. Abrial. Modeling in Event-B: system and software engineering. Cambridge
University Press, 2010.8, 12
[8] J. Abrial, M. Butler, S. Hallerstede, T. Hoang, F. Mehta, and L. Voisin. Rodin:
an open toolset for modelling and reasoning in Event-B.International Journal
on Software Tools for Technology Transfer (STTT), 12(6):447–466, 2010.10
[9] S. Agerholm and P. G. Larsen. The IFAD VDM Tools: Lightweight Formal
Methods. InProceedings of Applied Formal Methods - FM-Trends 98, volume
1641 ofLNCS, pages 326–329. Springer, 1999.226
[10] A. Agrawal. Graph rewriting and transformation (GReAT): A solution for the
model integrated computing (MIC) bottleneck. 2003.13, 109
[11] S. Ahumada, L. Apvrille, T. Barros, A. Cansado, E. Madelaine, and
E. Salageanu. Specifying Fractal and GCM Components with UML. InPro-
ceedings of the XXVI International Conference of the Chilean Society of Com-
puter Science, pages 53–62. IEEE, 2007.225
[12] J. Ali and J. Tanaka. Implementing the Dynamic Behavior Represented as Mul-
tiple State Diagrams and Activity Diagrams.Journal of Computer Science and
Information Management (JCSIM), 2(1):22–34, 2001.204
295
REFERENCES
[13] N. Amálio, F. Polack, and S. Stepney.Software Specification Methods, chapter
UML+ Z: Augmenting UML with Z, pages 81–102. Wiley Online Library,
2010.9
[14] C. Amelunxen, A. Konigs, T. Rotschke, and A. Schurr. MOFLON: A standard-
compliant metamodeling framework with graph transformations. InModel
Driven Architecture–Foundations and Applications, pages 361–375. Springer,
2006.13, 56, 109
[15] B. B. Ammar, M. T. Bhiri, and J. Souquières. Incremental development of uml
specifications using operation refinements.ISSE, 4(3):259–266, 2008.13
[16] D. Amyot and A. Eberlein. An evaluation of scenario notations and construction
approaches for telecom-munication systems development. InTelecommunica-
tion Systems, volume 24(1), September 2003.278
[17] K. Anastasakis, B. Bordbar, G. Georg, and I. Ray. Uml2alloy: A challenging
model transformation. InModel Driven Engineering Languages and Systems,
10th International Conference (MoDELS 2007), volume 4735 ofLNCS, pages
436–450. Springer, 2007.225
[18] M. Asadi and R. Ramsin. MDA-based methodologies: an analytical survey.
In Proceedings of the 4th European conference on Model Driven Architec-
ture: Foundations and Applications (ECMDA-FA 08), pages 419–431. Springer,
2008.6
[19] C. Atkinson and T. Kuhne. Model-driven development: a metamodeling foun-
dation. IEEE software, 20(5):36–41, 2003.228
[20] R. Back and J. Wright. Refinement Calculus: A Systematic Introduction.
Springer Verlag, 1998.10, 12
[21] J. Bézivin, F. Búttner, M. Gogolla, F. Jouault, I. Kurtev, and A. Lindow. Model
transformations? Transformation models!Model Driven Engineering Lan-
guages and Systems, pages 440–453, 2006.103, 178
[22] J. Bicarregui, J. Fitzgerald, P. Larsen, and J. Woodcock. Industrial practice
in formal methods: A review. InFM 2009: Formal Methods, Second World
Congress, volume 5850 ofLNCS, pages 810–813. Springer, 2009.8
296
REFERENCES
[23] L. Bichler. A flexible code generator for MOF-based modeling languages.2nd
OOPSLA Workshop on Generative Techniques in the context of Model Driven
Architecture, 2003.117
[24] E. Biermann, K. Ehrig, C. Köhler, G. Kuhns, G. Taentzer, and E. Weiss. EMF
model refactoring based on graph transformation concepts. InProc. Third In-
ternational Workshop on Software Evolution through Transformations (SETra
2006), volume 3. Citeseer.39
[25] D. Birkmeier and S. Overhage. On Component Identification Approaches -
Classification, State of the Art, and Comparison. InCBSE’09, pages 1–18,
2009.7, 279
[26] E. Börger and R. Stärk.Abstract state machines: a method for high-level system
design and analysis. Springer Verlag, 2003.8
[27] J. Bowen. Formal specification and documentation using Z: A case study ap-
proach, volume 66. International Thomson Computer Press, 2003.8
[28] M. Bräuer. Design and Prototypical Implementation of a Pivot Model as Ex-
change Format for Models and Metamodels in a QVT/OCL Development Envi-
ronment. PhD thesis, Technische Universität Dresden, 2008.30
[29] E. Bruneton, T. Coupaye, M. Leclercq, V. Quéma, and J.-B.Stefani. The FRAC-
TAL component model and its support in Java.Software: Practice and Experi-
ence, 36(11-12):1257–1284, 2006.61
[30] Budapest University of Technology and Economics. VMTS Web site.
http://www.aut.bme.hu/Portal/Vmts.aspx.16, 116
[31] M. Bureck. Visual QVT/R, A concrete graphical syntax forQVT/R.
http://www.randomice.net/ les/2009/06/7_bureck_visual_qvtr.pdf., 2009.115
[32] T. Bures, P. Hnetynka, and F. Plasil. SOFA 2.0: BalancingAdvanced Features
in a Hierarchical Component Model. InSERA, pages 40–48. IEEE Computer
Society, 2006.61
[33] S. Burmester, H. Giese, J. Niere, M. Tichy, J. Wadsack, R.Wagner, L. Wende-
hals, and A. Zundorf. Tool integration at the meta-model level: the Fujaba
approach. International Journal on Software Tools for Technology Transfer
(STTT), 6(3):203–218, 2004.13, 56, 109
297
REFERENCES
[34] F. Buttner and M. Gogolla. Realizing UML metamodel transformations with
AGG. Electronic Notes in Theoretical Computer Science, 109:31–42, 2004.13,
56, 109
[35] A. Cavalcanti and D. Naumann. A weakest precondition semantics for refine-
ment of object-oriented programs.IEEE Transactions on Software Engineering,
26(8):713–728, 2000.12
[36] X. Chen, J. He, Z. Liu, and N. Zhan. A Model of Component-Based Program-
ming. In Proc. Fundamentals of Software Engineering (FSEN 2007), volume
4767 ofLNCS, pages 191–206. Springer, 2007.17
[37] X. Chen, Z. Liu, and V. Mencl. Separation of Concerns and Consistent Inte-
gration in Requirements Modelling. InSOFSEM 2007: 33rd Conference on
Current Trends in Theory and Practice of Computer Science, volume 4362 of
LNCS, pages 819–831. Springer, Jan. 2007.281
[38] Z. Chen, A. H. Hannousse, D. V. Hung, I. Knoll, X. Li, Z. Liu, Y. Liu, Q. Nan,
J. C. Okika, A. P. Ravn, V. Stolz, L. Yang, and N. Zhan. Modelling with Rela-
tional Calculus of Object and Component Systems - rCOS. InCoCoME, volume
5153 ofLNCS, pages 116–145. Springer, 2007.i, 69
[39] Z. Chen, Z. Liu, A. P. Ravn, V. Stolz, and N. Zhan. Refinement and verification
in component-based model driven design.Sci. Comput. Program., 74(4):168–
196, Feb. 2009.i, 17, 69, 85, 95, 258, 280
[40] Z. Chen, Z. Liu, and V. Stolz. The rCOS tool. In J. Fitzgerald, P. G. Larsen,
and S. Sahara, editors,Modelling and Analysis in VDM: Proceedings of the
Fourth VDM/Overture Workshop, number CS-TR-1099 in Technical Report Se-
ries. Newcastle University, May 2008.93, 226
[41] Z. Chen, C. Morisset, and V. Stolz. Specification and Validation of Behavioural
Protocols in the rCOS Modeler. In3rd Intl. Symp. on Fundamentals of Software
Engineering (FSEN 2009), volume 5961 ofLNCS, pages 387–401. Springer,
2010.221, 281
[42] J. Chimia-Opoka, M. Felderer, C. Lenz, and C. Lange. Querying UML models
using OCL and Prolog: A performance study. InSoftware Testing Verification
and Validation Workshop, 2008. ICSTW’08. IEEE International Conference on,
pages 81–88. IEEE, 2008.184, 187, 188
298
REFERENCES
[43] F. Chitforoush, M. Yazdandoost, and R. Ramsin. Methodology support for the
model driven architecture. In14th Asia-Pacific Software Engineering Confer-
ence (APSEC 2007)., pages 454–461. IEEE, 2007.6
[44] M. Choi and E. Cho. Component Identification Methods Applying Method Call
Types between Classes.J. Inf. Sci. Eng, 22:247–267, 2006.7, 280
[45] K. Czarnecki and S. Helsen. Feature-based survey of model transformation
approaches.IBM Systems Journal, 45(3):621–646, 2006.2, 13, 55
[46] D. Dang. On Integrating Triple Graph Grammars and OCL for Model-Driven
Development. PhD thesis, Staats-und Universitätsbibliothek Bremen, 2009.i,
31
[47] J. Davies.The Scientific Approach, second edition. New York:Academic Press,
1973.21
[48] G. de Caso, V. A. Braberman, D. Garbervetsky, and S. Uchitel. Automated Ab-
stractions for Contract Validation.IEEE Transactions on Software Engineering,
38(1):141–162, 2012.279
[49] R. De Giorgis and M. Joui. Towards a UML Profile for Modeling WAP Appli-
cations.Journal of Computer Science and Technology, 5(4), 2005.49
[50] J. de Lara and E. Guerra. Formal Support for QVT-Relations with Coloured
Petri Nets. InMoDELS, volume 5795 ofLNCS, pages 256–270. Springer, 2009.
102
[51] J. de Lara and H. Vangheluwe. AToM3: A Tool for Multi-formalism and Meta-
modelling. InFundamental Approaches to Software Engineering, 5th Interna-
tional Conference, FASE 2002, volume 2306 ofLNCS, pages 174–188. Springer,
2002.13, 56, 109
[52] E. Dijkstra. A constructive approach to the problem of program correctness.
BIT Numerical Mathematics, 8(3):174–186, 1968.11
[53] S. Dupuy, Y. Ledru, and M. Chabre-Peccoud. An Overview ofRoZ: A Tool for
Integrating UML and Z Specifications. InProceedings in Advanced Informa-
tion Systems Engineering, 12th International Conference (CAiSE 2000), volume
1789 ofLNCS, pages 417–430. Springer, 2000.225
299
REFERENCES
[54] Eclipse Foundation. Eclipse Modelling Framework.
http://www.eclipse.org/modeling/emf/.38
[55] K. Ehrig, C. Ermel, and S. Hansgen. Towards Model Transformation in Gener-
ated Eclipse Editor Plug-Ins.Electronic Notes in Theoretical Computer Science,
152:39–52, 2006.16, 115
[56] M. Elkoutbi, I. Khriss, and R. Keller. Automated Prototyping of User Interfaces
Based on UML Scenarios.Automated Software Engineering, 13(1):5–40, 2006.
279
[57] G. Engels, M. Lohmann, S. Sauer, and R. Heckel. Model-Driven Monitoring:
An Application of Graph Transformation for Design by Contract. InProc. Third
Intl. Conf. on Graph Transformations, volume 4178 ofLNCS, pages 336–350.
Springer, 2006.31
[58] A. Etien, C. Dumoulin, and E. Renaux. Towards a unified notation to represent
model transformation. Research Report RR-6187, INRIA, 2007.16, 115
[59] M. Fan-Chao, Z. Den-Chen, and X. Xiao-Fei. Business Component Identifi-
cation of Enterprise Information System: A Hierarchical Clustering Method.
Proc. of the 2005 IEEE Intl. Conf. on e-Business Engineering, 2005. 7, 279,
280
[60] H. Fecher, J. Schönborn, M. Kyas, and W. P. de Roever. 29 New Unclarities in
the Semantics of UML 2.0 State Machines. InICFEM 2005, 7th International
Conference on Formal Engineering Methods, volume 3785 ofLNCS, pages 52–
65. Springer, 2005.40
[61] M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts.Refactoring: Im-
proving the Design of Existing Code. Addison-Wesley, 1999.18
[62] R. France, S. Ghosh, T. Dinh-Trong, and A. Solberg. Model-driven development
using UML 2.0: promises and pitfalls.Computer, 39(2):59–66, 2006.5
[63] R. France and B. Rumpe. Model-driven development of complex software: A
research roadmap. InInternational Conference on Software Engineering, pages
37–54. IEEE Computer Society Washington, DC, USA, 2007.1, 30, 53, 294
[64] L. Fuentes-Fernández and A. Vallecillo-Moreno. An introduction to UML pro-
files. UML and Model Engineering, UPGRADE, Vol.V, No. 2:6–13, 2004.193,
225
300
REFERENCES
[65] E. Gamma, R. Helm, R. Johnson, and J. Vlissides.Design Patterns: Elements
of Reusable Object-Oriented Software. Addison-Wesley, 1995.18, 293
[66] P. Gancarski and A. Butterfield. Connecting UML and VDM++with Open Tool
Support. InFM 2009: Formal Methods, Second World Congress, volume 5850
of LNCS, pages 563–578. Springer, 2009.9
[67] P. Gancarski and A. Butterfield. The denotational semantics of slotted-circus.
In FM 2009: Formal Methods, Second World Congress, volume 5850 ofLNCS,
pages 451–466. Springer, 2009.70
[68] A. Gargantini, E. Riccobene, and P. Scandurra. Combining Formal Methods and
MDE Techniques for Model-Driven System Design and Analysis.International
Journal On Advances in Software, 3(1 and 2):1–18, 2010.225
[69] J. Gibbons. Unifying Theories of Programming with Monads. In 4th Inter-
national Symposium on Unifying Theories of Programming (UTP 2012), Paris,
Proceedings, 2012.70
[70] B. Graaf and A. van Deursen. Model-driven Consistency Checking of Be-
havioural Specifications. InModel-Based Methodologies for Pervasive and Em-
bedded Software, 2007. MOMPES’07. Fourth International Workshop on, pages
115–126. IEEE, 2007.278
[71] J. Greenyer and E. Kindler. Reconciling TGGs with QVT. InModel Driven
Engineering Languages and Systems, 10th International Conference ( MoDELS
2007), volume 4735 ofLNCS, pages 16–30. Springer, 2007.145
[72] R. Grønmo and B. Møller-Pedersen. From UML 2 Sequence Diagrams to State
Machines by Graph Transformation.Journal of Object Technology, 10, 2011.
278
[73] R. Grønmo and J. Oldevik. An empirical study of the UML model transfor-
mation tool (UMT). Proc. First Interoperability of Enterprise Software and
Applications, Geneva, Switzerland, 2005.117
[74] H. Gross.Component-Based Software Testing with UML. Springer-Verlag New
York Inc, 2005.i, 31
[75] O. M. Group. UML 2.0 Diagram Interchange Specification, September 2003.
171, 215
301
REFERENCES
[76] O. M. Group. Unified Modeling Language: Infrastructure, version 2.4.1, August
2011.39
[77] E. Guerra and J. De Lara. Model view management with triple graph transfor-
mation systems.Graph Transformations, pages 351–366, 2006.14, 110
[78] B. Hailpern and P. Tarr. Model-driven development: The good, the bad, and the
ugly. IBM Systems Journal, 45(3):451–461, 2006.2, 3
[79] D. Harel, H. Kugler, and A. Pnueli. Synthesis revisited:Generating statechart
models from scenario-based requirements.Formal Methods in Software and
Systems Modeling, pages 309–324, 2005.278
[80] D. Harel and R. Marelly. Come, Let’s Play: Scenario-Based Programming
Using LSC’s and the Play-Engine. Springer-Verlag, 2003.280
[81] D. Harel and I. Segall. Synthesis from Scenario-based Specifications.Journal
of Computer and System Sciences, 78(3):970–980, 2012.278
[82] J. He, X. Li, and Z. Liu. rCOS: A refinement calculus of object systems.Theor.
Comput. Sci., 365(1-2):109–142, 2006.i, 17, 18, 69, 82, 92, 97, 223
[83] W. Heaven and A. Finkelstein. UML profile to support requirements engineering
with KAOS. IEE Proceedings-Software, 151(1):10, 2004.224
[84] G. Heineman and W. Councill.Component-based software engineering: putting
the pieces together, volume 17. Addison-Wesley USA, 2001.1
[85] C. Hoare. Communicating sequential processes, Prentice-Hall international
series in computer science. Prentice/Hall International, 1985.8, 97
[86] C. Hoare and J. He.Unifying theories of programming. Prentice-Hall Interna-
tional, 1998.17, 70, 72, 74
[87] P. Höfner and G. Struth. Can refinement be automated?Electronic Notes in
Theoretical Computer Science, 201:197–222, 2008.13
[88] A. Idani, J.-L. Boulanger, and L. Philippe. A generic process and its tool support
towards combining uml and b for safety critical systems. InProceedings of the
ISCA 20th International Conference on Computer Applications in Industry and
Engineering (CAINE 2007), pages 185–192. ISCA, 2007.225
302
REFERENCES
[89] A. Iliasov, E. Troubitsyna, L. Laibinis, and A. Romanovsky. Patterns for re-
finement automation. InFormal Methods for Components and Objects - 8th
International Symposium (FMCO 2009), volume 6286 ofLNCS, pages 70–88.
Springer, 2010.10, 12
[90] I. J. James Rumbaugh and G. Booch.The Unified Modeling Language Reference
Manual Second Edition. Addison-Wesley, July 2004.39
[91] W. Janssen, A. Korlyukov, and J. Van den Bussche. On the tree-transformation
power of XSLT.Acta Informatica, 43(6):371–393, 2007.116, 122
[92] C. Jones. Systematic Software Development using VDM. Prentice Hall, 2nd
edition, 1990.8
[93] F. Jouault, F. Allilaire, J. Bézivin, and I. Kurtev. ATL:A model transformation
tool. Science of Computer Programming, 72(1-2):31–39, 2008.14, 111
[94] F. Jouault and I. Kurtev. On the Architectural Alignmentof ATL and QVT. In
Proceedings of the 2006 ACM symposium on Applied computing, pages 1188–
1195. ACM, 2006.112
[95] M. Kay. XPath 2.0 programmer’s reference. Wrox Press, 2004.129
[96] M. Kay. XSLT 2.0 Programmer’s Reference, Third Edition. Wrox Press, 2004.
104, 125, 126
[97] W. Ke, X. Li, Z. Liu, and V. Stolz. rCOS: a formal model-driven engineering
method for component-based software.Frontiers of Computer Science in China,
6(1):17–39, 2012.i, 17, 18, 69, 102, 198, 217, 293
[98] A. Königs and A. Schürr. Multi-Domain Integration with MOF and extended
Triple Graph Grammars.Language Engineering for Model-Driven Software
Development, 4101, 2004.14, 110
[99] A. Königs and A. Schürr. Tool Integration with Triple Graph Grammars-A
Survey. Electronic Notes in Theoretical Computer Science, 148(1):113–150,
2006.14, 110
[100] P. Kruchten.The Rational Unified Process—An Introduction. Addison-Wesly,
2000.6
303
REFERENCES
[101] I. Kurtev. State of the Art of QVT: A Model Transformation Language Standard.
In Applications of Graph Transformations with Industrial Relevance, Third In-
ternational Symposium ( AGTIVE 2007), volume 5088 ofLNCS, pages 377–393.
Springer, 2007.15, 102
[102] F. Lagarde, H. Espinoza, F. Terrier, and S. Gérard. Improving UML Pro-
file Design Practices by Leveraging Conceptual Domain Models. In22nd
IEEE/ACM International Conference on Automated Software Engineering (ASE
2007), pages 445–448, 2007.49, 225
[103] C. Larman.Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design and the Unified Process. Prentice-Hall, 3rd edition, 2005.
18, 34, 40, 94, 95, 258
[104] G. Leavens, J. Abrial, D. Batory, M. Butler, A. Coglio, K. Fisler, E. Hehner,
C. Jones, D. Miller, S. Peyton-Jones, et al. Roadmap for enhanced languages
and methods to aid verification. InProceedings of the 5th international confer-
ence on Generative programming and component engineering, pages 221–236.
ACM, 2006.10
[105] S. Lee, Y. Yang, F. Cho, S. Kim, and S. Rhew. COMO: A UML-based com-
ponent development methodology. In6th Asia Pacific Softw. Eng. Conf., pages
54–61. IEEE, 1999.280
[106] D. Li, X. Li, J. Liu, and Z. Liu. Validation of requirement models by automatic
prototyping. Innovations in Systems and Software Engineering, 4(3):241–248,
2008.96
[107] D. Li, X. Li, Z. Liu, and V. Stolz. Interactive Transformations from Object-
Oriented Models to Component-Based Models. InProc. of Formal Aspects
of Component Software (FACS’11), volume 7253 ofLNCS, pages 97–114.
Springer, 2012.17, 224
[108] H. Liang, J. Dingel, and Z. Diskin. A Comparative Surveyof Scenario-based
to State-based Model Synthesis Approaches. InProceedings of the 2006 inter-
national workshop on Scenarios and state machines: models, algorithms, and
tools, pages 5–12. ACM, 2006.278
[109] S. Liu. Formal engineering for industrial software development: using the
SOFL method. Springer, 2004.8, 226
304
REFERENCES
[110] X. Liu, Z. Liu, and L. Zhao. Object-oriented structure refinement - a graph
transformational approach.Electr. Notes Theor. Comput. Sci., 187:145–159,
2007. UNU-IIST TR 340.293
[111] Z. Liu, V. Mencl, A. P. Ravn, and L. Yang. Harnessing Theories for Tool Sup-
port. In Proc. of the Second Intl. Symp. on Leveraging Applications of Formal
Methods, Verification and Validation (isola 2006), pages 371–382. IEEE Com-
puter Society, Aug. 2006. Full version as UNU-IIST Technical Report 343.18,
92, 280, 293
[112] Z. Liu, C. Morisset, and V. Stolz. rCOS: Theory and Tool for Component-Based
Model Driven Development. In3rd Intl. Symp. on Fundamentals of Software
Engineering (FSEN 2009), volume 5961 ofLNCS, pages 62–80. Springer, 2010.
i, 3, 17, 18, 69
[113] Z. Liu, C. Morisset, and S. Wang. A Graph-Based Implementation for Mecha-
nized Refinement Calculus of OO Programs. InSBMF, volume 6527 ofLNCS,
pages 258–273. Springer, 2010.281, 292
[114] Q. Long, Z. Qiu, and Z. Liu. Formal use of design patternsand refactoring. In
T. Margaria and B. Steffen, editors,International Symposium on Leveraging Ap-
plications of Formal Methods, Verification and Validation, volume 17 ofCom-
munications in Computer and Information Science, pages 323–338. Springer,
Nov. 2008.17, 18
[115] F. Lucas, F. Molina, and A. Toval. A systematic review ofUML model consis-
tency management.Information and Software technology, 51(12):1631–1645,
2009.58
[116] S. Markovic and T. Baar. Refactoring OCL annotated UML class diagrams.
Software and System Modeling, 7(1):25–47, 2008.58
[117] medini QVT, ikv++ Technologies,http://projects.ikv.de/qvt. 15,
113, 178
[118] S. Meliá, J. Gómez, and J. Serrano. UPT: A Graphical Transformation Lan-
guage based on a UML Profile1. InProceedings of European Workshop on
Milestones, Models and Mappings for Model-Driven Architecture (3M4MDA),
Bilbao, Spain, 2006.16, 102, 115
305
REFERENCES
[119] S. Mellor, A. Clark, and T. Futagami. Model-driven development.IEEE soft-
ware, 20(5):14–18, 2003.30
[120] T. Mens and P. Van Gorp. A Taxonomy of Model Transformation. Electronic
Notes in Theoretical Computer Science, 152:125–142, 2006.2, 13, 55, 56
[121] J. Miller, J. Mukerji, et al. MDA Guide Version 1.0. 1.Object Management
Group, 234, 2003.31, 32, 33
[122] ModelMorf, A Model Transformer,http://www.tcs-trddc.com/. 15,
101
[123] M. Möller, E.-R. Olderog, H. Rasch, and H. Wehrheim. Integrating a formal
method into a software engineering process with UML and Java.Formal Aspects
of Computing, 20(2):161–204, Mar. 2008.9, 225
[124] C. Morgan.Programming from specifications. Prentice-Hall, Inc., 1990.11
[125] J. Morris. A theoretical basis for stepwise refinement and the programming
calculus.Science of Computer Programming, 9(3):287–306, 1987.10, 11
[126] No Magic Inc. MagicDraw UML User’s Manual. http://www.magicdraw.com/,
2010.39, 173
[127] J. Nunamaker Jr and M. Chen. Systems Development in Information Systems
Research. InProceedings of the Twenty-Third Annual Hawaii International
Conference on System Sciences, volume 3, pages 631–640. IEEE, 1990.x, 22
[128] Object Management Group. Systems Modeling Language SysML V1.0. 224
[129] Object Management Group. UML Profile for MARTE: Modeling and Analysis
of Real-Time Embedded systems, Beta 2.224
[130] Object Management Group. Request for Proposal: MOF 2.0Query/Views/-
Transformations RFP, October 2003.57, 153
[131] Object Management Group. UML 2.0 OCL Specification, October 2003.4, 51,
52, 53, 130, 135
[132] Object Management Group. Meta Object Facility (MOF) Core Specification.
http://www.omg.org/spec/MOF/2.0/PDF, Jan. 2006.4, 35, 159
[133] Object Management Group. MOF 2.0/XMI Mapping, v2.1.1.
http://www.omg.org/spec/XMI/2.1.1/PDF, 2007.4, 38, 104
306
REFERENCES
[134] Object Management Group. Meta Object Facility (MOF) 2.0 Query/View/-
Transformation Specification, Version 1.1, January 2011.i, x, 2, 4, 31, 56,
57, 58, 102, 103, 117, 118, 120, 121, 142, 155, 159, 175, 178
[135] Object Management Group. Unified Modeling Language: Superstructure, ver-
sion 2.4.1, August 2011.i, 4, 31, 39, 49, 62, 199, 204, 212, 213
[136] Object Management Group. Model Driven Architecture (MDA) FAQ.
http://www.omg.org/spec/mda/faq_mda.htm, Jan. 2012.6
[137] Oliver Alt. Model transformation with the QVT Relations language - Fallstudie
einer werkzeug spezifischen Realisierung. In W.-G. Bleek, H. Schwentner, and
H. Züllighoven, editors,Software Engineering (Workshops), volume 106 ofLNI,
pages 255–260. GI, 2007.116
[138] R. Paige and J. Ostroff. ERC–An object-oriented refinement calculus for Eiffel.
Formal Aspects of Computing, 16(1):51–79, 2004.12
[139] D. Parnas. Really Rethinking "’Formal Methods".Computer, 43(1):28–34,
2010.10
[140] M. Peltier, J. Bézivin, and G. Guillaume. MTRANS: A general framework,
based on XSLT, for model transformations. InWorkshop on Transformations in
UML (WTUML), Genova, Italy, April, 2001.117
[141] C. Pons. Heuristics on the Definition of UML Refinement Patterns. InTheory
and Practice of Computer Science, 32nd Conference on Current Trends in The-
ory and Practice of Computer Science (SOFSEM 2006), volume 3831 ofLNCS,
pages 461–470. Springer, 2006.13
[142] J. Poole. Model-driven architecture: Vision, standards and emerging technolo-
gies. InWorkshop on Metamodeling and Adaptive Object Models, ECOOP.
Citeseer, 2001.4
[143] I. Porres and I. Rauf. Generating Class Contracts from UML Protocol Statema-
chines. InProceedings of the 6th International Workshop on Model-Driven
Engineering, Verification and Validation, Denver, CO, USA, 2009. ACM.279
[144] W. Reisig and G. Rozenberg.Lectures on Petri Nets: Basic Models. Number
1491. Springer, 1998.8
307
REFERENCES
[145] M. Said, M. Butler, and C. Snook. Language and tool support for class and state
machine refinement in UML-B. InFM 2009: Formal Methods, Second World
Congress, volume 5850 ofLNCS, pages 579–595. Springer, 2009.12
[146] W. Schamai, P. Fritzson, C. Paredis, and A. Pop. TowardsUnified System Mod-
eling and Simulation with ModelicaML. InProc. 7th Intl. Modelica Conference,
2009.224
[147] D. Schmidt. Model-driven engineering.IEEE computer, 39(2):25–31, 2006.2
[148] D. Schreiner. Component Based Communication Middleware for AUTOSAR.
PhD thesis, Vienna Univ. of Technol., Vienna, Austria, 2009.i, 31, 34
[149] A. Schurr. Specification of graph translators with triple graph grammars.
In Graph-Theoretic Concepts in Computer Science, pages 151–163. Springer,
1995.13, 56
[150] B. Selic. The pragmatics of model-driven development.IEEE software,
20(5):19–25, 2003.30
[151] B. Selic. A Systematic Approach to Domain-Specific Language Design Us-
ing UML. In Proc. Tenth IEEE Intl. Symp. on Object-Oriented Real-Time Dis-
tributed Computing (ISORC 2007), pages 2–9. IEEE, 2007.49, 225
[152] S. Sendall and W. Kozaczynski. Model transformation: The heart and soul of
model-driven software development.Software, IEEE, 20(5):42–45, 2003.2
[153] G. Shahmohammadi, S. Jalili, and S. M. H. Hasheminejad.Identification of
System Software Components Using Clustering Approach.Journal of Object
Technology, 9(6):77–98, 2010.7, 279, 280
[154] C. Snook and M. Butler. UML-B: Formal modeling and design aided by
UML. ACM Transactions on Software Engineering and Methodology (TOSEM),
15(1):92–122, 2006.10, 12
[155] Sparx Systems Pty Ltd. Enterprise Architect, A Visual Modeling Platform.
http://www.sparxsystems.com/, 2010.115
[156] C. Sprenger and D. Basin. Developing security protocols by refinement. In
Proceedings of the 17th ACM conference on Computer and communications
security, pages 361–374. ACM, 2010.10
308
REFERENCES
[157] D. Stein, S. Hanenberg, and R. Unland. A Graphical Notation to Specify Model
Queries for MDA Transformations on UML Models. InModel Driven Architec-
ture, European MDA Workshops: Foundations and Applications ( MDAFA 2003
and 2004), volume 3599 ofLNCS, pages 77–92. Springer, 2004.52, 158
[158] V. Stolz. An integrated multi-view model evolution framework. Innovations in
Systems and Software Engineering, 6(1–2):13–20, 2010.281, 293
[159] H. Störrle. A Logical Model Query Interface.In Proceedings of the VLL
2009 workshop on Visual Languages and Logic, Dalhousie, Canada, Septem-
ber, pages 18–36, 2009.184
[160] C. Szyperski, D. Gruntz, and S. Murer.Component software: beyond object-
oriented programming. Addison-Wesley Professional, 2002.1, 99
[161] G. Taentzer, K. Ehrig, E. Guerra, J. De Lara, L. Lengyel,T. Levendovszky,
U. Prange, D. Varro, and S. Varro-Gyapay. Model transformation by graph
transformation: A comparative study. InProc. Workshop Model Transformation
in Practice, Montego Bay, Jamaica. Citeseer, 2005.109, 110
[162] Tata Consultancy Services. Modelmorf. http://www.tcs-
trddc.com/ModelMorf/ModelMorf.htm.114
[163] M. Tisi, F. Jouault, P. Fraternali, S. Ceri, and J. Bézivin. On the use of higher-
order model transformations. InModel Driven Architecture-Foundations and
Applications, pages 18–33. Springer, 2009.149, 150
[164] D. Varró and A. Balogh. The model transformation language of the VIATRA2
framework.Science of Computer Programming, 68(3):214–234, 2007.109
[165] F. Vernadat, C. Percebois, P. Farail, R. Vingerhoeds, A. Rossignol, J. Talpin,
and D. Chemouil. The Topcased project-a toolkit in open-source for critical ap-
plication and system development. InInternational Space System Engineering
Conference-Data Systems in Aerospace. Eurospace, 2006. 39, 101, 171, 214,
218
[166] VMTS tutorials. The QVT Plug-in of the Visual Modeling and Transformation
System - Realizing QVT with Visual Modeling and Transformation System.
http://avalon.aut.bme.hu/ tihamer/.16
309
REFERENCES
[167] Z. Wang, X. Xu, and D. Zhan. A survey of business component identification
methods and related techniques.International Journal of Information Technol-
ogy, 2(4):229–238, 2005.7, 279, 280
[168] J. Warmer and A. Kleppe.The Object Constraint Language: Getting Your Mod-
els Ready for MDA,Second Edition. Addison-Wesley Professional, 2003.51
[169] J. Whittle and P. Jayaraman. Generating Hierarchical State Machines from Use
Case Charts. InRequirements Engineering, 14th IEEE International Confer-
ence, pages 19–28. IEEE, 2006.277
[170] J. Whittle and P. Jayaraman. Synthesizing hierarchical state machines from
expressive scenario descriptions.ACM Transactions on Software Engineering
and Methodology (TOSEM), 19(3):8, 2010.278
[171] I. Wikimedia Foundation. Wikipedia, the free encyclopedia.
http://en.wikipedia.org/. http://en.wikipedia.org/.32
[172] Wikipedia. Model/view/controller. http://en.wikipedia.org/wiki/Model202
[173] E. Willink. On Challenges for a Graphical Transformation Notation and the
UMLX Approach.Electronic Notes in Theoretical Computer Science, 211:171–
179, 2008.16, 112, 115, 117, 191
[174] N. Wirth. Program development by stepwise refinement.Communications of
the ACM, 14(4):221–227, 1971.11
[175] J. Woodcock, P. Larsen, J. Bicarregui, and J. Fitzgerald. Formal methods: Prac-
tice and experience.ACM Computing Surveys (CSUR), 41(4):19, 2009.8, 13
[176] WWW Consortium. XML Schema, W3C Recommendation.
http://www.w3.org/XML/Schema.105
[177] WWW Consortium. XML Path Language (XPath) 2.0, W3C Recommendation.
http://www.w3.org/TR/2007/REC-xpath20-20070123/, January 2007.122
[178] WWW Consortium. XSL Transformations (XSLT) Version 2.0, W3C Recom-
mendation, January 2007.20, 104, 125
[179] L. Yang, V. Mencl, V. Stolz, and Z. Liu. Automating Correctness Preserving
Model-to-Model Transformation in MDA. Number 348, pages 85–101, 2006.
101
310
REFERENCES
[180] L. Yang and V. Stolz. Integrating refinement into software development tools. In
G. Pu and V. Stolz, editors,1st Intl. Workshop on Harnessing Theories for Tool
Support in Software, volume 207 ofElectr. Notes in Theor. Comp. Sci., pages
69–88. Elsevier, Apr. 2008. UNU-IIST TR 385.101, 280
[181] L. Zhao, X. Liu, Z. Liu, and Z. Qiu. Graph transformations for object-oriented
refinement.Formal Aspects of Computing, 21(1–2):103–131, Feb. 2009.i, 17,
18, 69, 82, 97, 98
[182] T. Ziadi, L. Helouet, and J. Jezequel. Revisiting Statechart Synthesis with an
Algebraic Approach. InProceedings of the 26th International Conference on
Software Engineering, pages 242–251, Los Alamitos, CA, USA, 2004. IEEE
Computer Society.278
[183] P. Zwickl. Graphical Debugging of QVT Relations using Transformation Nets.
GRIN Verlag, 2010.114
311
Appendix A
EBNF for OCL used in QVTR-XSLT
tool
A.1 Basic definitions〈LName〉 ::= ( ‘a’ .. ‘ z’ ) ( ‘ a’ .. ‘ z’ | ‘A’ .. ‘ Z’ | ‘−’ | ‘ :’ | ‘_’ | ‘0’ .. ‘9’ )∗;
〈CName〉 ::= (‘A’ .. ‘ Z’) ( ‘ a’ .. ‘ z’ | ‘A’ .. ‘ Z’ | ‘_’ | ‘0’ .. ‘ 9’ )∗ ;
〈VarName〉 ::= 〈LName〉 ;
〈Variable〉 ::= 〈LName〉 ;
〈RelationName〉 ::= 〈CName〉 ;
〈QueryName〉 ::= 〈CName〉 ;
〈AssoEndName〉 ::= 〈LName〉 ;
〈AssoName〉 ::= 〈LName〉 ;
〈ClassName〉 ::= 〈CName〉 ;
〈AttributeName〉 ::= 〈LName〉 ;
〈Literal〉 ::= ( ‘ ’ ’ 〈String〉 ‘ ’ ’ ) | 〈Number〉 | ‘ true’ | ‘ false’ | ‘null ’;
〈ArithmeticOp〉 ::= ‘+’ | ‘ − ’ | ‘∗’ | ‘ / ’ ;
〈LogicalOp〉 ::= ‘>’ | ‘>=’ | ‘<’ | ‘<=’ | ‘=’ | ‘and’ | ‘or’ | ‘<>’ | ‘ ! =’;
〈OperationName〉 ::= ‘size’ | ‘ isEmpty’ | ‘notEmpty’ | ‘oclIsUndefined’ | ‘oclIsTypeOf’| ‘first’ | ‘at’ | ‘ last’ | ‘asSet’ | ‘asOrderedSet’ | ‘ indexOf’| ‘union’ | ‘ includes’ | ‘excludes’ | ‘ including’ | ‘excluding’ ;
〈LoopOpName〉 ::= ‘any’ | ‘select’ | ‘exists’ | ‘one’ | ‘ forAll ’ | ‘collect’ | ‘ iterate’;
〈FunctionName〉 ::= 〈LName〉| ‘compare’ | ‘contains’ | ‘count’ | ‘empty’ | ‘upper-case’| ‘ lower-case’ | ‘max’ | ‘min’ | ‘not’ | ‘number’ | ‘exists’ | ‘string ’| ‘substring’ | ‘ rest’ | ‘starts-with ’ | ‘string-join ’ | ‘string-length ’| ‘substring-after ’ | ‘substring-before’;
312
A.2 Expression definitions
〈OCLExpression〉 ::= 〈WhenExp〉 | 〈WhereExp〉;
〈WhenExp〉 ::= ( 〈Predicate〉 )∗;
〈WhereExp〉 ::= ( 〈VariableDef〉 | 〈RelationInvocation〉 )∗;
〈Predicate〉 ::= ( 〈OCLExp〉 | 〈IfExp〉 ) ‘ ;’;
〈VariableDef〉 ::= 〈VarName〉 ‘=’ 〈Expression〉 ‘ ;’;
〈RelationInvocation〉 ::= ( 〈RelationCall〉 | 〈IFRelationCall〉 ) ‘ ;’ ;
〈IFRelationCall〉 ::= ‘ if ’ 〈OCLExp〉 ‘ then’ 〈RelationCall〉 ‘endif’;
〈RelationCall〉 ::= 〈RelationName〉 ‘ (’ 〈Variable〉 ‘ ,’ 〈Variable〉 [ ‘ ,’ 〈Arguments〉 ] ‘ )’;
〈Expression〉 ::= 〈IfExp〉 | 〈TupleExp〉 | 〈OCLExp〉| ( 〈ClassName〉 ‘ :: ’ ‘ allInstances()’ [ ‘ ->’ 〈OCLExp〉 ] ) ;
〈IfExp〉 ::= ‘ if ’ 〈OCLExp〉 ‘ then’ 〈OCLExp〉 ‘else’ 〈OCLExp〉 ‘endif’ ;
〈TupleExp〉 ::= ‘Tuple’ ‘ {’ 〈Arguments〉 ‘ }’ ;
〈OCLExp〉 ::= 〈Variable〉 | 〈Literal〉 | 〈OperationCall〉 | 〈NavigationCall〉| 〈AttributeCall〉 | 〈LoopExp〉 | ( ‘ (’ 〈OCLExp〉 ‘ )’ ) ;
〈NavigationCall〉 ::= 〈OCLExp〉 ‘ .’ ( 〈AssoEndName〉 | 〈AssoName〉 | 〈ClassName〉 );
〈AttributeCall〉 ::= 〈OCLExp〉 ‘ .’ 〈AttributeName〉;
〈OperationCall〉 ::= ( 〈OCLExp〉 ( ‘ .’ | ‘ ->’ ) 〈OperationName〉 ‘ (’ [ 〈Arguments〉 ] ‘ )’ )| 〈FunctionCall〉 | 〈QueryCall〉| ( 〈OCLExp〉 〈ArithmeticOp〉 〈OCLExp〉 )| ( 〈OCLExp〉 〈LogicalOp〉 〈OCLExp〉 ) | ( ‘not’ 〈OCLExp〉 ) ;
〈Arguments〉 ::= ( 〈Variable〉 | 〈Literal〉 | 〈Variable〉 ‘ :: ’ 〈VarName〉 )[ ‘ ,’ 〈Arguments〉 ];
〈LoopExp〉 ::= 〈OCLExp〉 ‘ ->’ 〈LoopOpName〉 ‘ (’ [ 〈VarName〉 ‘ |’ ] 〈OCLExp〉 ‘ )’;
〈FunctionCall〉 ::= 〈FunctionName〉 ‘ (’ [ 〈Arguments〉 ] ‘ )’;
〈QueryCall〉 ::= 〈QueryName〉 ‘ (’ [ 〈Arguments〉 ] ‘ )’;
313
Appendix B
Algorithms for OO- to component
sequence diagram transformation
All algorithms here are expressed in a simple pseudocode with OCL-like navigation in
the context of the rCOS metamodel. For example, ifm is an object of typeMessage, as
shown in Fig.5.11, the expressionm.receiveEvent .event .operation gets the operation
invoked messagem.
B.1 Calculate strongly connected lifelines
Algorithm 1 defines a functionGetReachableLifelines which returns a set of lifelines,
to each of them there is path of messages from the controller objectℓc.
Algorithm 1 GetReachableLifelinesInput: ℓc, IntraM
Output: L : {Lifeline}
1: L := ∅;2: for all m(ℓi ,ℓj ) ∈ IntraM do3: if ℓc = ℓi then4: L := L ∪ {ℓj } ∪ GetReachableLifelines(ℓj , IntraM );5: end if6: end for7: return L;
B.2 Generate component from selected object lifelines
Algorithm 2 describes the creation of a component with its provided and required
interface, and the composition of the resulting component with other entities in the
model, whereLs = D .lines − {ℓc} is a selection of lifelines except the controller ob-
ject. We first create a new componentcom with a new contract interfaceconif (lines
1–2). Then an empty setLcomr is initialized to collect the existing component lifelines
which send messages to the new component (line 3).
For each messagem(ℓi ,ℓj ) received by the selected lifelines, we create a design
operationdop with a signature that is copied from the calling operation ofm(ℓi ,ℓj ), and
adddop to the contract interfaceconif (lines 4–8). We turn each selected lifeline inLs
314
B.2. Generate component from selected object lifelines
Algorithm 2 LifelineToComInput: ℓc,Ls,OutM , InM
Output: com : ServiceComponent
1: com := ServiceComponent .new(); com.name := ”COM _” + ℓc.name;2: conif := ContractInterface.new(); conif.name = ”ConInter_” + ℓc.name;3: Lcomr := ∅;4: for all m(ℓi ,ℓj ) ∈ InM do5: op : Operation := m(ℓi ,ℓj ).receiveEvent .event .operation ;6: dop := DesignOperation.new(); dop.name := op.name;
7: copyall op.Ownedparameter to dop.Ownedparameter ;8: add dop to conif ;9: if ℓi.represents.type = Component then
10: Lcomr := Lcomr ∪ {ℓi};11: end if12: end for13: for all ℓ ∈ Ls do14: fld := Field .new(); fld .name := ℓ.name; fld .type = ℓ.represents.type ;15: add fld to conif ;16: end for17: intr := InterfaceRealization.new(); intr .client := com;18: intr .contract := conif ; intr .supplier := conif ;19: add intr to com;20: for all ℓ ∈ Lcomr do21: orif : ContractInterface := ℓ.represents.type.required ;22: cpos := Composition.new();23: cpos.client := orif ; cpos.supplier := conif ;24: end for25: if OutM 6= ∅ then26: com := GenRequiredInterface(ℓc ,OutM , com);27: end if28: return com;
into a property (field) which has the same name and type as the represented class of
the lifeline (lines 13–16). Then an interface realizationintr is created and itsclient,
supplierandcontractare set, andconif becomes the provided interface of component
com (lines 17–19).
For each component lifelineℓ in Lcomr which have already been collected in lines
9–11, we connect the required interfaceorif of the component represented byℓ to conif
using an rCOScomposition(lines 20–24). Finally, if there are messages inOutM , we
construct a required interface for componentcom using algorithmGenRequiredInter-
face(lines 25–27).
315
B. Algorithms for OO- to component sequence diagram transformation
B.3 Generate required interface
Algorithm 3 GenRequiredInterfaceInput: ℓc,OutM , com
Output: com : ServiceComponent
1: rif := ContractInterface.new(); rif.name = ”RInter_” + ℓc.name;2: Lcomp := ∅;3: for all m(ℓi ,ℓj ) ∈ OutM do4: op : Operation := m(ℓi ,ℓj ).receiveEvent .event .operation ;5: dop := DesignOperation.new(); dop.name := op.name;
6: copyall op.Ownedparameter to dop.Ownedparameter ;7: add dop to rif ;8: if ℓj .represents.type = Component then9: Lcomp := Lcomp ∪ {ℓj};
10: end if11: end for12: usg := Usage.new(); usg .client := com; usg .supplier := rif ;13: add usg to com;14: for all ℓ ∈ Lcomp do15: opif : ContractInterface := ℓ.represents.type.provided ;16: cpos := Composition.new();17: cpos.client := rif ; cpos.supplier := opif ;18: end for19: return com;
The process of constructing a required interface is similar to the way a provided in-
terface is generated. In Algorithm3, we first build a new required interfacerif (line 1),
and copy the operation signatures from corresponding operations defined in the class
(line 3–7). A UML usageis used to link the required interface to its owner component
(line 12). In the last, if there are components that provide the required operations (line
8–10), we plug the provided interfaces of these components into required interfacerif
(line 14–18).
316
Curriculum Vitae
CONTACT INFORMATION
Name: Li Dan
Address: No. 1, Shanxi Road, Guiyang, Guizhou, China 550001
Tel.: +86 851 5928853(h) Mobile: 13885169969
E-mail: [email protected], [email protected]
RESEARCH INTERESTS
Model-driven development and model transformations; Formal techniques and sup-
porting tools; Information system development
EDUCATION
1. University of Macau, China, Phd Student in Software Engineering, 2008–2013
2. East China University of Science and Technology, China, B.S. in Chemical En-
gineering, 1980–1984
RELATED TRAINING
1. International Institute for Software Technology, United Nation University, Macau,
Fellow, March 2002–Nov. 2002
2. Okinawa International Center, Japan, Senior System Analyst/Designer, Nov.1997–
May 1998
PROFESSIONAL EXPERIENCE
1. Associate Researcher, Guizhou Academy of Sciences, China, 2007–2008
2. Assistant Researcher, Guizhou Academy of Sciences, China, 1984–2006
RESEARCH PROJECTS
1. A Framework of Diagnosing and Correcting for Software Errors under Confi-
dence Constraints, granted by the National Natural Science Foundation of China
(NSFC) (approved No. 90718009) as the major research plan on the basic re-
search of trustworthy software, Jan. 2008–Dec. 2010, as principal investigator.
2. Design and Development of eTechCMS: A Personalized & Intelligent Enter-
prise Content Management System, 2007 high-tech industrialization demonstra-
tion projects of Guizhou Province, granted by the Guizhou Province Develop-
ment and Reform Commission and the Department of Science & Technology of
Guizhou Province, May 2007–Dec. 2008, as project leader.
317
3. Research and Design of the B2 Level Security Database Based on the Logic SQL,
granted by the Special Governor Fund of Guizhou Province for Outstanding Sci-
entific and Educational Talents (2005-88), Dec. 2004–Dec. 2006, as principal
investigator.
4. Comprehensive Criminal Information System Based on Security Database for
Municipal Police Bureau, 2005 high-tech industrialization demonstration projects
of Guizhou Province, granted by the Guizhou Province Development and Re-
form Commission and the Department of Science & Technology of Guizhou
Province(2004-JN057), Dec. 2004–Dec.2005, as principal investigator.
5. Research on the Data Sharing Model of "Digital Guizhou", granted by the De-
partment of Science & Technology of Guizhou Province (2003GGY010), May.
2003–Dec.2004, as principal investigator
6. Application of the Formal Methods in Software Development, granted by the
Department of Science & Technology of Guizhou Province (2001-3010), Sept.
2001–June 2003, as project leader
7. Comprehensive Energy-saving Computer monitoring System, granted by the De-
partment of Science & Technology of Guizhou Province (1997-1058), May.
1997–April 1999, as principal investigator.
PATENTS
1. A Keywords-Based Personalized Document Processing System, Chinese inven-
tion patent ( No. 2007102001028), Aug. 2007, as second inventor.
PUBLICATIONS
Journal Papers
1. Dan Li , Xiaoshan Li, Volker Stolz,Model Querying with Graphical Notation of
QVT Relations, ACM SIGSOFT Software Engineering Notes, Vol. 37, No. 4,
pp. 1-8, July 2012.
2. Dan Li , Xiaoshan Li, Volker Stolz,QVT-Based Model Transformation Using
XSLT, ACM SIGSOFT Software Engineering Notes, Vol. 36, No. 1, pp. 1-8,
January 2011.
3. Dan Li , Xiaoshan Li, Jicong Liu, Zhiming Liu,Validation of Requirement Mod-
els by Automatic Prototyping, Innovations in Systems and Software Engineering,
Vol. 4, No. 3, pp. 241-248, October 2008.
318
4. Li Dan , Li Danning, Chris George,The Research and Design of a Web-Based
Formal Methods Tool: RRTChecker, Computer Sciences, Vol. 35, July 2008 (in
Chinese)
5. Li Dan , Li Danning,A Lightweight J2EE Web Framework Based on Open Source
Software, Guizhou Science, Vol. 25, No. 4, pp. 18-25, Dec. 2007. (in Chinese)
6. WANG Baohua, MA Xinqiang,LI Dan , LI Danning and ZHANG Heng,Re-
search and Design of the B2 Level Security Mechanism Based on the Logic SQL,
Guizhou Science, Vol. 25, No. 1, pp. 27-30, Mar. 2007. (in Chinese)
7. WANG Baohua, MA Xinqiang, LI Danning,LI Dan , ZHANG Heng and ZHAO
Zhenyong,Logo Technology and Analysis Examples of Security Database Covert
Channel, Computer Technology and Development, No. 2, pp. 233-235+238,
2007. (in Chinese)
8. WANG Baohua, MA Xinqiang,LI Dan , LI Danning, ZHANG Heng and ZHAO
Zhenyong ,Covert Channel Analysis in Security Database with High Security
Levels, Journal of Computer Research and Development, Vol.43(Suppl.II), pp.
168-172, Aug. 2006. (in Chinese)
9. Li Danning,Li Dan , Understanding Based Intelligent Interface Design, Guizhou
Science, Vol. 9, No. 4, pp. 314-321, Dec. 1991.
10. Li Danning,Li Dan , A Method of Chinese Character Frequency Adjustment with
Gradual Sequence Alternation, Guizhou Science, Vol. 8, No. 2, pp. 55-59, June
1990. (in Chinese)
11. Li Dan , Li Danning,An Interrupt Subroutine for Graphics Output on Printers,
The Journal of Chinese Computer Users, No. 10, 1989. (in Chinese)
12. Li Danning,Li Dan , A Chinese Word Input System of Following Text Situation.
Guizhou Science, Vol. 7, No. 2, pp. 64-69, June 1989. (in Chinese)
13. Li Dan , Li Danning, A General Subroutine for Outputting High Resolution
Graphics on Dot Matrix Printers, Machinery and Electronics, No. 5, pp. 16-
19, 1988. (in Chinese)
Conference Papers
1. Dan Li, Xiaoshan Li, Zhiming Liu, Volker Stolz,Support Formal Component-
based Development with UML Profile, In Proceedings 22nd Australasian Soft-
ware Engineering Conference (ASWEC 2013), Melbourne, Australia, IEEE, pp.
191-200, June 2013.
319
2. Dan Li , Xiaoshan Li, Zhiming Liu, and Volker Stolz,Interactive Transforma-
tions from Object-Oriented Models to Component-Based Models, In Proceed-
ings of International Symposium on Formal Aspects of Component Software
(FACS2011), Vol. 7253 of LNCS, pp. 97-114, Springer Verlag, 2012.
3. Dan Li , Xiaoshan Li, and Volker Stolz,Solving the TTC 2011 Compiler Op-
timization Case with QVTR-XSLT, In Proceedings Fifth Transformation Tool
Contest (TTC 2011), June 2011, Electronic Proceedings in Theoretical Com-
puter Science (EPTCS), Vol. 74, pp. 54-69.
4. Dan Li , Xiaoshan Li, and Volker Stolz, Saying HelloWorld with QVTR-XSLT –
A Solution to the TTC 2011 Instructive Case, In Proceedings Fifth Transforma-
tion Tool Contest (TTC 2011), June 2011, Electronic Proceedings in Theoretical
Computer Science (EPTCS), Vol. 74, pp. 223-236.
5. Dan Li , Danning Li,Towards a Formal Behavioral Semantics for UML Inter-
actions, In Proceedings International Symposium on Information Science and
Engineering (ISISE 2010), pp. 213-218, Dec. 2010.
6. Dan Li , QVT Based Model Transformation from Sequence Diagram to CSP, In
Proceedings of the 15th International Conference on Engineering of Complex
Computer Systems (ICECCS 2010), pp. 349-354, March 2010.
7. LI Dan , LI Danning, WANG Baohua, MA Xinqiang,The Optimization Princi-
ple of Chinese Word Segmentation Algorithm Based on Dictionary, In Proceed-
ings of the 2007 Symposium of Search Engine and WebMining (SEWM2007),
Haikou, Hainan, China, March 2007. Journal of Guangxi Normal University
(Natural Science Edition), Vol.24(2), pp. 95-98, Dec. 2006. (in Chinese)
8. Li Dan , Bernhard K. Aichernig,Combining Algebraic and Model-based Test
Case Generation, In Proceedings of First International Colloquium on Theoret-
ical Aspects of Computing, LNCS 3407, pp. 250-264, Springer-Verlag, 2005.
9. Li Danning,Li Dan , A User Adapting and Text Situation Following Chinese
Word Input System, In Proceedings of the ’91 Beijing International Conference
on Chinese Word Inputting From Keyboard, Beijing, Oct., 1991.
10. Li Dan , Li Danning, Xia Jianfang,A Method of Size Amplification and Shape
Smoothness for Dot Matrix Chinese Characters, In Proceedings of the Seventh
CMS National conference, Xi’an, China, Sept. 1990. (in Chinese)
11. Li Danning,Li Dan , An Intelligent User Interface Based on Understanding the
Process of Interaction, In Proceedings of the 3-th National Knowledge Engi-
neering Symposium, Chengdu, China, Aug. 1990. (in Chinese)
320
Related Documents
