Extended Model Relations with Graphical
Consistency Conditions
Jan Hendrik Hausmann, Reiko Heckel, and Stefan Sauer
University of Paderborn, Computer Science Department
D-33095 Paderborn, Germany
{hausmann|reiko|sauer}@upb.de
Abstract. Consistency of models and model transformations are
strongly interrelated topics. It is thus desirable to have a single notation to express model properties concerning both aspects. When using
meta modeling techniques, graph transformations are a natural candidate to express model transformations. This paper explores the use of
graph transformations for denoting consistency conditions between models. This technique yields benefits for different types of interrelation between transformation and consistency. A special focus is put on the generation of automatic consistency-establishing transformations.
Keywords: meta modeling, static model consistency, graph transformation,
model transformation
1
Introduction
Models are used in software engineering for capturing ideas and aspects of software systems, for developing such systems or for documenting them. Yet, a
system model is seldom a single artifact but rather a collection of partial models, each representing a particular view of the system. Furthermore, it has been
recognised that the expression of different aspects of the software requires specialised modelling languages. The UML [Obj01] as the standard language for the
expression of software models addresses this need by providing several different
languages (diagram types) and extension mechanisms to introduce additional
or specialised diagrams. The known problem with this multi-view and multilanguage approach is the maintenance of consistency.
Another closely related problem is that of change. Since models are used
to represent and construct software, they are (alomost) never stable. Rather,
changes in the model occur frequently to reflect either alterations in the represented information (e.g. evolving requirements) or the ongoing system development (e.g. by introducing design information or translating model information to
code). The term model transformation has been coined to discuss the problems
this constant change entails.
In our view, these two issues are not separate problems but rather strongly
related ones. On the one hand, without a notion of consistency that should
be preserved or achieved, models can be freely transformed in every way without problems. Obviously, the interesting problem is to find transformations that
respect or establish some (consistency) properties of a model. Notions of consistency, on the other hand, have to anticipate changes in the model. A consistency
relation that has to be re-established from scratch each time a transformation
occurs will be of limited use in practice. The notion of consistency should be
incremental instead [EGHK02]. Thus, if both aspects could be expressed by a
single notation, one could better reason about the connections and implications
of the different specifications.
In this paper, we will present our notions of consistency and transformations
in more detail (Sect. 2) and introduce an integrated approach that can be used
for the expression of consistency requirements (Sect. 3) as well as for model
transformations (Sect. 4). Open issues and further work are discussed in the
concluding Sect. 5.
2
Consistency and Model Transformations
Models are used to represent (views on) information. If the same information
is represented in multiple models, the models are said to overlap. This overlap
of information can happen between models of the same type expressing partial
views on the same information (e.g. different class diagrams overlapping in some
elements), between models of different type (e.g. a sequence diagram and a class
diagram) and even between meta-levels (a UML model has to be consistent with
the UML metamodel). Overlap of models can be represented as a relation over
models.
overlaps : M odeln
If overlapping models represent information in a non-contradictory way, they
are said to be consistent. The set of consistent tuples of models is typically described in terms of consistency conditions. These conditions either require or
interdict certain combinations of models with respect to the notion of consistency. Thus, a consistency condition can as well be regarded as a relation over
models.
cc : M odeln
From this point of view, the well-formedness of a model with respect to its
metamodel is a special type of consistency as well as the consistency of types
used in a sequence diagram with the corresponding class diagram. Consistency
may concern the static structure of models (static consistency) as well as the
behaviour expressed by them (dynamic consistency). In this paper, we will talk
about static consistency only. For reasons of simplicity, we will also focus on
binary consistency relations. Therefore, two models A and B ∈ M odel are consistent with respect to consistency condition cc iff cc(A, B).
Following the above definitions, cc ⊆ overlaps, i.e., in the case of binary
consistency conditions the following implication holds:
∀A, B ∈ M odel : cc(A, B) ⇒ overlaps(A, B)
2
Model transformations describe the application of techniques on one model
to create a new model (which may either be another representation of the same
information or extended/changed in some ways). The transformation may either
be monolithic or constructed from steps. Well-known examples for model transformations include the translation of models into new languages [Ake00,Var02],
the generation of new views on underlying information (e.g. by abstraction) or
the development of models according to some process description (refinement).
In contrast to consistency relations, transformations are interpreted to be operational rather than declarative. Thus, a transformation relation usually distinguishes between the ’before’ and the ’after’ model and is formulated in terms that
describe a construction leading from the former to the latter. Transformations
can be regarded as functions over models.
t : M odel → M odel
When combining the concepts of consistency and transformation, different
interesting questions arise (see Fig. 1):
Consistency-perserving Transformation
Self-consistent Transformation
consistent
Model A
t
consistent?
Model B
Model A
consistent?
t
Model A’
Model A’
Consistency-establishing Transformation
Multiple consistency
consistent
Model A
t?
MetaModel A
Model B
MetaModel B
consistent
consistent
Model A’
Model A’
consistent
t
Model B’
consistent
Fig. 1. Scenarios with interrelation of consistency and transformations
a) Is a transformation consistency-preserving, i.e., does it change a model in a
way that its consistency with another model is preserved (Fig.1 upper left)?
Especially automatically performed transformations are supposed to have
this property. A very natural example is the consistency of a UML model
with the UML metamodel. Any transformation that results in a model which
violates the constraints of the UML metamodel is normally unacceptable.
Formally, a transformation t is consistency-preserving iff
∀A, B ∈ M odel : cc(A, B) ⇒ cc(t(A), B)
3
b) Is a transformation consistency-enforcing, i.e., does it change a model in a
way that makes the result of the transformation consistent with some given
context (Fig.1 lower left)? Whenever transformations are not proven to be
consistency-preserving, but are e.g. performed manually by a modeller, it is
possible that models become inconsistent. For certain inconsistent situations
there exist transformations which re-establish the consistency. Such transformations are usually implemented in modelling tools (though up to date
in most cases only for consistency with respect to the metamodel). Formally,
a transformation is consistency-enforcing iff
∀A, B ∈ M odel : (overlaps(A, B) ∧ ¬cc(A, B)) ⇒ cc(t(A), B)
c) Is a transformation a consistent transformation, i.e., is the result of its application consistent with the original model (Fig.1 upper right)? Usually this
kind of consistency is concerned with the preservation of semantic properties. Examples include the refactoring and the translation of models as well
as code-generating transformations. It is crucial in these cases that the result of the transformation faithfully represents the semantics of the input.
Formally, a transformation is a consistent transformation iff
∀A ∈ M odel : cc(A, t(A))
d) The most common case is a combination of these scenarios (Fig. 1 lower
right). The result of a transformation (model B’) has to be consistent with its
language definition (metamodel B) and be semantically related to its input
(model A’). In this case of multiple consistency relations, a transformation
is highly dependent on the source and target languages and the notion of
semantic consistency underlying the transformation.
∀A, A0 , B, B 0 ∈ M odel :
(ccm1 (A, A0 ) ∧ t(A0 ) = B 0 ) ⇒ (cct (A0 , B 0 ) ∧ ccm2 (B, B 0 ))
3
Expressing Consistency
The most common way to express consistency between UML models is the specification of OCL expressions. OCL is the Object Constraint Language, a higherorder logic notation that is part of the UML standard [Obj01]. OCL expressions
are associated with the UML metamodel to describe the details of valid UML
models. A recent approach [KA02] defines the consistency of models by introducing relations between models that are further detailed by OCL expressions.
We will heavily rely on that work and try to show—using similar examples—how
a graph-transformation-based approach compares to the results presented there.
The main ideas of that work are as follows (for a detailed description, see
[KA02]): Whenever elements of two models are related to each other (i.e. there
is an overlap), a relation class should be introduced (XRelY in the example of
Fig. 2) that defines the range and the domain objects. It should be pointed out
4
that all domain objects should be of the same type, but the domain does not
have to cover all instances of this type (the same holds for the range). Hence,
the relation has to be defined on the model rather than on the metamodel level.
According to the relation, pairs should be defined (X2Y in the example) that
connect one object of the domain to one object of the range . This pattern is
given in Fig. 2.
XRelY
1
domain
*
X
1
x
element
X2Y
1
y
range
Y
Fig. 2. The relationship pattern
An example for the application of this pattern given in the original paper
is that of the mapping between class diagrams and instance diagrams, i.e., an
instantiation relation. Figure 3 gives the abstract syntax of the diagram types
and the mapping between them (we choose a simplified version of the example).
Class diagrams are reduced to Classes, Associations and AssociationEnds (see
the left package in Fig. 3), while the instance diagrams comprise Objects, Links
and LinkEnds (right package in Fig. 3). The corresponding relations and pairs are
defined in the middle package. Thus, associations are related to links, association
ends to link ends and classes to objects.
We can now proceed by specifying the properties of these relations and further
consistency constraints. A relation can be total, onto, functional, or inverse functional. Combination of these properties yields bijective relations. In [KA02] these
properties are expressed by OCL expressions using set-based query operations.
The advantage of that kind of notation is that it is very powerful (higher-order
logic) and standardised in the UML. The ability to define auxiliary functions
makes for good modularisation of the definition. One drawback of the notation
is, however, that it is textual. This is especially disadvantageous when navigation over object structures has to be described. The strong modularisation also
makes it hard to grasp the complete meaning of an expression or to spot errors.
We are thus confident that a graphical notation has benefits in comparison with
the OCL-based approach (although it incorporates some drawbacks too).
There are several examples in the literature for the definition of consistency
with graphs or graph transformations [ET00,EK80,MSW00,HW95]. We orient
ourselves on the concept of graphical consistency conditions as introduced in
[HW95]. A graphical consistency condition (GCC) contains the specification of
a counter example, i.e., a situation that must not occur. This kind of specifica5
ClassDiagram
Relations
InstanceDiagram
range
Association
domain
AssocRelLink
name:String
x
1
2
Association End
name:String
uppper:Int
lower:Int
1
domain
Assoc2Link
y
1
range
AssocEndRelLinkEnd
AssocEnd2LinkEnd
label:String
y
range
domain
ClassRelObject
x
1
Object
id:String
class:String
element
Class2Object
2
LinkEnd
element
x
Class
name:String
Link
label:String
element
y
allParent
Fig. 3. Abstract syntax of class diagrams, instance diagrams and their relations
tion is equivalent to the specification of valid situations (as done, e.g. in OCL
invariants), but it allows for an intuitive and simple construction of the graphs.
Examples are given in Fig. 4.
The examples are presented as typed and attributed (left sides of)
graph transformation rules including Negative Application Conditions (NACs)
[HHT96]. The GCCs intuitively specify patterns that can be matched in a model.
This is similar to the idea of collaborations on the specification level as defined
in the UML. Thus, the elements of the GCCs could also be regarded as roles.
If NACs (the crossed out structures) are specified, these structures must not be
present for the GCC to match. Furthermore, each GCC is given a name and a
context element with respect to which it is defined. This information is given
in the head of the rule; and the context element is given the rolename context
for readability purposes. Formally, we use the mechanism of graph matching as
known from graph transformations [Roz97].
The examples in Fig. 4 define the four basic properties of a relation as GCCs.
The GCC in the upper left corner of Fig. 4 is said to match in a given model if an
element from the domain of the relation XRelY can be found which participates
in two pairs (X2Y) of this relation. Note that we assume the matching to be
injective, i.e., the roles p1 and p2 cannot be identified. Thus the rule expresses
that a relation is functional unless an element of the domain participates in two
pairs. It is total unless there is an element of the domain which does not participate in a pair (lower left). The properties ‘isInverseFunctional’ and ‘isOnto’ are
accordingly defined for the range elements. Remember that a GCC specifies the
counter example, thus the specified pattern must not be present for the condition
to hold.
6
XRelY.isFunctional
XRelY.isInverseFunctional
context:XRelY
domain
context:XRelY
element
p1:X2Y
x
:X
element
p1:X2Y
element
p2:X2Y
x
element
p2:X2Y
XRelY.isTotal
x
range
:Y
y
XRelY.isOnto
context:XRelY
domain
y
context:XRelY
element
p1:X2Y
element
p1:X2Y
:X
range
y
:Y
Fig. 4. Basic constraints for the relationship pattern
These basic constraints define the properties of the relationship pattern as
specified in Fig. 2. When applying this pattern to a specific model consistency
problem (as shown in Fig. 3 for class diagrams an instance diagrams), these
properties will have to be defined for the specific context as well. This is done
by associating elements with GCCs by making them the context element of the
GCC. GCCs are combined conjunctively, i.e., none of the consistency rules must
match to achieve a consistent model. In the example given above, we want to
define that the relation AssociationRelLink is onto and inverse functional (every
link must conform to exactly one association). The result of applying the appropriate GCCs is given in Fig 5. Since the other relations (ClassRelObject and
AssociationEndRelLinkEnd) have the same constraints, they are omitted here.
The given GCCs for the relationship pattern only cover the most common
cases of consistency conditions. There are more complex and specific constraints
which cannot be predefined in general. In the example, we want to express that
a link is correctly typed, i.e., the connected objects conform to the classes connected to the respective association. In [KA02], this is done with the following
OCL expression that uses the auxiliary function range lookup to get all pairs
that contain a certain range element:
context PackageSnapshot inv:
associationRelLink.elements->forAll(el |
el.link.linkEnd->forAll(le | let classOfObject =
classRelObject.rangeLookup(le.target).class in
7
AssocRelLink.isOnto
AssocRelLink.isInverseFunctional
context:AssocRelLink
context: AssocRelLink
element
element
:Assoc2Link
y
range
p1:Assoc2Link
:Link
element
p2:Assoc2Link
y
range
:LInk
y
Fig. 5. GCCs for AssociationRelLink
classOfObject->union(classOfObject.allParents)
->includes(el.association.associationEndRelLinkEnd
->rangeLookup(le).associationEnd.target))
Although it is precisely defined, this is not very intuitive. But the understandability is crucial since these constraints cannot be pre-coined in the form
of patterns (by skilled specialists) but have to be created specifically for each
model. If we attempt to express this consistency condition graphically, we end
up with the GCC in Fig. 6. This rule states that a link is correctly typed, unless
the object at the links end is neither typed according to the class at the end
of the association, nor according to any of its subclasses. This example shows
nicely that it appears more intuitive to specify complex structures (like the one
in Fig. 6) graphically.
LinkEnd.isCorrectlyTyped
:AssociationEnd
:AssocEnd2LinkEnd
context:LinkEnd
:Class
:Class2Object
: Object
:Class
allParents
:Class
Fig. 6. GCC expressing the correct typing of links
8
There are shortcomings of the graphical approach as well. Once we move from
mainly structural features to evaluations of attributes, the graph-based approach
lacks intuitive concepts. For example, if we try to express that the multiplicities
specified in the class diagram (attributes upper and lower in AssociationEnd)
have to be respected in an instance diagram, we cannot do this in a general way.
An amalgamation of OCL and graph-based expressions could be beneficial here.
4
Expressing Transformations
Up to now we have only presented concepts to denote consistency conditions.
Now we want to show how the chosen graph-based approach can serve the integration of consistency and transformation notions. First, we focus on the scenario
of consistency-establishing transformations. A consistency-establishing transformation is a transformation that is applied to a model which is currently inconsistent with some other model. The transformation is supposed to heal the
inconsistency and provide a consistent model (or at least an improved model).
Such transformations are needed to propagate e.g. user changes through different consistent models or to update internal representations of a modelling tool.
Each of these automated transformations starts with an inconsistency. Thus,
whenever one of the consistency conditions given above matches in a model, we
do not only obtain the information that the model is inconsistent, but we also
know where the inconsistency resides and can apply automated transformations
to improve the situation.
We can distinguish between three basic reactions to the detection of an inconsistency. Either we delete elements that violate the consistency; or we insert new
(dummy) elements into the model that re-establish the consistency, but which
might have to be detailed by the user later on; or we generate an exception and
ask the user to intervene manually. Since the GCCs are already based on graph
transformation mechanisms, it is easy to extend them with specifications for the
automatic improvement of inconsistent situations. We treat the GCC as the left
hand side of a graph transformation rule and supply a right hand side for the
rule. While the left hand side (the GCC) specifies the (inconsistent) pre-state
of the transformation, the right hand side gives the (improved) post-state after
the application of the transformation. Elements occurring on both sides of the
rule are identified, elements occurring only on the left hand side are deleted, and
elements occurring only on the right hand side are created. Thus we can specify
the deletion of offending elements as well as the introduction of new elements. If
no right hand side is given for a GCC, the inconsistency cannot automatically
be remedied.
Applied to the example, we can e.g. state that if the GCC AssociationRelLink.isOnto in Fig. 5 is violated (the AssociationRelLink is not onto, i.e.,
there is a Link that is not in a pair with a corresponding Association) we can
delete the link (see Fig. 7). While this might be desirable from the viewpoint of
consistency, it might not be suitable from the users viewpoint as he could not
establish the pair without creating the link first (a pair needs both partners, see
9
Fig. 2) and could not create the link without the pair since it would be deleted
immediately. We may thus consider the rule in Fig. 8 to be better suited to deal
with this situation. This rule shows an extension of the GCC from Fig. 5 as
its left hand side (although the left hand side is notated on top of the rule for
layout reasons). By extending the original GCCs, we are able to denote special
situations that can be automatically corrected. The special case here consists of
finding an association that corresponds to the links (association name equals link
label). In this case, we can automatically generate a new element (the pair) that
heals the inconsistency. If this rule is used instead of the deleting one in Fig. 7,
a modeller can create a new link and the corresponding pair will be established
automatically.
AssocRelLink.isOnto
context:AssocRelLink
context:AssocRelLink
element
:Assoc2Link
y
:Link
Fig. 7. Graph transformation rule repairing the inconsistency by deleting the link
We can thus see how GCCs may not only serve to denote consistency conditions, but how they can also be used to trigger automated transformations that
improve the model (in special cases). Thus the connection between consistency
conditions and consistency-enforcing transformations is nicely provided by this
mechanism. We identified three more situations in which these topics interrelate
in Sect. 2. We will now proceed to review the benefits of our approach for each
of them :
– Consistency
preserving
transformations: Graph transformations are a natural candidate to specify model transformations (see
e.g. [Var02,HKT02]). If a transformation is given as a graph transformation
and the consistency is specified in the form of GCCs, we can apply the
results from [HW95]. These results do not only allow for a check of
rules whether they preserve certain consistency conditions, but they also
introduce a technique to modify transformation rules to guarantee this
consistency preservation.
– Consistent transformations: The technique presented here may as well
work for translation approaches since the consistency with an empty model
may be considered as a (very complex) case of inconsistency. A sufficiently
advanced set of transformation rules based on GCCs should be able to build
a translated version of the input. The problem here is the coordination of
different rules. It is possible to have creating and deleting rules working
against each other, thus having a translation that never terminates. To claim
10
AssocRelLink.isOnto
context:AssocRelLink
domain
:Association
name = x
element
:Assoc2Link
range
: Link
label = x
context:AssocRelLink
domain
:Association
name = x
element
:Assoc2Link
range
: Link
label = x
Fig. 8. Graph transformation rule repairing the inconsistency by creating a pair
11
that this scenario really works with the GCC-based rules, further experiences
with this approach are necessary.
– Multiple consistency conditions: The common scenario of multiple consistency conditions also profits from the GCC-based rules. By giving a set
of consistency-establishing rules, we can focus each rule on one specific aspect of the multiple consistencies and disregard others. Take the rule from
Fig. 7 as an example. If this rule is applied to delete an untyped link, we
create new inconsistencies, because the ends of this link are still part of the
model, but they are not connected to a link anymore. Thus, by correcting
an inconsistency stemming from the inter-model consistency (links must correspond to types), we violate the model-metamodel consistency (links ends
must be connected to links). But if this inconsistency is also equipped with
an automatic correction rule, the correction can cascade over several rules
until a consistent model is reached (although it cannot in general be guaranteed that the cascade terminates). Using the rules this way, it becomes
possible to have transformations in multiple consistency settings that focus
on a single consistency condition only. This makes for better modularisation
and changeability.
5
Conclusions and Future Work
We have taken up the notion of relationship patterns [KA02] to express related
elements in models and introduced a graphical way to specify the consistency
conditions of these relationships. The GCCs presented here are intuitively understandable and especially suited to express complex object structures. They can
also be equipped with mechanisms that allow for the automatic correction of certain inconsistencies. The advantages of this technique are that consistency and
transformations can be studied in a single language and that it yields benefits
for all mentioned scenarios in which consistency and transformation interact.
While we are convinced that this approach is a promising way to specify
consistency and transformations of models, important work remains to be done.
Apparently, the claim of understandability has to be supported by further case
studies. Especially in comparison with OCL it should be pointed out that OCL
is part of the UML standard and cannot easily be dismissed. An amalgamation
of the two techniques might be beneficial to combine the visual power of the
GCCs and the set-theoretic and logic expressions of OCL. A first idea for such
an amalgamation is to regard the labels of the GCCs as predicates that can be
used in OCL expressions. In that way, it would be easy to express object structures by GCCs and higher-order expressions in OCL. This idea has to undergo
further investigation. Another approach towards the same goal is presented in
[BKPPT01], where an encoding of OCL expressions in graphical UML notation
(collaboration diagrams) is given.
Another necessary extension of the presented approach are events. We have
already implicitly used parts of the event-condition-action (ECA) concept from
active database systems (see e.g. [DBB+ 88]). The GCCs specify the condition
12
under which a repair action (the right hand side of the rules) is being invoked.
What is missing in our concept is information about dependencies on certain
previous actions. As we pointed out earlier, modellers have to create temporarily inconsistent situations to advance the state of a model. A system should not
interdict this, but rather aid them in their work. Thus it is of interest which
actions precede an inconsistent situation. If an association has been deleted, it
might seem feasible to delete all links that have been instantiated from this association. But if the last action has been the creation of a link with an unknown
label, it seems more natural to create a dummy association which the modeller
may then specify in detail. Thus an event-driven mechanism for the evaluation
of the rules presented here would allow for a fine-grained control over the automatic correction of inconsistencies. Such a mechanism could also be used to
control the translation of complex models by GCC-based rules (as mentioned
in Sect. 4). Furthermore, event-driven consistency checks are an efficient way to
incrementally re-validate only the context of the last changes and not the whole
model.
References
[Ake00]
David H. Akehurst. Model Translation: A UML-based specification technique and active implementation approach. PhD thesis, December 2000.
(unknown variable note).
[BKPPT01] P. Bottoni, M. Koch, F. Parisi-Presicce, and G. Taentzer. A visualization of ocl using collaborations. In M. Gogolla and C. Kobryn, editors,
Proc. UML 2001, Toronto, Kanada, volume 2185, pages 257–271. SpringerVerlag, 2001.
[DBB+ 88] Umeshwar Dayal, Barbara T. Blaustein, Alejandro P. Buchmann, Upen S.
Chakravarthy, M. Hsu, R. Ledin, Dennis R. McCarthy, Arnon Rosenthal,
Sunil K. Sarin, Michael J. Carey, Miron Livny, and Rajiv Jauhari. The
hipac project: Combining active databases and timing constraints. SIGMOD Record, 17(1):51–70, 1988.
[EGHK02] G. Engels, L. Groenewegen, R. Heckel, and Küster. Consistency-preserving
model evolution. In Proc. UML 2002, Dresden, Germany, LNCS. SpringerVerlag, October 2002. To appear.
[EK80]
H. Ehrig and H.-J. Kreowski. Applications of graph grammar theory to
consistency, synchronization, and scheduling in database systems. Information Systems, 5:225–238, 1980.
[ET00]
H. Ehrig and A. Tsioalikis. Consistency analysis of UML class and sequence diagrams using attributed graph grammars. In H. Ehrig and
G. Taentzer, editors, ETAPS 2000 Workshop on Graph Transformation
Systems (GraTra), Berlin, Germany, 2000.
[HHT96]
A. Habel, R. Heckel, and G. Taentzer. Graph grammars with negative
application conditions. Fundamenta Informaticae, 26(3,4):287 – 313, 1996.
[HKT02]
R. Heckel, J.M. Küster, and G. Taentzer. Towards automatic translation
of UML models into semantic domains. In H.-J. Kreowski, editor, Proc.
ETAPS’02 Workshop on Application of Graph Transformation (AGT’02),
Grenoble, France, April 2002.
13
[HW95]
[KA02]
[MSW00]
[Obj01]
[Roz97]
[Var02]
R. Heckel and A. Wagner. Ensuring consistency of conditional graph
grammars – a constructive approach. In Proc. of SEGRAGRA’95 ”Graph
Rewriting and Computation”, volume 2 of ENTCS, 1995.
St. Kent and D. Akehurst. A relational approach to defining transformations in a metamodel. In Proc. UML 2002, Dresden, Germany, LNCS.
Springer-Verlag, 2002. To appear.
M. Münch, A. Schürr, and A. Winter. Integrity constraints in the multiparadigm language progres. In Theory and Application of Graph Transformations, 6th International Workshop, TAGT’98, Paderborn, Germany,
November 16-20, 1998, Selected Papers, LNCS. Springer-Verlag, 2000.
Object Management Group. UML specification version 1.4, 2001.
G. Rozenberg, editor. Handbook on Graph Grammars: Foundations, volume 1. World Scientific, Singapore, 1997.
Dániel Varró. Automatic program generation for and by model transformation systems. In Hans-Jörg Kreowski and Peter Knirsch, editors, Proc.
AGT 2002: Workshop on Applied Graph Transformation, pages 161–173,
Grenoble, France, April 12–13 2002.
14