Compositional MDA

Louis van Gool1 , Teade Punter1 , Marc Hamilton2 , and Remco van Engelen2
1
Technische Universiteit Eindhoven
Den Dolech 2, P.O. box 513, 5600 MB Eindhoven, The Netherlands
l.v.gool@tue.nl, t.punter@tue.nl
2
ASML
De Run 6501, 5504 DR Veldhoven, The Netherlands
marc.hamilton@asml.com, remco.van.engelen@asml.com

Abstract. In this paper we present a language that models an important aspect of ASML waferscanners, called coordination. The language
is a compositional subset of UML2.0 activity diagrams which by themselves are not compositional in our sense of the word. We show how we
transform models in this language into models for the ASML platform
that implements coordination. The fact that the language is compositional enables us to dene the transformation in a simple and compact
manner.

Introduction

ASML1 is a world-leading manufacturer of lithography systems (called waferscanners) for the semiconductor industry. Important requirements of ASML
waferscanners are high performance and accurate timing. Because o-the-shelf
solutions do not suce, ASML uses a proprietary coordination platform for controlling the machine parts of their waferscanners. Input for this coordination
platform is a denition of high-level services (abstract behaviours) in terms of
low-level services (resource behaviours) and the machine parts (resources) that
execute them.
Currently the input for the coordination platform is written in plain C-code
and documented in Word documents. Technische Universiteit Eindhoven (TU/e)
is investigating how ASML can benet from model-driven architecture (MDA) as
dened by the Object Management Group2 (OMG). We developed a language for
the design of abstract behaviours and constructed a model transformation that
enables automatic transformation into models for the ASML coordination platform. In MDA terms, we are transforming platform-independent models (PIMs)
into (semantically equivalent) platform-specic models (PSMs).
For the description of PIMs, we developed a compositional language that is
based on the activity diagrams3 of the Unied Modeling Language (UML), version 2.0. By compositional we mean that the language is built up from a few
1
2
3

www.asml.com
www.omg.org
This paper focuses on the behavioural part of coordination. The behavioural part is
complemented with a structural part that is not described in this paper.

O. Nierstrasz et al. (Eds.): MoDELS 2006, LNCS 4199, pp. 126139, 2006.
c Springer-Verlag Berlin Heidelberg 2006


Compositional MDA

127

simple patterns that can have subparts that are again built with these patterns.
This is the key idea behind the well-established principle of structured programming [1], where a language consists for example only of assignment statements,
sequentially composed statements, guarded statements and looped statements.
In section 2 we present a short overview of MDA and its potential benets
for ASML. Section 3 discusses the compositionality principle and explains what
is gained by applying this principle. In section 4 we explain the basic principles
of the coordination aspect of ASML waferscanners and dene the compositional
language that we developed for it, illustrating it by means of an example PIM.
Section 5 describes a simplied version of the ASML coordination platform and
shows parts of the PSM that is the result of applying the model transformation
to the example PIM. The denition of the model transformation is given in
section 6. Section 7 concludes the paper.

MDA

Model-driven development (MDD) is considered to be the next step in software

engineerings strive to construct systems at a higher level of abstraction [6].
Development in MDD is based on assemblies of domain-specic abstractions,
called models. The added value of MDD over traditional object-oriented development (OOD) is the concept of model transformation, in particular the ability
to (semi)-automatically transform high-level models (PIMs) into (semantically
equivalent) models that t a specic platform (PSMs), possibly enabling generation of executable code. MDA is the term used for the specic way the OMG
denes MDD.
An important ingredient in MDA is the explicit denition (standardization) of
the domain-specic languages (DSLs) that are used to describe models. ASML
expects that the use of standardized languages for concepts in their machine
domain will increase quality of designs and improve communication within and
between development teams.
MDA distinguishes two approaches for dening DSLs. In the approach called
metamodeling, DSLs (metamodels) are designed from scratch for a specic goal.
In MDA, a metamodel is described by means of the meta-object facility (MOF).
The other approach, called proling, is based on the reuse of existing MOF-based
languages, like UML, that are customized to ones specic needs by means of
proles. The customization is performed by means of stereotypes, tagged values
and OCL-constraints [2].
For our case we have chosen the proling approach. The main reason is the
expectation that (re)using standardized languages as much as possible improves
communication within the organisation. Furthermore, tools specically designed
for a standardized language like UML can already oer advanced support for a
DSL that is based on this language. Proling looses its benets over metamodeling if one only uses a few basic elements of the existing language to represent
the elements of the proled language. In principle one could only use the classes
and associations of UML to model any of the elements and connections of the

