Graph Transformation
as a Conceptual and Formal Framework
for System Modeling and Model Evolution
Gregor Engels and Reiko Heckel
University of Paderborn, Dept. of Computer Science, D 33095 Paderborn, Germany
{engels|reiko}@upb.de
Abstract. Distributed software systems are typically built according
to a three layer conceptual structure: Objects on the lowest layer are
clustered by components on the second layer, which themselves are located at nodes of a computer network on the third layer. Orthogonal
to these three layers, an instance level and a type or schema level are
distinguished when modeling these systems. Accordingly, the changes a
system experiences during its lifetime can be classified as the system’s
dynamic behavior on the instance level and as the evolution of the system on the schema level. This paper shows how concepts from the area of
graph transformation can be applied to provide a conceptual and formal
framework for describing the structural and behavioral aspects of such
systems.
Keywords: typed graph transformation, hierarchical graphs, system
modeling, model evolution
1
Introduction
The structure and characteristics of software systems have changed dramatically
during the last four decades. Starting with small programs in the 1960s and continuing with large monolithic systems in the 1970s, the 1980s faced a development
towards hierarchically structured subsystems or modules. Today, software systems represent complex, often dynamic networks of interacting components or
agents. In order to adapt to changing requirements and application contexts, and
supported by modern programming language features (as, e.g., Java RMI [36]),
middleware standards (like CORBA or DCOM [28,7]), and world-wide connectivity, these components may evolve over time, and they may be down-loaded
and linked together while the system is executing.
Beside the development from monolithic and static towards distributed and
mobile applications, the process of software development has also changed. Today’s software development teams consist of developers with different expertise,
skills, and responsibilities. Due to resource management, organizational, or administrative reasons, the development process itself may be distributed. Moreover, since complex systems can no longer be built from scratch, an incremental
U. Montanari et al. (Eds.): ICALP 2000, LNCS 1853, pp. 127–150, 2000.
c Springer-Verlag Berlin Heidelberg 2000
128
G. Engels and R. Heckel
software development process is employed which is structured in several phases
like, for example, a requirements analysis, design, and implementation phase (cf.
[24]).
A major concern for the success of such a distributed, incremental process is
the maintenance of consistency in different dimensions: for instance, between the
behavior of different components of the system, between the concepts used by
different development teams in the project, or between the artifacts of different
phases of development.
An important means for achieving consistency in all dimensions is to build
a model. It can, for instance, facilitate formal verification of component interaction, form the basis for communication between teams, and serve as project
documentation where all relevant decisions are documented in order to trace
design choices between different phases of development. In particular, a requirements specification document is indispensable in which the functionality of the
software system to be built is stated. This document may represent a contract
between the customer and the software development team as well as a contract
within the team between software engineers being responsible for the analysis
and design tasks and the programmers being responsible for a correct and efficient implementation.
Thus, the model has to be written in a language which is intuitively and easily
understandable by customers, in general not being computer scientists, as well
as by software engineers and programmers, hopefully being computer scientists.
Particularly, this means that the used specification or modeling language has to
provide language features which are on an appropriate abstraction level. Thus,
the language has to offer support to abstract from programming or even machinedependent details on the one hand and from unimportant real-world details on
the other hand (cf. Fig. 1).
real world
abstracts from
analyse and
design
system
model
code
abstracts from
program
Fig. 1. Role of a system model.
Often, informal diagrammatic modeling languages like the Unified Modeling
Language (UML) [27] are considered the first choice from this point of view:
They are visual and apparently easy to understand and, due to the use of various diagrams and special-purpose notations for different aspects, they provide
Graph Transformation as a Conceptual and Formal Framework
129
good support for high-level specifications. However, as we can judge from our
own experience in teaching and modeling in UML, the language still lacks a clear
underlying conceptual model of the systems to be modeled [20]. But, an agreement on such a conceptual model has to precede the definition of syntax and
semantics of a language, as only on this base appropriate language features, a
precise semantics, and adequate pragmatic guidelines on how to use the language
can be given.
Therefore, the aim of this paper is twofold. First, we want to contribute to
the understanding of the conceptual model underlying today’s software systems.
This shall be done by presenting a typical example of a mobile, distributed application and by identifying three relevant dimensions. Second, we shall provide a
formalization of the conceptual model using concepts and results from the theory
of graph transformation systems. The basic idea is to model the system’s states
as graphs, and to specify its dynamic change by transformation rules.
In the theory of semantics, various formalisms have been developed for the
operational specification of concurrent, distributed and mobile systems. Most
of them are based on a notion of state much simpler than graphs. Among the
numerous term-based approaches we only mention process calculi like [42,3,34,43]
building on labeled transition systems and the Structured Operational Semantics
(SOS) paradigm [44], and approaches based on rewriting systems like [41,4]. In
Petri net-based approaches [46] the states of a system are modeled as sets or
multi-sets. These formalisms have been quite successful in modeling relevant
aspects of software systems, and they have developed a large body of theory
which can aid the developer in structuring, understanding, and verifying her
specifications.
Still, we believe that graphs and graph transformation are indispensable
means for providing an operational, conceptual and formal framework for today’s software development. First, the states of object-oriented, distributed, and
mobile systems are most naturally represented as graphs modeling, e.g., object
structures, software architectures, network topologies, etc. Then, for describing
changes to these states like the insertion or deletion of objects or links, architectural or network reconfiguration, graphs have to be manipulated. Second, in
diagrammatic modeling languages, the abstract syntax of an individual model
is usually represented as a graph instead of a term or tree as in (textual) programming languages. Thus, for translating one diagram language into another,
for defining the semantics of diagrams by reducing them to a normal form or by
animating them, graph-based techniques are needed where, in the case of textual
languages, term rewrite systems or SOS specifications may be used.
In this paper, we will be interested in the first issue of interpreting graphs
as states and graph transformation systems as “programs”. The second idea of
graphs as representing diagrams and graph transformation systems defining their
operational semantics is dealt with, for example, in [8,19]. In the next section, we
will discuss a simple application scenario of a distributed and mobile system. This
will serve for identifying the relevant dimensions of a conceptual framework for
expressing structural and behavioral aspects as well as the evolution of today’s
130
G. Engels and R. Heckel
software systems. Based on these investigations, in Sect. 3 we will use graph
transformation systems to formalize our conceptual framework making explicit
the consistency and orthogonality of its different dimensions. We close with a
summary and a discussion of further aspects of software development which are
not covered in the paper.
2
A Conceptual Model for Distributed and Mobile
Application
In this section, we discuss and analyze a concrete application scenario of a distributed system with mobile hardware components in order to identify the relevant concepts and dimensions in modeling such systems. This conceptual model
shall provide the basis for the formal approach developed in Sect. 3.
Our application scenario is (a simplified version of) a distributed system from
the financial domain which uses Java cards (i.e., smartcards with a microprocessor supporting the JavaCard runtime environment [35]) to handle financial
transactions (like the paying of bills) which require the coordination of services
from different providers (e.g., a shop and a bank). A customer possessing such a
smartcard may for instance, after purchasing some goods in a shop, use this card
to download a corresponding bill from a cash box. Later on, she may pay her bills
at a banking terminal. This terminal is one out of several hundreds, connected
via an intranet connection to the mainframe of the bank. Thus, the scenario
involves four different types of hardware components: cash boxes, smartcards,
banking terminals, and mainframes (cf. Fig. 2). Each hardware component has
a processor and memory, and can host and execute software components.
CashBox
MainFrame
SmartCard
BankingTerminal
Fig. 2. Sample application scenario.
Graph Transformation as a Conceptual and Formal Framework
2.1
131
Hierarchical Structures
Fig. 3 shows a snapshot of the hardware architecture of the scenario on a more
abstract level. The diagram depicts five hardware components where the SmartCard component is linked to one of two BankingTerminal components which are
both connected to a MainFrame. The diagram is shown in a UML-like notation
[27], where instances i of class C are represented as i:C (or simply :C if the identity
is not of interest). The boxes are an iconic notation for hardware components
(called nodes) as it is known from UML deployment diagrams.
This hardware architecture forms the base layer of any running software
system. Each node is equipped with some software components, which interact
with each other locally (at one node) or remotely (between different nodes).
These software components form the second layer of a software system.
:CashBox
:MainFrame
hardware links
Intranet
hardware
components
:SmartCard
Intranet
:Banking
Terminal
:Banking
Terminal
Card Interface
Fig. 3. Hardware architecture of the application scenario (snapshot).
The allocation of software components to nodes can be described by UML
deployment diagrams. A sample diagram is shown in Fig. 4 where the SmartCard hosts a BillCard component responsible for accepting a bill issued by the
Billing component of a CashBox as well as for storing this bill and transferring
it to a BankingTerminal for payment. Notice that software components may be
temporarily linked even if they reside on different nodes. A node may also host
several different software components as, for instance, the SmartCard which carries a separate AuthCard component responsible for the authentication of the
card owner.
From a technical point of view, these diagrams are graphs with labeled (and
attributed) vertices and edges. The deployment diagram in Fig. 4 can even be
132
G. Engels and R. Heckel
:CashBox
:Billing
Card Interface
:SmartCard
:BillCard
:AuthCard
Fig. 4. Deployment diagram.
viewed as a kind of hierarchical graph where vertices representing hardware nodes
contain vertices representing software components. Due to the links between
software components running on different nodes, however, this hierarchy is not
strict, as sublayers of different subgraphs may be directly interconnected.
On top of the hardware architecture and component layers, a third layer can
be identified. These are the problem-domain objects (the objects doing the actual work) within software components. Fig. 5 provides an extended deployment
diagram which, in addition, depicts problem-domain objects like the :Bill and
:Customer located within the Billing component.
:CashBox
software
component
processor
:Billing
:Bill
amount = a
Pays
:Customer
problem domain
objects
Fig. 5. Deployment diagram extended by problem-domain objects.
Graph Transformation as a Conceptual and Formal Framework
133
That is, our conceptual framework for system modeling shall be based on
hierarchical graphs where at least three layers have to be distinguished (cf. Fig.
11). Moreover, we often encounter hierarchical structures even within any of
the three layers of objects, software components, and hardware architecture.
This multi-layered hierarchical graph structure forms the first dimension of our
conceptual framework.
2.2
Typed Structures
All diagrams discussed so far have shown individual snapshots of the application
scenario. In the world of programming, this corresponds to a state in the execution of a program which is specified in the program text by means of variables
and types. Analogously, in modeling we also distinguish between an instance and
a type level and demand that the instance level is consistent with the type level.
In the layer of problem-domain objects, the type level is provided by a class
diagram as depicted in Fig. 6. It defines three different classes and their associations where the multiplicity is restricted by appropriate cardinality constraints.
Classes are described by their names and by attribute definitions, whereas instances of a class will have concrete values for these attributes.
Account
balance
*
1 To
*
1 From
*
Bill
amount
*
Has
1
Customer
name
Pays
0..1
Fig. 6. Problem-domain class diagram.
Analogously, the allowed software and hardware architectures on the instance
level may be determined by appropriate type definitions. Type definitions for
software architectures, also called architectural styles [51], determine a set of
admissible concrete architectures. Fig. 7 gives an example for the definition of
hardware architectural style using a hardware diagram on the type level. The
notation is similar to that of the class diagram in Fig. 6 but for the use of
the node icon. The xor-constraint ensures that a SmartCard instance is either
connected to a CashBox or to a BankingTerminal.
Hence, beside the hierarchical structure of the model we have identified a
second, orthogonal dimension of typing. The states of our conceptual model are
134
G. Engels and R. Heckel
MainFrame
CashBox
1
0..1
0..1
SmartCard
*
{xor}
0..1
0..1
Banking
Terminal
Fig. 7. Hardware architecture (type level).
therefore multi-layered, non-strict hierarchical graphs typed over correspondingly structured type graphs.
2.3
Instance Level Dynamics
So far, we have only dealt with the structural aspects of our model. In order to
provide semantics for distributed and mobile applications with dynamic reconfiguration we have to specify operations for transforming this structure.
Dynamic change on the instance level is specified by transformation rules as
shown in Fig. 8. A rule consists of two object diagrams, the left- and the righthand side, where the former specifies the situation before the operation and the
latter the situation afterwards. The rule in Fig. 8 describes the operation of a
customer paying a bill from his account by transferring the required amount to
the specified target account. The transformation of object structures has to be
consistent with the typing in the sense that the constraints on the instance level
imposed by the type-level diagrams are preserved.
The object transformation shown in Fig. 8 can be seen as an abstract requirement specification of the operation payBill disregarding the constraints imposed
by the architectural layer. According to our scenario, Account and Bill objects
originally reside on different nodes. Therefore, the bill has to be transferred from
the cash box to the banking system by means of a SmartCard. The operations
required for downloading the bill onto the card are described in Fig. 9. When
the card is inserted into the cash box’s card reader, a hardware connection is
established. This triggers, after completion of an appropriate authentication protocol, the connection of the Billing with the BillCard component. Then, the bill
is stored in the BillCard component and the customer’s identity is recorded by
the Billing component of the cash box.
As indicated by the identities of the Customer and the Bill objects, these
objects are not simply copied from one component to the other but they are
actually shared after the operation. This is physically impossible, but objectoriented middle-ware like CORBA [28] supports the sharing of objects (as well
as references between objects on different machines) through the concept of
proxies, i.e., local place-holders providing access to remote objects. As conceptual
Graph Transformation as a Conceptual and Formal Framework
:Customer
:Customer
Has
:Account
Pays
Has
payBill(b)
From
balance = x
b:Bill
amount = a
:Account
balance = y
135
To
:Account
balance =
x−a
:Account
balance =
y+a
Fig. 8. Object transformation rule.
framework for the application developer, our model should provide features (at
least) on the same level of abstraction as offered by state-of-the-art programming
technology. Of course, in order to allow for sharing on the instance level, also on
the type level it must be possible to share classes between different components
types.
Notice that we have described dynamic changes within all three layers of our
hierarchy and all but the first transformation are concerned with two layers at
the same time. Thus, not only the states of our systems are hierarchical, but
also the operations have to take care of the hierarchical structure, as they are
potentially not restricted to a single layer.
2.4
Type Level Evolution
The last point to be discussed in this section is the difference between the dynamic change on the instance level as described above and the evolution of the
system by changes on the type level. As systems have to be adapted to new
requirements, not only their configuration may change, but also it may be necessary to introduce new types of hardware or to deploy new software components
containing objects of classes which have not been known before.
In our application scenario, a new component CashCard is downloaded on
the card in order to provide the additional service of using the card directly
for paying bills at a cash box. A corresponding Cashing component is needed
at cash boxes while banking terminals have to provide a CashCardService to
transfer virtual money to the card. On the hardware level, the evolution consists
in establishing a new kind of hardware connection in order to transfer bills from
the cash box to the banking system via the internet. The new types are shown
in the diagram of Fig. 10.
136
G. Engels and R. Heckel
:CashBox
:CashBox
insertCard
:SmartCard
:SmartCard
:CashBox
Billing
:CashBox
connect
Components
Billing
:SmartCard
:SmartCard
BillCard
BillCard
:Billing
:Billing
b :Bill
b :Bill
amount = a
amount = a
c:Customer
Pays
name = n
transferBill
:BillCard
:BillCard
b :Bill
amount = a
c:Customer
c:Customer
name = n
name = n
Pays
Fig. 9. Transformation of the instance level hierarchy.
Graph Transformation as a Conceptual and Formal Framework
137
Internet
MainFrame
CashBox
Cashing
BankingSystem
Billing
Intranet
CardInterface
BankingTerminal
SmartCard
BillCard
BillCardService
AuthCard
AuthCardService
CashCard
CashCardService
CardInterface
Fig. 10. Evolution of hardware and software architecture.
The overall framework is summarized in Fig. 11. It distinguishes between an
instance level and a type level. Within each level, a hierarchical structure of three
layers can be identified. For instance on the instance level, we have the problemdomain objects on the first layer, which are distributed over a component-based
software architecture on the second layer, where software components are spread
over a network of hardware components on the third layer. Orthogonally to
these two dimensions of typing and hierarchical structures, we consider, as a
third dimension, the dynamic change on the instance level and the evolutionary
change on the type level, both in all of the three layers. The formalization and
consistent integration of these three dimensions is the subject of the next section.
3
Formalizing the Conceptual Model
with Graph Transformation Systems
In Sect. 2, we have analyzed the structures relevant for the modeling of distributed and mobile applications. In retrospect, in a single model we can identify the three dimensions of typing, dynamic and evolutionary change, and of the
hierarchy of objects, software and hardware components. In this section, these
three dimensions as well as their interdependencies shall be formalized.
We build upon concepts from the theory of graph transformation systems
which focus on the specification of systems where states are represented as graphs
and changes are specified by transformation rules (thus dynamic change is already present). Surveys on the state-of-the-art of theory and application of graph
138
G. Engels and R. Heckel
instance level
type level
problem− domain objects
problem− domain model
instanceOf
layers
component− based
software architecture
software architectural style
instanceOf
network of processors
hardware architectural style
instanceOf
Fig. 11. Instance and type level as well as the three-layered hierarchy of system models.
transformation can be found in the three handbook volumes [47,14,16]. A good
introductory text is [1].
Among the various formalizations of graph transformation, the “algebraic,
Double PushOut (DPO) approach” [18,10] is one of the most successful, mainly
because of its flexibility. In fact, since the basic definitions of rule and transformation are based on diagrams and constructions in a category, they can be
used in a uniform way for a wide range of structures. Therefore, many results
can be proved once and for all using categorical techniques [17]. This flexibility
shall be exploited in the following in order to augment the original formalism
[18] with several levels of typing (in the spirit of the typed DPO approach [9]),
thus representing the hierarchy within a model and its evolution on the type
level.
3.1
Object Dynamics as Typed Graph Transformation
In this section, we are going to provide the formal semantics of the dynamic
change at the instance level conceptually discussed in Sect. 2.3. This includes
the concepts of typing as described in Sect. 2.2 as well as the transformation of
instances in a type-consistent way.
Graphs and typed graphs. The relation between diagrams on the type level and
diagrams on the instance level is formally captured by the concept of type and
instance graphs [9].
By graphs we mean directed unlabeled graphs G = hGV , GE , srcG , tarG i
with set of vertices GV , set of edges GE , and functions srcG : GE → GV and
tarG : GE → GV associating with each edge its source and target vertex. A
graph homomorphism f : G → H is a pair of functions hfV : GV → HV , fE :
GE → HE i preserving source and target, that is, srcH ◦fE = fV ◦srcG and tarH ◦
Graph Transformation as a Conceptual and Formal Framework
139
fE = fV ◦ tarG . The category of graphs and graph morphisms with composition
and identities defined componentwise on the underlying functions is denoted by
Graph.
Definition 1 (typed graphs). Given a graph T G, called type graph, a T Gtyped (instance) graph consists of a graph G together with a typing homomorphism g : G → T G associating with each vertex and edge x of G its type g(x) = t
in T G. In this case, we also write x : t ∈ G. A T G-typed graph morphism between
two T G-typed instance graphs hG, gi and hH, hi is a graph morphism f : G → H
which preserves types, that is, h ◦ f = g. The category of all instance graphs
typed over T G is denoted by GraphT G .
f
G
g
TG
+
GC
H
CC
{
{
CC
{
{
g CCC
{{
! }{{ h
TG
Categorically speaking, GraphT G is the comma category (Graph ↓ T G) of
graphs over T G (see, e.g., [40]). This observation allows to inherit categorical
constructions from Graph to GraphT G . In particular, since the category of
graphs has all limits and colimits, the comma category GraphT G has all limits
and colimits as well, and their constructions coincide in Graph and GraphT G
up to the additional typing information.
Example 1 (type and instance graphs). Fig. 12 shows the class diagram of Fig. 6
as a type graph, as well as a corresponding instance graph. We use the UMLlike notation vertex:type for specifying instance graphs and their typing. The
name of the vertex may be omitted in which case the diagram represents an
isomorphism class of graphs. We do not formally deal with attributes in this
paper. For approaches to the transformation of attributed graphs the reader is
referred to [48,39,5].
Typed graph transformations. The DPO approach to graph transformation has
originally been developed for vertex- and edge-labeled graphs [18]. Here, we
present immediately the typed version [9].
According to the DPO approach, graph transformation rules (also called
l
graph productions), are specified by pairs of injective graph morphisms (L ←−
r
K −→ R), called rule spans. The left-hand side L contains the items that must be
present for an application of the rule, the right-hand side R those that are present
afterwards, and the context graph K specifies the “gluing items”, i.e., the objects
which are read during application, but are not consumed. The transformation
of graphs is defined by a pair of pushout diagrams, a so-called double pushout.
Definition 2 (DPO graph transformation). Given a type graph T G, a T Gtyped graph transformation rule is a pair p : s consisting of a rule name p and a
l
r
rule span s = (L ←− K −→ R).
140
G. Engels and R. Heckel
Instance graph G
:Customer
Type graph TG
name = Al
Has
Account
balance
To
Pays
Bill
amount
:Account
Typing
hom. g
From
b:Bill
amount = 3
Has
Customer
name
From
balance = 5
:Account
Pays
balance = 0
Has
To
:Customer
name = Tim
Fig. 12. Type and instance graph.
A double-pushout (DPO) diagram o is a diagram like below where (1) and
(2) are pushouts. Given a rule p : s like above the corresponding (direct DPO)
p/o
transformation from G to H is denoted by G =⇒ H.
l
r
/R
K
Lo
oL
Go
(1)
g
oK (2)
D
h
oR
/H
The DPO diagram o is a categorical way of representing the occurrence of a
rule in a bigger context. Assuming a simpler representation of rules, the same
situation can also be expressed in a more set-theoretic way. In fact, a graph
transformation rule can be represented (up to renaming) as a pair of graphs
with rule name p : L → R such that the union L ∪ R is defined (i.e., graphs L
and R live in the same name space). The span representation can be recovered
as p : L ←- L ∩ R ,→ R. That is, given that L ∪ R is defined, the interface graph
K, which is needed in the categorical setting for specifying the sharing between
L and R, can be reconstructed and is therefore omitted.
Then, a direct transformation from G to H (with G ∪ H defined) using rule
p : L → R is given by a graph morphism o : L ∪ R → G ∪ H, called occurrence,
such that
– o(L) ⊆ G and o(R) ⊆ H, i.e., the left-hand side of the rule is embedded into
the pre-state and the right-hand side into the post-state
Graph Transformation as a Conceptual and Formal Framework
141
– o(L \ R) = G \ H and o(R \ L) = H \ G, i.e., exactly that part of G is deleted
which is matched by elements of L not belonging to R and, symmetrically,
that part of H has been added which is matched by elements new in R.
Like in the categorical definition, the resulting graph H is only determined up
to isomorphism by the rule p : L → R and the occurrence oL : L → G.
Example 2 (typed graph transformation). Fig. 13 shows the span representation
of the object transformation rule of Fig. 8 as well as its application to the instance
graph in Fig. 12. Operationally speaking, the application of the rule proceeds
as follows. Given the occurrence oL of the left-hand-side in the given graph G
determined by the mapping of the b:Bill vertex, the application consists of two
steps: The objects of G matched by L \ l(K) are removed which leads to the
graph D without the bill. Then, the objects matched by R \ r(K) are added to
D leading to the derived graph H.
Gluing the graphs L and D over their common part K yields again the given
graph G, i.e., the left-hand square (1) forms a so-called pushout complement.
Only in this case the application is permitted. Similarly, the derived graph H is
the gluing of D and R over K, which forms the right-hand side pushout square
(2).
The same rewrite mechanism is used for the update of attributes: In order
change an attribute value, the attribute is deleted and re-generated with the new
value.
The formalization of deletion as “inverse gluing” implies that the application
of a rule can be described as an embedding of K = L ∩ R into a context by
means of the occurrence morphism oK : K → D (cf. Fig. 13). This implies that
only vertices in the image of L ∩ R can be merged or connected to edges in the
context. These observations are reflected, respectively, in the identification and
the dangling condition of the DPO approach which characterize, given a rule
l
r
p : (L ←− K −→ R) and an occurrence oL : L → G of the left-hand side,
the existence of the pushout complement (1), and hence of a direct derivation1
p/o
G =⇒ H. The identification condition states that objects from the left-hand side
may only be identified by the match if they also belong to the interface (and are
thus preserved). The dangling condition ensures that the structure D obtained
by removing from G all objects that are to be deleted is indeed a graph, that is,
no edges are left “dangling” without source or target node.
In this way, the DPO construction ensures the consistency of the transformation with the graph structure. Type consistency is ensured by the fact that
the transformation rules themselves are well-typed. Together with the typing of
the given graph G this induces the typing of the derived graph H.
1
The pushout (2) always exists since category GraphTG is cocomplete due to the
cocompleteness of Graph.
142
G. Engels and R. Heckel
K
R
:Customer
:Customer
L
:Customer
Has
Pays
:Account
Has
l
From
Has
:Account
r
balance = x
b:Bill
amount = a
:Account
:Account
balance = y
:Account
balance =
y+a
To
oK
oL
oR
:Customer
:Customer
name = Al
name = Al
:Customer
name = Al
Has
Has
Has
Pays
:Account
:Account
From
balance = 5
b:Bill
amount = 3
:Account
balance = 0
Has
:Account
balance =
x−a
g
:Account
h
:Account
balance = 2
:Account
balance = 3
To
Has
Has
:Customer
:Customer
name =Tim
name =Tim
:Customer
name =Tim
G
D
H
Fig. 13. DPO graph transformation step.
3.2
Hierarchical Structures as Aggregated Graphs
In Sect. 2.3, we have pointed out the requirements for modeling the dynamic
change of the instance level hierarchy consisting of the object, software and
hardware component layers where, in general, each of these layers may be again
hierarchical. It has been observed that these hierarchies are not strict (neither on
the type nor on the instance level) in the sense that vertical sharing is allowed,
i.e., the refinement relation forms a directed acyclic graph (DAG) rather than a
tree. In this section, we outline an approach to formalize the transformation of
such structures.
Hierarchical graphs and their transformation have received much attention
in the graph transformation literature. The first formal account we are aware of
is [45]. Close to the conceptual model outlined in Sect. 2.1 is the approach of
Graph Transformation as a Conceptual and Formal Framework
143
distributed graph transformation [52]. Distributed graphs are hierarchical graphs
with two layers only. Formally, they are diagrams in the category of graphs. That
means, a graph G representing the network topology is attributed with graphs
and graph morphisms modeling, respectively, the object structures contained in
the local components and relationships between them. The transformation of
these graphs is based on the double-pushout approach. As distributed graphs
also allow sharing of objects between different components, they would be a
natural candidate for formalizing our hierarchical models. However, they are
restricted to hierarchies of depth two (although the construction of diagrams in
the category of graphs could be iterated).
A new approach towards hierarchical graph transformation based on the
DPO transformation of hypergraphs (see, e.g., [13]) which allows hierarchical
graphs of arbitrary finite depth is proposed in [12]. Conceptually, hyperedges in
this approach represent components which contain other hypergraphs, and the
attachment vertices of a hyperedge represent ports through which the components are connected. The drawback of this approach from our point of view is
its limitation to strict, tree-like hierarchies without vertical sharing.
More general concepts of hierarchical graphs allowing both vertical sharing
and multiple-layered structures have been proposed, for example, in [21,6] but
neither of them formally accounts for the transformation of these graphs. Summarizing, none of the approaches we are aware of satisfies all the requirements
of Sect. 2 although many approaches contribute to some aspect of the overall
problem.
Instead of extending the underlying formalism as it is done in most approaches, we propose to model hierarchical graphs with vertical sharing by aggregated graphs, i.e., graphs with distinguished aggregation edges representing
the refinement of vertices. This approach has the advantage of preserving the
theoretical results and semantic properties of the basic typed graph transformation approach. In particular, the concurrent semantics in terms of concurrent
traces, graph processes, and event structures (see [2] for a recent survey) is relevant to our aim of developing a formal model for distributed and mobile systems.
For distinguishing between aggregation edges and ordinary edges in both
type and instance graphs, we introduce an additional level of typing, the meta
type level. In the meta type graph T G0 in Fig. 14 on the left two kinds of
edges are defined: ordinary edges and aggregation edges with a diamond head
designating the super-vertex. Since there is only one node representing all kinds
of vertices, T G0 is the most general type graph serving our purpose. It could be
further refined by separating the three layers of objects, software and hardware
components as shown in the same figure on the right. In fact, since the graph
T G1 on the right is itself typed over T G0 , it could be used to provide another
level of typing (that we omit for the sake of simplicity). An analogous approach
can be found in the standardization of the UML by the OMG [27] based on the
Meta Object Facility [26], a meta modeling framework which provides four levels
of typing.
144
G. Engels and R. Heckel
Node
Vertex
Component
TG
0
Class
TG1
Fig. 14. Meta type graphs.
Thus, graphs typed over T G0 represent graphs with aggregation edges. Since
the genuine type level is still missing, typed graphs with aggregation edges are
defined by replacing in Definition 1 the category of graphs and graph morphisms
with the category GraphT G0 of T G0 -typed graphs. Given a T G0 -typed graph
hT G, tg0 : T G → T G0 i representing a type graph with aggregation edges, we
build the comma category GraphT G0 ↓ hT G, tg0 i of T G0 -typed graphs over
hT G, tg0 i. Objects of this category are graphs with two levels of typing compatible with the typing of T G as represented by the commutative diagram below
on the left.
f
g
/ TG
GD
DD
DD
tg0
D
g0 DD
! T G0
(
G D g / TG o h
H
DD
z
z
DD
z
tg0 zz
D
z
g0 DD
! }zz h0
T G0
A morphism of hT G, tg0 i-typed graphs hG, gi and hH, hi is a graph morphism f
such that the diagram above on the right commutes. In particular, notice that
both the meta type graph T G0 and the type graph hT G, tg0 i remain fixed, i.e.,
the only variation allowed is on the level of instances.
Example 3 (typed graph with aggregation). Fig. 15 shows a type graph with aggregation edges which is itself an instance of the meta type graph T G1 in Fig. 14.
Notice the vertical sharing of the classes Customer and Bill between the Billing
and BillCard components as well as the link between the two components contained in different nodes.
The transformation of hT G, tg0 i-typed graphs is defined by replacing in Definition 2 the category GraphT G for a given type graph T G with the category
GraphT G0 ↓ hT G, tg0 i for a given T G0 -typed type graph hT G, tg0 i. Due to
the notion of morphism, the transformation is restricted to the instance level
while the type level remains static. Notice again that the use of a comma category does not only allow us to inherit the categorical structure relevant for the
Graph Transformation as a Conceptual and Formal Framework
145
SmartCard:Node
CashBox:Node
BillCard:Component
Billing:Component
Customer:Class
Bill:Class
Pays
Fig. 15. A type graph with aggregation edges.
definition of transformation, but also to reestablish most theoretical results of
double-pushout graph transformation.
Example 4 (graph transformation rule with aggregation). A graph transformation rule conforming to the type graph of Fig. 15 is shown in Fig. 16. It represents
the formal counterpart of the lower rule transferBill in Fig. 9 (the context graph
is omitted). Here, the sharing of Bill and Customer between the Billing and the
BillCard components, which has been noted already in the type graph, occurs on
the level of instance graphs in the right-hand side of the rule rule.
Although the concept of meta typing allows us to represent graphs with aggregation edges, additional constraints are required in order to exclude meaningless
structures. In particular, we have to require the acyclicity of aggregation edges
in the instance level graphs. Thus, given a T G0 -typed type graph hT G, tg0 i, an
aggregated graph is a hT G, tg0 i-typed instance graph such that the aggregation
edges form a directed acyclic graph. Further, an aggregated graph transformation rule is a rule in GraphT G0 ↓ hT G, tg0 i which does not introduce a new
:BillCard
:BillCard
:Billing
transferBill
c:Customer
b:Bill
Pays
:Billing
c:Customer
b:Bill
Pays
Fig. 16. Graph transformation rule with aggregation.
146
G. Engels and R. Heckel
aggregation edge between two already existing vertices. This is enough to show
that the application of a rule on an aggregated graph yields again an aggregated
graph (i.e., it does not create cycles of aggregation edges), thus ensuring the
consistency between dynamic change and hierarchical structure.
Of course, other constraints may be added, for example, about the connections allowed between graphs within different nodes or between different layers
of the hierarchy (see, e.g., [21]). Such constraints, however, are highly application dependent and they should not be part of the basic formalism. Instead,
a constraint language is required for specifying such constraints and verifying
the consistency of rules. The most prominent logical approach for specifying
graph properties [11] is based on second-order monadic logic. In contrast to the
first-order case, this allows the specification of path properties like the acyclicity
constraints mentioned above. A less powerful formalism for expressing integrity
constraints which is based on a graphical notation has been introduced in [33].
3.3
Model Evolution through Type Level Transformation
In the previous section, we have used meta typing in order to distinguish ordinary
and aggregation edges representing refinement in hierarchical graphs. We have
pointed out that, due to the notion of morphism between graphs with two levels
of typing, the transformation is restricted to the instance level while the type
level remains static. In this section, it is our aim to extend the transformation
to the type level. To this aim, we provide another construction of graphs with
two-level typing which yields the same notion of graphs but a more flexible kind
of morphism.
An arrow category C→ in a given category C has arrows a : A → A0 of C
as objects. A morphism between a : A → A0 and b : B → B 0 is a pair of arrows
hf, f 0 i in C such that the square below on the right commutes.
A
a
A0
A
f
a
A0
/B
b
f0
/ B0
The arrow category Graph→ over the category of graphs has graph morphisms
as objects. We may think of them as typing morphisms from instance graphs
to type graphs. With this intuition, morphisms of Graph→ consist of graph
morphisms both on the instance and the type level thus allowing the variation
of types as required for evolutionary change.
In order to preserve the hierarchical structure established through meta typing and to provide some control on the transformation of types, we build the
arrow category over the category of T G0 -typed graphs. Thus, objects of this
category are arrows in GraphT G0 like below on the left, and arrows are pairs of
Graph Transformation as a Conceptual and Formal Framework
147
arrows hfI , fT i in GraphT G0 as shown on the right:
fI
g
/ TG
GD
DD
DD
tg0
D
g0 DD
! T G0
G
g
/ TG
/ TH o
FF
FF tg0 fT th0 xxx
FF
x
FF
xx
g0
"+
|xsx
h0
T G0
h
+
H
Now we can define our ultimate notion of transformation, catering for hierarchical structures as well as for type-level evolution, by replacing the category of
T G-typed graphs in Definition 2 with the category Graph→
T G0 .
Transformation rules in this setting consist of two-level graphs. They modify
consistently the type and the instance level. The consistency between the two
levels of transformation and the meta typing realizing the hierarchical structure
is implicit in the commutativity of the above diagrams.
A more general approach to system evolution has been presented in [38]. In
addition to the evolution of type graphs, in [38] also the transformation rules
specifying dynamic change may be modified by application of higher-level evolution rules. Thus, unlike in our approach, dynamic change and evolution form
orthogonal dimensions.
4
Conclusion
In this paper, we have proposed a conceptual framework for mobile and distributed applications. Three orthogonal dimensions of such systems have been
identified: A multi-layered, non-strict hierarchical graph structure, the typing of
instance graphs over type graphs, and the dynamic and evolutionary change
occurring, respectively, on the instance and the type level. This conceptual
framework is formalized using concepts of graph transformation, in particular, typed graph transformation systems according to the categorical doublepushout (DPO) approach [18,9] and hierarchical graphs. The use of categorical
constructions like comma categories allows us to express the orthogonality and
consistency of the three dimensions while inheriting many theoretical results.
Our framework does not yet cover all important aspects of software development. Some of these aspects have been investigated in the graph transformation
literature for simpler kinds of systems (e.g., without typing or hierarchical structure). In particular, the software development process with its different phases
of analysis, design, and implementation and the refinement steps between these
phases are subject of ongoing research (see, e.g., [29,25,37,53]). Horizontal structuring techniques for models and programs like modules, views, or packages have
been studied, for example, in [31,30,32,49]. In order to support the transition
from design to implementation, high-level programming and modeling languages
based on graph transformation are developed (see, e.g., [23,50,22]).
Most of these approaches are neither consistent nor strictly orthogonal to
the conceptual framework presented her. It remains future work to identify the
148
G. Engels and R. Heckel
relation between the various concepts and to incorporate them into a consistent
overall model of software development.
Acknowledgment
The authors are grateful to Stefan Sauer for fruitful comments on earlier versions
of this article.
References
1. M. Andries, G. Engels, A. Habel, B. Hoffmann, H.-J. Kreowski, S. Kuske,
D. Plump, A. Schürr, and G. Taentzer. Graph transformation for specification
and programming. Science of Computer Programming, 34:1–54, 1999.
2. P. Baldan, A. Corradini, H. Ehrig, M. Löwe, U. Montanari, and F. Rossi. Concurrent semantics of algebraic graph transformation. In Ehrig et al. [16].
3. J.A. Bergstra and J.W. Klop. Process algebra for synchronous communication.
Information and Control, 60(1–3):109 – 137, 1984.
4. G. Berry and G. Boudol. The chemical abstract machine. Theoret. Comput. Sci.,
96(1):217–248, 1992.
5. M.R. Berthold, I. Fischer, and Koch. M. Attributed graph transformation with
partial attribution. In H. Ehrig and G. Taentzer, editors, Joint APPLIGRAPH and
GETGRATS Workshop on Graph Transformation Systems (GraTra2000). Tech.
Univ. of Berlin, March 2000. Tech. Report 2000-2, Dept. of Comp. Sci.
6. G. Busatto, G. Engels, K. Mehner, and A. Wagner. A framework for adding
packages to graph transformation approaches. In Ehrig et al. [15].
7. Microsoft Corp. Distributed component object model protocol – DCOM, V 1.0,
1998. http://www.microsoft.com/com/tech/dcom.asp.
8. A. Corradini, R. Heckel, and U. Montanari. Graphical operational semantics.
In Proc. ICALP2000 Workshop on Graph Transformation and Visual Modelling
Techniques, Geneva, Switzerland. Carleton Scientific, July 2000.
9. A. Corradini, U. Montanari, and F. Rossi. Graph processes. Fundamenta Informaticae, 26(3,4):241–266, 1996.
10. A. Corradini, U. Montanari, F. Rossi, H. Ehrig, R. Heckel, and M. Löwe. Algebraic
approaches to graph transformation, Part I: Basic concepts and double pushout
approach. In Rozenberg [47].
11. B. Courcelle. The expression of graph properties and graph transformations in
monadic second-order logic. In Rozenberg [47].
12. F. Drewes, B. Hoffmann, and D. Plump. Hierarchical graph transformation.
In J. Tiuryn, editor, Foundations of Software Science and Computation Structures (FoSSACS’00), Berlin, Germany, volume 1784 of LNCS. Springer Verlag,
March/April 2000.
13. F. Drewes, H.-J. Kreowski, and A. Habel. Hyperedge replacement graph grammars.
In Rozenberg [47].
14. H. Ehrig, G. Engels, H.-J. Kreowski, and G. Rozenberg, editors. Handbook of
Graph Grammars and Computing by Graph Transformation, Volume 2: Applications, Languages, and Tools. World Scientific, 1999.
15. H. Ehrig, G. Engels, H.-J. Kreowski, and G. Rozenberg, editors. Proc. 6th
Int. Workshop on Theory and Application of Graph Transformation (TAGT’98),
Paderborn, November 1998, volume 1764 of LNCS. Springer Verlag, 2000.
Graph Transformation as a Conceptual and Formal Framework
149
16. H. Ehrig, H.-J. Kreowski, U. Montanari, and G. Rozenberg, editors. Handbook of
Graph Grammars and Computing by Graph Transformation, Volume 3: Concurrency and Distribution. World Scientific, 1999.
17. H. Ehrig and M. Löwe. Categorical principles, techniques and results for highlevel replacement systems in computer science. Applied Categorical Structures,
1(1):21–50, 1993.
18. H. Ehrig, M. Pfender, and H.J. Schneider. Graph grammars: an algebraic approach.
In 14th Annual IEEE Symposium on Switching and Automata Theory, pages 167–
180. IEEE, 1973.
19. G. Engels, J.H. Hausmann, R. Heckel, and St. Sauer. Dynamic meta modeling: A
graphical approach to the operational semantics of behavioral diagrams in UML.
Submitted.
20. G. Engels, R. Heckel, and St. Sauer. UML - A universal modeling language? In
Proc. 21st Int. Conference on Application and Theory of Petri Nets (Petri Nets
2000), Aarhus, Denmark, LNCS. Springer Verlag, June 2000. To appear.
21. G. Engels and A. Schürr. Hierarchical graphs, graph types and meta types. Proc.
of SEGRAGRA’95 ”Graph Rewriting and Computation”, Electronic Notes of TCS,
2, 1995. http://www.elsevier.nl/locate/entcs/volume2.html.
22. C. Ermel, M. Rudolf, and G. Taentzer. The AGG approach: Language and tool
environment. In Engels et al. [14].
23. T. Fischer, J. Niere, L. Torunski, and A. Zündorf. Story diagrams: A new graph
transformation language based on UML and Java. In Ehrig et al. [15].
24. C. Ghezzi, M. Jazayeri, and D. Mandrioli. Fundamentals of Software Engineering.
Prentice Hall Int., 1991.
25. M. Große-Rhode, F. Parisi Presicce, and M. Simeoni. Refinement of graph transformation systems via rule expressions. In Ehrig et al. [15].
26. Object Management Group. Meta object facility (MOF) specification, 1999.
http://www.omg.org.
27. Object Management Group. OMG Unified Modeling Language Specification, V
1.3, 1999. http://www.omg.org.
28. The Object Management Group. The common object request broker: Architecture
and specification, v. 3.0, 2000. http://www.omg.org.
29. R. Heckel, A. Corradini, H. Ehrig, and M. Löwe. Horizontal and vertical structuring
of typed graph transformation systems. Math. Struc. in Comp. Science, 6(6):613–
648, 1996.
30. R. Heckel, G. Engels, H. Ehrig, and G. Taentzer. Classification and comparison of
modularity concepts for graph transformation systems. In Engels et al. [14].
31. R. Heckel, G. Engels, H. Ehrig, and G. Taentzer. A view-based approach to system
modelling based on open graph transformation systems. In Engels et al. [14].
32. R. Heckel, B. Hoffmann, P. Knirsch, and S. Kuske. Simple modules for grace. In
Ehrig et al. [15].
33. R. Heckel and A. Wagner.
Ensuring consistency of conditional
graph grammars – a constructive approach.
Proc. of SEGRAGRA’95
”Graph Rewriting and Computation”, Electronic Notes of TCS, 2, 1995.
http://www.elsevier.nl/locate/entcs/volume2.html.
34. C.A.R. Hoare. Communicating Sequential Processes. Prentice-Hall, 1985.
35. Sun Microsystems Inc.
Java card applet developer’s guide.
http://java.sun.com/products/javacard21.html, 1998.
36. Sun
Microsystems
Inc.
Java
remote
method
invocation.
http://java.sun.com/products/jdk/rmi, 1998.
150
G. Engels and R. Heckel
37. C.-A. Krapp, S. Krüppel, A. Schleicher, and B. Westfechtel. UML packages for
PROgrammed Graph REwrite Systems. In Ehrig et al. [15].
38. M. Löwe. Evolution patterns. Postdoctoral thesis, Technical University of Berlin.
Tech. Report 98-4, Dept. of Comp. Sci, 1997.
39. M. Löwe, M. Korff, and A. Wagner. An algebraic framework for the transformation
of attributed graphs. In M.R. Sleep, M.J. Plasmeijer, and M.C. van Eekelen,
editors, Term Graph Rewriting: Theory and Practice, chapter 14, pages 185–199.
John Wiley & Sons Ltd, 1993.
40. S. Mac Lane. Categories for the Working Mathematician, volume 5 of Graduate
Texts in Mathematics. Springer, New York, 1971.
41. J. Meseguer. Conditional rewriting logic as a unified model of concurrency. Theoret.
Comput. Sci., 96:73–155, 1992.
42. R. Milner. Communication and Concurrency. Prentice-Hall, 1989.
43. R. Milner, J. Parrow, and D. Walker. A calculus of mobile processes. Information
and Computation, 100:1–77, 1992.
44. G. Plotkin. A structural approach to operational semantics. Technical Report
DAIMI FN-19, Aarhus University, Computer Science Department, 1981.
45. T.W. Pratt. Definition of programming language semantics using grammars for
hierarchical graphs. In H. Ehrig, V. Claus, and G. Rozenberg, editors, 1st Int.
Workshop on Graph Grammars and their Application to Computer Science and
Biology, LNCS 73, volume 73 of LNCS. Springer Verlag, 1979.
46. W. Reisig. Petri Nets, volume 4 of EATCS Monographs on Theoretical Computer
Science. Springer Verlag, 1985.
47. G. Rozenberg, editor. Handbook of Graph Grammars and Computing by Graph
Transformation, Volume 1: Foundations. World Scientific, 1997.
48. H.-J. Schneider. On categorical graph grammars integrating structural transformation and operations on labels. Theoret. Comput. Sci., 109:257 – 274, 1993.
49. A. Schürr and A.J. Winter. UML packages for PROgrammed Graph REwrite
Systems. In Ehrig et al. [15].
50. A. Schürr, A.J. Winter, and A. Zündorf. The PROGRES approach: Language and
environment. In Engels et al. [14].
51. M. Shaw and D. Garlan. Software Architecture: Perspectives on an Emerging
Discipline. Prentice Hall, 1996.
52. G. Taentzer, I. Fischer, M. Koch, and V. Volle. Distributed graph transformation
with application to visual design of distributed systems. In Ehrig et al. [16].
53. Andreas Zamperoni and Gregor Engels. Formal integration of software engineering
aspects using graph rewrite systems - a typical experience?! In A. Schürr M. Nagl,
editor, Proc. Applications of Graph Transformations With Industrial Relevance
(AGTIVE), Kerkrade (The Netherlands), September 1–3, 1999, LNCS. Springer
Verlag, 2000. To appear.