128

L. van Gool et al.

proled language. However, more is gained in terms of standardization and tool

support if one reuses other UML elements as much as possible.
As mentioned at the beginning of this section, model transformation is a key
concept in MDA. An important element of our case study was the implementation of an (automated) model transformation. Automated model transformation
of PIMs into PSMs reduces coding eort because the mental gap between PSMs
and code is much smaller than the gap between PIMs and code. Furthermore,
automated construction of PSMs is only a small step away from automatic code
generation. We also created a version of the transformation that produces code
(via a code metamodel) instead of the model presented in this paper.
Apart from the UML, MOF and prole standards, OMG is also working on
the Query/View/Transformation (QVT) standard. Like UML has become the
standard for modeling, OMGs intention is that QVT becomes the standard for
describing model transformations. The main reason for ASML to comply to standards like UML and QVT is better alignment of multiple modeling initiatives
that exist within and outside of ASML. To investigate feasiblity of automated
transformation when complying to QVT, the model transformation has been implemented in the (QVT-compliant) model-transformation language of Borland4
Together Architect 2006.

Compositionality

As pointed out in the introduction, we have chosen to develop a language that is

compositional. Many graphical general-purpose languages, like Petri nets or the
activity diagrams of UML, are not compositional in our sense of the word. In
principle, arbitrary complex networks of elements and connections can be created
in these languages, as illustrated by the activity diagram in Fig. 1. There are no
clear identiable patterns in such a model which makes it dicult to understand
how the activity behaves.
Besides the fact that unrestrained use of a language like activity diagrams can
easily lead to incomprehensible models, transformation of these kind of models
into models for a specic target platform, is also not feasible in general. This
would require the target platform to support the behaviour of arbitrary complex
activity-diagrams, which cannot and should not be expected from a dedicated
platform.
In the context of proling, the remedy is to conne oneself to a sublanguage
that is compositional, like for example structured workow languages [3]. The
constructs of a compositional sublanguage of a general-purpose language are
built using simple patterns of elements of the general-purpose language (in our
case patterns of activity-diagram elements). Figures 2 and 3 illustrate this notion
of compositionality. Figure 2 denes the patterns that are used to build the
activity that is presented in Fig. 3. The clouds in Fig. 2 represent an arbitrary
construct that is built using only the right three patterns.
4

www.borland.com

Compositional MDA

129

Fig. 1. Non-compositional activity

Fig. 2. Compositional patterns

Fig. 3. Compositional activity

The use of a language that is compositional helps in the construction of specications that are easy to understand. This principle holds under the assumption
that the languages constructs are rich enough for a designer to express his or
her thoughts in a clear and concise manner. The development of our language
was therefore performed hand-in-hand with the reconstruction from ASML documentation and C-code of several abstract behaviours, one of which (CLBS) was
considered the most complex instance.
The PIM of CLBS was presented to ASML architects to review its correctness,
completeness and understandability. The fact that the architects were immediately able to understand the model and use it to discuss details about CLBS,
gave a clear indication of the strength of the language.
Besides understandability of specications, another important advantage of
using a compositional language is that it makes automated model transformation
feasible because one only needs to be able to transform a few simple patterns.
The clear structure of the transformation is also expected to make it easy to
adapt the transformation to other platforms, which is crucial for a company
like ASML that develops and has to maintain many dierent versions of their
machines.

130

L. van Gool et al.

Next to a PIM, we also reconstructed a PSM of CLBS. The reconstruction

went hand in hand with the design of the transformation of which a simplied
version is described in this paper. As already mentioned, we also created an
adapted version of the transformation that can generate code. Because of the
clear structure of the transformation, this turned out to be a straightforward
task.

PIM

In this section we dene our language for the coordination aspect of ASML
waferscanners (from now on simply called coordination) and illustrate it by
means of an example PIM. As mentioned in the introduction, coordination is
about the denition of abstract behaviours. An abstract behaviour consists of
algorithmically combined resource behaviours which are behaviours of parallel
executing parts (of an ASML waferscanner), called resources.
An abstract behaviour is not as straightforward as a simple sequence of resource behaviours, but can contain decisions that are based on the results of
resource behaviours. Loops and parallellism are also part of abstract behaviours,
but are outside the scope of this paper.
An important aspect of coordination is that abstract behaviours are not executed in isolation. Abstract behaviours may execute concurrently if they do not
need a certain resource at the same moment. Sometimes one wants to prevent
that a resource is aected by another abstract behaviour, although one does not
need the resource to perform any resource behaviour. This can be guaranteed
by performing so-called passive behaviour on that resource.
We now dene our language for coordination. It consists of any activity that
can be built with the patterns proc, seq, assign, guard, if and call, presented in
Fig. 4. A cloud represents an arbitrary construct that is built using the last ve
patterns. We only show a specic case of the call pattern. In general there is one
active resource and several passive ones. Furthermore, the number of input pins
and output pins on the active action can be arbitrary (including zero).
We illustrate the language by means of a simple ctional example PIM, shown
in Fig. 5. The example describes the testing of a lamp. Two resources are involved in this example: a lamp that can be turned on and o and a sensor that
can check if the lamp produces light. The test starts with resource behaviour
CHECK LIGHT on the sensor. The result of this resource behaviour is stored in
variable LGT. Next, it is checked if variable LGT is equal to OFF (the %s are
explained below). If this is the case, variable LMP is set to ON and used as input for resource behaviour SET LAMP on the lamp. In other words, the lamp is
turned on in that case. It is then checked again if the sensor receives light. The
passive action for the lamp ensures that no other abstract behaviour can
use the lamp during this check. If the sensor reports that it does not receive any
light, we know for sure that something is wrong and return with return value
BROKEN, aborting all further execution. If in the end variable LGT is equal to
ON, the test terminates, returning the (default) return value OK.

Compositional MDA

proc

if

seq

assign

131

guard

call
Fig. 4. PIM Patterns

We now explain some peculiar details of the example. In the version of Borland
Together Architect 2006 that is available to us, expressions are strings without
any structure. For the transformation we have to be able to identify the variable
names in an expression however. We put %s around the variable names in an
expression to make it easier to recognize them. Parameter passing has been simplied by only allowing the use of variable names instead of arbitrary expressions
for the specication of inputs for a resource behaviour. The variable name that
species an input or output also determines (by name) the resource behaviours
parameter that is associated with this input or output. A consequence is that
a parameter of a resource behaviour can only be associated with the variable
that has the same name as the parameter. These simplications have no serious
inuence on the expressiveness of the language and allow us to implement the
transformation with the available version of the tool.

PSM

We now describe the ASML platform that implements coordination and show
parts of the PSM that is obtained by transforming the lamp-test PIM. For presentation and condentiality reasons, we present a simplied version of the platform.
Within the platform, an abstract behaviour is described by a sequence of
concrete behaviours and separate denitions of these concrete behaviours. During
the execution of a sequence of concrete behaviours, the platform oers a means
to skip all concrete behaviours in the sequence until a certain one. This enables
the implementation of conditional execution.

132

L. van Gool et al.

Fig. 5. PIM of lamp test

Abstract behaviours are (in their platform-specic form) oered to a scheduling component that tries to execute them in an optimal manner. For each abstract behaviour, the scheduling component determines the set of resources that
are needed for its execution and when they are needed. This denes a kind of
Tetris brick for each abstract behaviour that is used to determine optimal execution of abstract behaviours in a manner that resembles a game of Tetris [4].
Figure 6 illustrates this Tetris game. The + combines two Tetris bricks into
the schedule on the right-hand side of the =. Notice that the shape of the Tetris
bricks is xed and does not change under the inuence of gravity. As mentioned
in the previous section, passive behaviour can be used to prevent unwanted interference of abstract behaviours. In terms of the Tetris game, passive behaviour
can be used to extend Tetris bricks. The white Tetris brick in Fig. 6 contains
passive regions, indicated by a grey color.
Transforming algorithmic coordination of resource behaviours (PIM) into a sequence of concrete behaviours (PSM) is a rst step in determining when resource

Compositional MDA

133

Fig. 6. Scheduling, seen as a game of Tetris

Fig. 7. Sequencing part of the lamp-test PSM

behaviours are executed. In terms of the Tetris game, this step corresponds to
the denition of the overall structure of the Tetris bricks.
We distinguish two kinds of concrete behaviours: functional behaviours and
control behaviours. A functional behaviour corresponds to a call of a PIM. It
determines which resource behaviour is executed and which resources are passive
during this execution. Control behaviours are used to implement coordination
constructs like if and assign.
Figure 7 shows an activity diagram that describes the sequencing of concrete
behaviours for the lamp-test example. The behaviours IF1, ASSIGN2, ENDIF1,
GUARD3 and ENDPROC are control behaviours. The integer labels on control behaviours are necessary to distinguish control behaviours of the same kind5,6 . The
behaviours FN CHECK LIGHT and FN SET LAMP are functional behaviours. A
functional behaviour has the set of resources that should be passive as input.
5

Labeling is actually not necessary for our lamp-test example as each kind of control
behaviour occurs only once.
For simplicity we ignore the fact that an extra label should be added in order to
distinguish control behaviours of dierent abstract behaviours.

134

L. van Gool et al.

Fig. 8. Denition of EX CHECK LIGHT

Fig. 9. Denition of IF1

The denitions of concrete behaviours are specied separately from the sequencing of concrete behaviours. We omitted the denitions of the functional
behaviours as this requires a level of detail that would only distract from the
core issues. What is important to know, is that each functional behaviour FN X
is associated with a behaviour EX X that executes resource behaviour X with
the appropriate parameter values7 .
Figure 8 shows the denition of EX CHECK LIGHT. A special variable state
contains a record of the variables that occur in the PIM (LGT and LMP in the
lamp-test example). These variables are used to provide resource behaviours
with parameter values, store resource-behaviour results and steer control behaviours. During execution of EX CHECK LIGHT, the result of resource behaviour CHECK LIGHT is stored in variable LGT.
Figure 9 shows the denition of control behaviour IF1. If the value of variable
LGT is not equal to OFF when control behaviour IF1 is executed, all concrete
behaviours until ENDIF1 are skipped.
Figures 7, 8 and 9 only specify part of the lamp-test PSM. How a complete
PSM is obtained from a PIM, is dened by the transformation that is described
in the next section.
Notice that although both PIM and PSM are represented by activity diagrams, they are written in dierent languages. Due to space limitations, the
language for the PSMs is not explicitly described in this paper.
7

The denitions of the resource behaviours are outside the PSMs scope.

Compositional MDA

135

Transformation

We now describe the model transformation that transforms PIMs like the lamp
test of Fig. 5 into PSMs. A schematic description of the transformation is presented in Figs. 10, 11, 12, 13, 14 and 15. The fact that our language is compositional and the fact that the target platform has sucient expressive power,
together make it possible to dene the transformation in a compositional manner. We now explain the notation that we used to describe the transformation,
without going into the specics of the transformation itself.

n0 @pre = 1

Fig. 10. Transformation rule for proc

n : Integer
n0 @pre = n@pre
n1 @pre = n0
n = n1

Fig. 11. Transformation rule for seq

Each gure shows the transformation rule for a certain pattern. A transformation rule consists of three sections, separated by double lines. The left8 section
is called the source section, the middle section the variable section and the right
section the target section.
The source section contains a source pattern, describing a pattern that can be
used in the construction of a PIM. In the source pattern, source pattern variables
may be used to abstract from specic parts. In Fig. 14 for example, X and g
are source pattern variables. Source pattern variable X is an arbitrary construct
that is inductively built with the patterns seq, assign, guard, if and call and source
pattern variable g is a string. We left these types implicit.
8

For layout-technical reasons, the transformation rule for the call (Fig. 15) is presented
top-down. For this rule left is top and right is bottom.

136

L. van Gool et al.

n : Integer
n0 = n@pre
n = n0 + 1

Fig. 12. Transformation rule for assign

n : Integer
n0 = n@pre
n = n0 + 1

Fig. 13. Transformation rule for guard

n : Integer
n0 = n@pre
n1 @pre = n0 + 1
n = n1

Fig. 14. Transformation rule for if

Compositional MDA

137

n : Integer
n = n@pre

Fig. 15. Transformation rule for call

The target section contains a target pattern that describes how the source
pattern is implemented in the PSM. In Fig. 14 for example, the target pattern
is divided into two parts, separated by a single line. The left part describes
the sequencing of concrete behaviours and the right part describes their denition. The cloud with [[X]]n1 in it represents the sequencing part of the result
of transformation of X. The n1 is an integer input/output parameter for the
transformation rule that is used to transform X. This parameter is used to label control behaviours. As mentioned in the previous section, labeling of control
behaviours is necessary to distinguish control behaviours of the same kind.
The variable section consists of a list of typed parameters for the transformation (above the line) and constraints on the variables that occur in the transformation rule (below the line). The transformation rule for proc has no parameters
and the transformation rules for seq, assign, guard, if and call each have an integer parameter n (n : Integer). In the specication of a constraint, the value
that a variable x has when a transformation is initiated (its pre value), is represented by x@pre and the value that a variable has when a transformation is
completed (its post value), is represented by x. Equation n1 @pre = n0 + 1 in
the transformation rule for if (Fig. 14) for example denes that the pre value of
variable n1 equals the post value of variable n0 plus 1.

138

L. van Gool et al.

Like source pattern variables represent parts of a source pattern, target pattern variables represent parts of a target pattern. The post value of a target
pattern variable determines how it is instantiated. If the transformation rule for
if (Fig. 14) is initiated with n equal to 1, then (equation n0 = n@pre denes the
post value of n0 equal to the pre value of n) each occurrence of IFn0 and ENDIFn0
in the target pattern is instantiated as IF1 and ENDIF1 respectively. In other words,
in this particular execution of the if transformation rule, the IFs and ENDIFs are
labeled with 1 (notice the implicit conversion of the integer 1 to the string 1).
The function [ ] that occurs in the target section of the transformation rules
for assign, guard and if transforms an expression (string) such that each variable name x (indicated by %s) is replaced by the expression state.x that
represents the value of variable x in the target platform. If a source pattern
variable g equals for example the string %LGT% = OFF, then [g] is equal to
state.LGT = OFF.

Conclusion

In this paper we presented a language that models the concept of coordination

as it occurs in ASML waferscanners. The language is a compositional subset of
UML2.0 activity diagrams, meaning that it is built up from a few simple patterns
of UML2.0 activity-diagram elements, where the patterns can have subparts that
are again built with these patterns. We dened a model transformation that
transforms models in the language (PIMs) into models for a proprietary ASML
platform that implements coordination (PSMs).
The approach to use a compositional subset of a standardized language turned
out benecial. ASML architects were quickly able to understand the language
and discuss details of a coordination instance that was considered very complex.
Furthermore, the languages compositionality guided the denition of the model
transformation. Feasibility has been shown by a working implementation of the
model transformation.
We think that the compositional approach that we took can be benecial for
companies who, like ASML, cannot use o-the-shelf solutions because of high
demands on their platforms, but still want to use well-supported easy-to-learn
design languages with a feasible approach to generation of code for all kinds of
dierent platforms that are used in dierent versions of their products.

Acknowledgements
The research presented in this paper was conducted within the IDEALS research
project, under the responsibility of the Embedded Systems Institute (ESI). This
project is partially sponsored by the Dutch Ministry of Economic Aairs under
the Senter program. We like to thank Tanja Gurzhiy from TU/e (OOTI) who implemented the model transformation, Wilbert Alberts and Stefan Slootjes from
ASML for reviewing our models and Michel Reniers for discussing a draft version
of the paper. We also thank the anonymous referees for their helpful comments.

Compositional MDA

139

References
1. E.W. Dijkstra. Notes on Structured Programming. In Structured Programming
(1972) 182.
2. L. Fuentes, A. Vallecillo. An Introduction to UML Proles. In UPGRADE, The
European Journal for the Informatics Professional (2004) 513.
3. B. Kiepuszewski, A.H.M. ter Hofstede, C. Bussler. On Structured Workow Modelling. In Conference on Advanced Information Systems Engineering (2000) 431445.
4. N.J.M. van den Nieuwelaar. Supervisory Machine Control by Predictive-Reactive
Scheduling. Ph.D. thesis. Technische Universiteit Eindhoven (2004).
5. D.A.C. Quartel, R.M. Dijkman, M. van Sinderen. Extending Proles with Stereotypes for Composite Concepts. In MoDELS, Proceedings of the 8th ACM/IEEE International Conference on Model Driven Engineering Languages and Systems (2005)
232247.
6. S. Sendall, W. Kozaczynski. Model Transformation the Heart and Soul of ModelDriven Software Development. In IEEE Software, Special Issue on Model Driven
Software Development (2003) 4253.