December 14, 2010 10:3 WSPC/117-IJSEKE

S0218194010004918

SPI-J111

0218-1940

International Journal of Software Engineering

and Knowledge Engineering
Vol. 20, No. 5 (2010) 679694
c World Scientic Publishing Company


DOI: 10.1142/S0218194010004918

FORMAL ANALYSIS OF UML 2.0 ACTIVITIES

USING GRAPH TRANSFORMATION SYSTEMS

VAHID RAFE, , ADEL T. RAHMANI, and REZA RAFEH,

Department

of Computer Engineering
Arak University, Arak, Iran

Department of Computer Engineering

Iran University of Science and Technology
Tehran, Iran
v-rafe@araku.ac.ir
rahmani@iust.ac.ir
r-rafeh@araku.ac.ir

Received 26 January 2008

Revised 20 July 2009
Accepted 11 August 2009
Graph transformation is a general visual modeling language which is suitable for stating
the dynamic semantics of the designed models formally. We present a highly understandable yet precise approach to formally dene the behavioral semantics of UML 2.0 Activity
diagrams by using graph transformation. In our approach we take into account control
ow and data ow semantics. Our proposed semantics is based on token-like semantics
and traverse-to-completion. The main advantage of our approach is automated formal
verication and analysis of UML Activities. We use AGG to design Activities and we use
our previous approach to model checking graph transformation system. Hereby, designers can verify and analyze designed Activity diagrams. Since workow modeling is one of
the main application areas of the Activities, we use our proposed semantics for modeling
and verication of workows to illustrate our approach.
Keywords: Activity diagram; graph transformation; verication; dynamic semantics;
AGG.

1. Introduction
UML Activity diagram is a useful modeling tool for dynamic parts of a system. It
allows specifying workows as well as modeling of complex and large processes [1].
It is also used to model the behavior of a system and to specify the global behavior
of a Service-Oriented Architecture (SOA) [2]. However, to let the user understand
whether the designed model fullls the stated requirements, we need to combine
modeling with suitable analysis capabilities. Precise analysis in an automated way
requires design models like Activities to be stated with a formal language (i.e. a
language with a precise semantics).
679

December 14, 2010 10:3 WSPC/117-IJSEKE

S0218194010004918

680

SPI-J111

0218-1940

V. Rafe, A. T. Rahmani & R. Rafeh

Unied Modeling Language (UML) is a standard modeling language to express

models in a software development process. Nonetheless, UML only denes syntax
for modeling without a precise formal semantics. Using formal methods is crucial
for automated software engineering. However, the main problem of formal methods
is that they are dicult to understand because of their complex mathematics.
Our aim is to implement a precise semantics based on UML 2.0 specication
[3] yet easily understandable for UML 2.0 Activities using graph transformation
systems [4, 5].
Graph transformation has recently become more and more popular as a general
formal modeling language. Most of the means used by software engineers are nothing
but suitable annotated graphs. Graphs have proven their usefulness in everyday
software engineering such as software architectures, class diagrams, and version
histories. Graph transformation systems are used to describe the models and to
formalize their syntax and to dene the formal semantics of used notations [6].
Our motivation for choosing graph transformation as a semantic background for
modeling Activities was the natural formalism of such systems for languages which
basically are graphs.
Our work is based on the approach presented in [7]. In this paper, we present
an innovative approach to analyze Activities modeled by graph transformation
system using model checking. Based on this approach, the transition system must
be generated following our dened semantics. In the generated transition system
states are graphs representing the current state of the Activity. By using this graph
we can check specied properties of the model (e.g. via temporal logics interpreted
on the transition system). We use AGGa toolset [8] to implement semantics of UML
2.0 Activity diagrams. AGG allows dening desired constraints using atomic constraints. Since AGG is unable to generate transition systems, we use our previous
approach for generating transition systems and model checking [911]. Graph transformation systems designed in AGG are translated to BIR (Bandera Intermediate
Language) the input language of Bogorb model checker [12]. Bogor generates the
transition system and checks desired properties stated by LTL (Linear Temporal
Logic). The translation process is completely automatic allowing designers to use
this approach without any knowledge about BIR or Bogor.
As it was mentioned before, workflow modeling is one of the main application areas of the Activities. Therefore, we use our proposed semantics of UML 2.0
Activity diagrams for modeling workows. To verify the correctness of workows,
we consider several crucial properties of Activities modeling workows. We explain
how our proposed semantics can be automatically used to verify workows. In contrast to previous approaches [13, 14], our proposed semantics supports concepts
dened in UML 2.0 Activities (e.g. Petri-like semantics and traverse-to-completion).
In addition, our approach supports more elements of Activities (e.g. exception
a http://tfs.cs.tu-berlin.de/agg/
b http://bogor.projects.cis.ksu.edu/

December 14, 2010 10:3 WSPC/117-IJSEKE

S0218194010004918

SPI-J111

0218-1940

Formal Analysis of UML 2.0 Activities

681

handling and events) for modeling than [13]. Also, with respect to checking user
dened properties on the Activities, our approach is more exible. Finally, using
our approach is easier for designers since we use traditional graph transformation
system. This contrasts with [15] which uses a concept named rule invocation that
cannot be supported directly by existing environments for modeling graph transformation systems (e.g. AGG).
The rest of this paper is organized as follows. Section 2 surveys the related
works. Section 3 describes our approach to dene a formal semantics for Activities.
Section 4 shows our approach to verify modeled workows and Sec. 5 concludes the
paper.
2. Related Work
Denition of formal semantics for Activity diagrams using dierent formal languages
has been a research topic in software engineering. In [16], Hausmann denes a concept named Dynamic Meta Modeling (DMM) using graph transformation systems.
In this new concept, the traditional graph rules have been extended by dening
a new concept named rule invocation. DMM includes two kinds of rules: bigstep and small-step rules. Big-step rules have a similar mechanism as traditional
rules but small-step rules should be invoked by big-step rules. In [16], there is
also a denition for semantics of Activity diagrams using concept of DMM. By
using DMM and semantics dened by Hausmann for modeling and verication of
workows, Engels et al. [17] show how to employ GROOVE [16] for verication.
However, since GROOVE does not support rule invocation, they change the rules
to be veriable by GROOVE. They check deadlock freedom and action reachability
properties on the modeled workows. Compared to this work, our approach is more
exible in supporting user dened properties. Furthermore, our approach has the
ability to support data ow, event and exception modeling. In addition, it is not so
easy for designers to use this approach since the extension dened by Hausmann
(small/big step rules and rule invocation) cannot be modeled directly in existing
graph transformation tools.
Rafe and Rahmani [7] proposed a formal semantics for workow modeling and
analyzing by using graph transformation systems. They dene a graph schema to
formalize the metamodel of the Activities. To formalize the behavior of Activity
diagrams, they dene a set of graph transformation rules. The proposed semantics
only covers control ow and does not support traverse-to-completion.
St
orrle et al. [19] use Petri nets as the semantic background for the UML 2.0
Activities. By dening denotational semantics, they examine Activities based on
the UML version 2.0 standard. It covers basic control ow and data ow, expansion
nodes and exception handling. They showed that some of the constructs proposed
in the standard are not so easily formalized. They concluded that it is not possible
to use Petri nets for this purpose because of the traverse-to-completion semantics
in UML 2.0.

December 14, 2010 10:3 WSPC/117-IJSEKE

S0218194010004918

682

SPI-J111

0218-1940

V. Rafe, A. T. Rahmani & R. Rafeh

In [20], Eshuis denes a statechart-like semantics for UML 1.5 Activity diagrams.
He introduced a property called strong fairness (a model with no innite loop) to
verify functional requirements of the model. This approach uses NuSMV model
checker [21] to check the strong fairness property stated in an LTL expression.
He dened two levels of formalism: requirements level that is easy to analyze but
somewhat abstract and implementation level that is dicult to analyze but has an
accurate representation. This approach along with two others [14, 22] treat UML
1.5 Activities instead of its successor (UML 2.0).
Using UML Activities (instead of dening semantics for Activities), Baldan et al.
[23] use hypergraphs to show the behavior of a model (instance graph). They use
instance graph to show the static model of a system, then by dening a rule for
each Action in the Activity and using synchronized hyper graph rewriting, they
control the application of the rules. They present a variant of monadic second-order
logic to verify hyper graphs. On the negative side, they do not introduce any tools
to implement their ideas. Also, they do not use semantics dened by UML 2.0
(e.g. token ow) to implement their proposal.
3. Implementing the Semantics
To simplify modeling of workows, we only use a subset of UML 2.0 Activities. This
is because using this subset suces to model many types of workows. Figure 1
shows the parts of Activities which we consider for workow modeling. Before presenting our dened semantics for workow modeling, we need to show its basic idea.
Based on the UML 2.0 specication [3], Activities have a Petri-net-like semantics,
i.e., the semantics is based on token ow. When an Activity is executed, the Init

Fig. 1. A small portion of UML 2.0 metamodel [25].

December 14, 2010 10:3 WSPC/117-IJSEKE

S0218194010004918

SPI-J111

0218-1940

Formal Analysis of UML 2.0 Activities

683

node starts the token ow. Based on our dened rules this token is then routed
through the Activity.
Following the semantics described above, we need to dene an accurate syntax
for the model under design. To do so, we dene a set of constraints on the model.
These constraints are as follows:
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)

Each Activity diagram must have exactly one Init node and one Final node.
Init node has no incoming edges and Final node has no outgoing edges.
Each Fork and Decision node should have exactly two outgoing edges.
Each Merge, Action, Object, Init and Join node must have exactly one outgoing
edge.
The source and target node of each edge should not be identical (there must
not be any self-edge in the graphs).
Each Final, Object, Action, Fork and Decision node should have only one incoming edge.
Each Join and Merge node should have exactly two incoming edges.
Each Action node can have some outgoing edges to some dierent ExceptionHandler node and each ExceptionHandler node should have exactly one outgoing edge to an Action node (this kind of edges is dierent from other edges).

Note that constraints 1,3 and 7 do not restrict the modeler in practice: more
than one Init node can be modeled equivalently by one Init node and one or more
Fork node(s) (Final and Join nodes accordingly). Fork (or Decision) nodes with
more than two outgoing edges can be modeled equivalently by cascading two or
more Fork (Decision) nodes (we use the same way for Join and Merge nodes).
These constraints have been proposed to have models with precise syntax and to
make drawing of many UML 2.0 Activities possible.c
The class diagram shown in Fig. 1 represents a portion of UML 2.0 Activity diagrams metamodel [25]. This metamodel can be formally considered as an
attributed typed graph. As it was mentioned in Sec. 3, a metamodel denes the
abstract syntax of a modeling language. Also, a type graph represents a modeling
language formally. UML 2.0 specication stipulates that activities use a Petri-like
semantics [26]. Therefore, to show tokens, we add an attribute to Action node,
named token of type boolean. Figure 2 shows the enhanced metamodel as a
type graph for Activity diagrams.
The proposed type graph based on the enhanced metamodel along with listed
constraints are shown in Fig. 2. We design this type graph and other parts of
proposed graph transformation system in AGG toolset. AGG automatically checks
the consistency of each host graph (i.e. Activity diagram) and rules with the type
graph and other constraints. Modeling an Activity in AGG ensures us that it is
syntactically consistent with type graph and other constraints. A formal denition
c Since

them.

labels or guards on the edges have no eect on our approach for verication, we ignore

December 14, 2010 10:3 WSPC/117-IJSEKE

S0218194010004918

684

SPI-J111

0218-1940

V. Rafe, A. T. Rahmani & R. Rafeh

Fig. 2. Proposed type graph for UML 2.0 Activity diagram.

of workows (or in general Activity diagram) is: a workow is a host graph typed
over the typed graph of Fig. 2.
Our proposed type graph includes one abstract type (i.e. Node). The star (*)
sign on the top right corner shows the multiplicity of these nodes in the models. This
abstract type is inherited by other nodes (except Exception). Using inheritance, all
the other nodes (except Exception) have the associations with the specied multiplicities to node type Edge. According to UML 2.0 specication, in contrast
with control nodes and edges, Action and Object nodes can hold the token. Preventing control nodes and edges from holding tokens ensures that tokens do not get
stuck when alternative paths are open [23]. Taking this semantics into account,
we enhanced Action nodes with a Token attribute. Two kinds of such attributes
are associated to object nodes. Object nodes can hold more than one token at a
time a specic maximum number of tokens [26]. We used UB to show the upper
bound of tokens. CV shows the current value of tokens. Before the execution of
the Activity, the value of CV is zero which means that the Object node does
not carry any token. Greater values for CV show the number of tokens in an
Object node and thus we do not need token attribute for Object nodes. Node type
Exception is used to support exception handling. Each exception is associated
with a handler (it is specied with an Action node) and may be raised by an action.
In fact, each action may raise more than one exception. The type graph has a node
type Key. A boolean attribute ag with initial value false is associated to this
node. Each Activity has exactly one node of type key. We control the execution
of the Activity using key node at the beginning and at the end (by some graph
rules). Each node type Edge points to the token needs to be routed (using the
points association).
Such type graph does not satisfy all the above constraints. Therefore, we need
additional constraints. For example, based on this type graph, we can have host
graphs (Activity diagrams) with some Edges without any source or target node. In
AGG, by atomic graph constraint and formula constraint, we can dene desired constraints on the model. For example, consider Fig. 3 which consists of three atomic

December 14, 2010 10:3 WSPC/117-IJSEKE

S0218194010004918

SPI-J111

0218-1940

Formal Analysis of UML 2.0 Activities

685

Fig. 3. Three atomic graph constraints.

graph constraints described by three rules. First, each Edge must have exactly one
source and one target node which cannot be identical. The second constraint ensures
that each node does have two outgoing edges to a node of type Edge (we use the
negation of this constraint in the formula constraint). The last constraint states
that each Fork node must have exactly two outgoing Edges. The formula constraint: (1 && (! 2) && 3) forces the host graphs (Activities) to follow all the three
constraints.
We complete the metamodel of the proposed formal semantics by adding extra
constraints to the graph transformation system. Then, we can directly model workows (or Activities) as a host graph in graph transformation system. Figure 4
shows a sample workow modeled by an Activity diagram [3]. All Action nodes in
the dashed region can raise the exception Cancel Order Request . This Activity
diagram, which describes the processing of orders in a company, is used as a running
example for the rest of the paper. The meaning of the diagram is as follows:
The Decision node with two guards in the diagram is responsible for accepting
or rejecting an order. If the order is accepted, Action Fill Order is performed. Then,
to speed up the process, two Actions Ship Order and Send Invoice are executed in
parallel. After termination of these two actions (or rejection of the order), Order
Close Action is performed. Finally, either by reaching the Final node or raising the
exception Cancel Order Request, the process is terminated.

Fig. 4. A sample activity diagram [3].

December 14, 2010 10:3 WSPC/117-IJSEKE

S0218194010004918

686

SPI-J111

0218-1940

V. Rafe, A. T. Rahmani & R. Rafeh

Fig. 5. A portion of the sample activity diagram in Fig. 4 as a host graph in AGG.

A portion of the sample Activity as a host graph in AGG is shown in Fig. 5.

Note workows have been directly modeled as a host graph (Activity) in AGG. It
is also possible to draw the Activity in a desired UML editor. Then, using a one-to
one-mapping between UML and AGG constructs, we can implement a transformer
to automatically transform Activities which have been designed in a UML editor to
host graphs in AGG. This is useful for non-expert designers since they do not need
to learn graph transformation or to work with AGG.
In fact, most of the constraints formulated above put restrictions on the syntax
of Activities rather than on their semantics. We focus on the verication of the
dynamic semantic rather than verication of syntax restrictions, because syntax
restrictions can be automatically veried by AGG. To verify dynamic semantic, we
need a formal semantic of the behavior of Activity diagrams. Therefore, we design
the dynamic semantics of the model by dening graph transformation rules. The
proposed rules show the token ow in the host graphs. We dene the following rules
for token ow:
At the beginning there is no token in a token ow, i.e. the Edge nodes do not
point to any node. The token ow is started by Init node as soon as the Activity
is executed.
Tokens are not stuck on nodes, i.e. as soon as there is a suitable way, tokens are
routed. This is compliance with the UML specication which states the traverseto-completion semantics for tokens.
When a token arrives to the Final node the ow of tokens is terminated.
Following the above rules and the desired behavior of Activity diagrams, we have
proposed 26 graph transformation rules as dynamic semantics for Activities. Due
to the lack of space, we just briey describe some of the rules.
We have implemented the token ow semantics in a simple way: as soon as a
token arrives at the incoming Edge(s) of a node (in this case the Edge points to
Action or Object node holding the token), this node (based on its dened semantics) will oer the token to its following Edge(s). The implementation of Init node
semantics is depicted in Fig. 6. NAC (Negative Application Condition) and LHS
(Left Hand Side) describe the preconditions, while RHS (Right Hand Side) shows

December 14, 2010 10:3 WSPC/117-IJSEKE

S0218194010004918

SPI-J111

0218-1940

Formal Analysis of UML 2.0 Activities

687

Fig. 6. The proposed rule as the semantics of Init node.

the post-conditions of the rule. We follow the AGG notation to show the rules.
The rule shown in Fig. 6 states that if flag attribute of node Key is false and the
outgoing Edge of Init node does not point to the Key node, the Edge must point to
the Key node (in this case Key node plays the role of a token). This rule is in fact
the starting point for the execution of the Activity. Note that there is no existing
token in the model when the execution starts. Therefore, the Key node plays the
role of a token till the token arrives at an Action or Object node. We use the Key
node (while its flag is false) in the LHS of all designed rules. When a token arrives
at the Final node, the value of ag is changed to true. This terminates the ow of
tokens because no more rule can be applied on the Activity. We discuss the rule
implementing the semantics of Final node later.
Figure 7 shows two other rules implementing portions of the semantics of Object
nodes.d Rule (A) describes the situation when the incoming Edge of an Object node

Fig. 7. Two example rules implementing portions of the semantics for object nodes.

d In

this article, we focused mostly on control ow instead of data ow. Therefore, the implemented
semantics for Object nodes is based on control ow.

December 14, 2010 10:3 WSPC/117-IJSEKE

S0218194010004918

688

SPI-J111

0218-1940

V. Rafe, A. T. Rahmani & R. Rafeh

points to a token. The LHS of this rule has an Attribute Conditione : AC = x > y
to state that this rule can only be applied on the Activity if the current number of
holding tokens by Object node is less than the dened Upper Bound for that Object
node. This is in contrast with the UML 2.0 specication which states that when
the number of tokens in an Object node reaches its upper bound, no more token
is accepted [23]. This rule increments the current number of tokens (to show the
acceptance of the token by Object node). It also terminates pointing of the incoming
Edge of the Object node to the token. To show the token in the rule we use the Key
node. Of course, it is also possible to use an Action or Object node. Therefore, we
need two similar rules for those cases which are not shown in the gure.
In Figure 7, Rule (B) shows the case where an Object node holding one or more
tokens (i.e. AC = y > 0) oers a token to its outgoing Edge. The three NACs of
this rule state that the outgoing Edge cannot point to any token. The RHS of this
rule decrements the current number of tokens in the Object node. It also states that
the outgoing Edge points to the Object node (i.e. the Edge is carrying a token).
Three sample rules are shown in Fig. 8 which implement the semantics of Action
nodes. Rule (A) in this gure is similar to rule (A) in Fig. 7, but instead of an Object
node an Action node has been replaced. Moreover, Action node can hold only one
token at a time. Rule (B) in Fig. 8 describes the token ow semantics from Action
nodes which do not raise any exceptions (NAC4 shows this fact). Other three NACs
state that the outgoing Edge cannot point to any token. In fact, this looks like to

Fig. 8. Three example rules implementing portion semantics of action nodes.

e Attribute

Condition (AC) is one of the useful facilities provided by AGG.

December 14, 2010 10:3 WSPC/117-IJSEKE

S0218194010004918

SPI-J111

0218-1940

Formal Analysis of UML 2.0 Activities

689

rule (B) in Fig. 7. Finally, Rule (C) implements the same semantics as rule (B)
when the Action node can raise an exception. The control ow of the Activity can
be changed by exceptions. Therefore, there are two possible scenarios for token to
be routed. The rst one is shown in Fig. 8 by rule (C) which states that Action
does not raise the exception. Thus, the token is routed through the outgoing Edge
of Action node. The case where Action raises an exception routes the token through
the handled edge to the handler Action node. This case is not shown in the gure.
Note that throw and handled edges dier from activity Edges. In fact, Edge is
a node type in the type graph of Fig. 2 while throw and handled are two edge
types. UML metamodel supports Edge node (Fig. 1) while the type graph has been
enhanced by throw and handled to support exception handling.
Figure 9 describes the semantics of Final node. As the gure shows, when a
token arrives to the Final node, the ow of tokens is terminated by changing the
ag attribute to false. As a result, no more rules can be applied on the Activity.
This diers from the UML specication which states that when a token arrives at
the Final node, the entire Activity is immediately terminated (in contrast with Flow
Final nodes) [27].
Applying all enabled rules to initial state (the Activity diagram before applying
rules) will result in a transition system which represents the complete behavior of
the Activity diagram. When using model checking, this transition system is the
basis for analysis of the Activity. In the next section, we show our approach to
verify an Activity using its transition system.
4. Verification and Validation
As mentioned in Sec. 3, to analyze designed Activities we use our previous approach
to verify graph transformation systems [9]. When designers are experts in graph
transformation, they can directly model workows by graph transformation. Nonexpert designers can model workows by UML Activities.f Indeed such designers
do not need to dene any rule for verication. This is due to designing a bunch
of xed properties for designers. Designers only model the workow. Verication

Fig. 9. Example rule implementing the semantics of nal node.

f In

this case, a transformer is needed to automatically transform UML Activities to graph transformation.

December 14, 2010 10:3 WSPC/117-IJSEKE

S0218194010004918

690

SPI-J111

0218-1940

V. Rafe, A. T. Rahmani & R. Rafeh

is automatically done via our xed designed properties (without intervention of

designers). Of course, expert designers can dene new properties. One advantage of
using rules to state properties is relieving designers to learn any other formalism.
Instead, they can state properties by the same formalism that they model the system
(i.e. graph transformation).
Recall from Sec. 4 that for a correct Activity, a token must arrive at the Final
node which means that the Activity must be deadlock free. To verify this property
we should check that for all possible executions of the Activity, Final node is reachable. To state this property, we have designed two rules: KeyFalse and KeyTrue
shown in Fig. 10. These two rules have neither a NAC nor a dierence in their
LHS and RHS. When preconditions of a property rule hold within a state, that
rule matches the state. The only precondition of KeyFalse is that the token has
not arrived at the Final node (in contrast to KeyTrue). Note that as soon as the
token arrives at the Final node, the ag is changed to true. The LTL expression

(KeyFalse (KeyTrue)) states this property, where symbol
means always,
means finally and symbol shows the implication. The result of checking
this property on the transition system is true if in every possible execution of the
Activity there is a state in a path in which KeyFalse is satised and then eventually
there is a state in the postx of that path in which the token arrives at the Final
node (i.e. KeyTrue is satised). This means that the token must always arrive at
the Final node. The Activity in Fig. 4 is an example which satises this property. In
this Activity token always arrive at the Final node. On the contrary, the Activity
of Fig. 11(a) shows an example where the mentioned property is not satised. This
Activity shows a workow which contains a deadlock. In this diagram, there is a
Join node immediately after Init node which prevents the token to be propagated
from Init node. As a result, the token never arrives at the Final node which causes
a deadlock. Therefore, the mentioned property is never satised for this Activity.
Another property for a sound workow is not having any useless work (Action),
i.e. for each Action node there should be at least one execution in which the token
arrives at that node. In other words, each Action in a sound workow must be
reachable. We state this property as follows: each specied Action must be reachable
which means that a rule must be designed for each Action (using its name) to
check this property. Figure 10 shows a rule (ActionWithToken) to state that the
Action Ship Order in the Activity of Fig. 4 is reachable. The LTL expression

(ActionWithToken) states this property which is satised for the Activity of
Fig. 4. This LTL expression ensures us that there is an execution of the Activity

Fig. 10. Rules KeyFalse, KeyTrue and ActionWithToken.

December 14, 2010 10:3 WSPC/117-IJSEKE

S0218194010004918

SPI-J111

0218-1940

Formal Analysis of UML 2.0 Activities

691

Fig. 11. Two faulty activities. (a) contains a deadlock. (b) contains an unreachable action node.

which the specied Action node (Ship Order in this case) has the token (i.e. it is
reachable).
Now, consider the Activity of Figure 11(b). If we replace the name of the Action
node in Figure 10 (ActionWithToken) with Action4 and check the property, we
see that it is not satised. Since there is a Decision node before Action1 and
Action2, based on the semantics of Decision nodes, the token is routed to only
one of them. As a result, in all executions of this Activity, only one token will
arrive at Join node before Action4. Based on the semantics of Join nodes, token
will never reach Action4. Therefore, we can conclude that this property is never
satised for this workow. Such kind of property can be stated in a more general
way by ignoring the name of Action. In this case, this property only determines the
existence of unreachable Action in the Activity instead of unreachable Action itself.
To validate our approach by some benchmarks, we use model checking. For
example, if we implement the semantics correctly, the two Actions ship order
and send invoice in Activity of Fig. 4 can be executed in parallel, i.e. there must
be at least one state in the transition system in which both Actions have the token
in that state. Two property rules of Fig. 12 along with the LTL expression:

(ActionsWithoutToken (ActionsWithToken)) state this property.
In all model checking approaches state space explosion is a serious restriction.
Therefore, we discuss the size of Activities (or graphs in general) that our approach
can verify. Scalability of our approach depends on dierent parameters: the size
of the host graph, the number of dynamic nodes which must be added/deleted

December 14, 2010 10:3 WSPC/117-IJSEKE

S0218194010004918

692

SPI-J111

0218-1940

V. Rafe, A. T. Rahmani & R. Rafeh

Fig. 12. Two example property rules.

Table 1. Exprimental results.
Example
Figure 4
Figure 11 (a)
Figure 11 (b)

States

Memory (MB)

Time (M Sec)

2173
3
84

1.2
0.1
0.4

2271
1
5

to/from the host graph by rules, the number of applicable rules in the same time,
etc. We know that there is not any dynamic node in the Activities. Besides, the
size of Activities is not usually too large. When the size of Activities is too large
designers can decrease their size using Action Call nodes. As a result we came to
this conclusion that our approach can support Activities with reasonable size. To
investigate this, we veried the example activity diagrams in this paper (diagrams
in Fig. 4 and Fig. 11). The number of the generated states along with the consumed
time and space are shown in Table 1.
Table 1 summarizes the results obtained by our verication approach,g this table
shows that for these examples, the number of generated states, consumed memory
and time are too small.
5. Conclusions and Future Work
We have proposed an approach to formally dene a semantic for UML 2.0 Activities. This semantic is based on token ow and traverse-to-completion using
graph transformation systems. To implement static semantics, we have dened a
type graph (based on UML 2.0 Activity metamodel). All Activities are modeled as
a host graph which must conform to the type graph. To dene dynamic semantics,
we have dened a set of graph transformation rules. We have used our previous
approach to verify graph transformations. We have illustrated our proposed verication approach to verify workows by dening some quality criterion. This is
because workows are a typical modeling domain for UML 2.0 Activities.
Our approach is easy for non-expert designers who have no knowledge about
underlying formalisms (i.e. BIR and Bogor). However, further research is required
to model other necessary elements as Parameter nodes and Pins. We are currently
working on modeling other elements and implementing their semantics as some
graph transformation rules.
g The

translator is available at: http://webpages.iust.ac.ir/rafe/les/expriments.rar

December 14, 2010 10:3 WSPC/117-IJSEKE

S0218194010004918

SPI-J111

0218-1940

Formal Analysis of UML 2.0 Activities

693

References
1. R. Eshuis, D. Jansen and R. Andwieringa, Requirements-level semantics and model
checking of object-oriented statecharts, Requirements Eng. J. 7 (2002) 243263.
2. G. Alonso, F. Casati, H. Kuno and V. Machiraju, Web Services: Concepts, Architectures and Applications (Springer, 2004).
3. Object Management Group, UML Specication V2.0, http://www.omg.org/ technology/documents/modeling spec catalog.htm (2005).
4. L. Baresi and R. Heckel, Tutorial introduction to graph transformation: A software
engineering perspective, in Proc. of First International Conference on Graph Transformation (ICGT), LNCS Vol. 2505, 2002, pp. 402429.
5. H. Ehrig, G. Engels, H. J. Kreowski and G. Rozenberg, Handbook on Graph Grammars
and Computing by Graph Transformation, Vol. 2: Applications, Languages and Tools
(World Scientic, 1999).
6. S. Kuske, A formal semantics of UML state machines based on structured graph
transformation, in Proc. of UML 2001, LNCS Vol. 2185, 2001.
7. V. Rafe and A. T. Rahmani, Formal analysis of workows using UML 2.0 activities and
graph transformation systems, in Proc. of 5th International Colloquium on Theoretical
Aspects of Computing (ICTAC08), LNCS Vol. 5160, 2008, pp. 305318.
8. M. Beyer, AGG1.0 Tutorials, Technical University of Berlin, Department of Computer Science, 1992.
9. L. Baresi, V. Rafe, A. T. Rahmani and P. Spoletini, An ecient solution for model
checking graph transformation systems, in Proc of 3rd Workshop on Graph Transformation for Verification and Concurrency, ENTCS Vol. 213, 2007, pp. 321.
10. V. Rafe, A. T. Rahmani, L. Baresi and S. Spoletini, Towards automated verication of layered graph transformation specications, J. IET Software, 3(4) (2009)
276291.
11. V. Rafe and A. T. Rahmani, Towards automated software model checking using graph
transformation systems and Bogor, J. Zhejiang University Science A (JZUS), 10(8)
(2009) 10931105.
12. Robby, M. Dwyer and J. Hatcli, Bogor: An extensible and highly-modular software
model checking framework, in Proc. of the 9th European Software Engineering Conference, 2003, pp. 267276.
13. R. Eshuis, Semantics and Verication of UML Activity Diagrams for Workow Modelling, Ph.D. Thesis, University of Twente, Netherlands, 2005.
14. C. Bolton and J. Davies, On giving a behavioural semantics to activity graphs, in:
A. Evans, S. Kent and B. Selic (Eds.), UML 2000, LNCS Vol. 1939, 2000.
15. C. Soltenborn, Analysis of UML workow diagrams with dynamic metaModeling techniques, Masters Thesis, University of Paderborn, Germany, 2006.
16. J. H. Hausmann, Dynamic Meta Modeling: A Semantics Description Technique for
Visual Modeling Languages, Ph.D. Thesis, University of Paderborn, Germany, 2005.
17. G. Engels, C. Soltenborn and H. Wehrheim, Analysis UML activities using dynamic
meta modeling, in Proc. of 9th IFIP International Conference on Formal Methods for Open Object-Based Distributed Systems (FMOODS), LNCS Vol. 4468, 2007,
pp. 7690.
18. A. Rensink, The GROOVE simulator: A tool for state space generation, in Applications of Graph Transformations with Industrial Relevance (AGTIVE), LNCS
Vol. 3062, 2004, pp. 479485.
19. H. St
orrle and J. H. Hausmann, Towards a formal semantics of UML 2.0 activities,
in: P. Liggesmeyer, K. Pohl and M. Goedicke (Eds.), Software Engineering, LNI GI
Vol. 64, 2005, pp. 117128.

December 14, 2010 10:3 WSPC/117-IJSEKE

S0218194010004918

694

SPI-J111

0218-1940

V. Rafe, A. T. Rahmani & R. Rafeh

20. R. Eshuis, Symbolic model checking of UML activity diagrams, ACM Trans. Software
Engineering Methodology 15(1) (2006) 138.
21. A. Cimatti, E. Clarke, F. Giunchiglia and M. Roveri, NuSMV: A new symbolic model
checker, International Journal on Software Tools for Technology Transfer 2(4) (2000)
410425.
22. E. B
orger, A. Cavarra and E. Riccobene, An ASM semantics for UML activity diagrams, in: Rus, T. (ed.), AMAST 2000, LNCS Vol. 1816, 2000, pp. 293308.
23. P. Baldan, A. Corradini and F. Gadducci, Specifying and verifying UML activity
diagrams via graph transformation, in Proc. of Global Computing, LNCS Vol. 3267,
2004, pp. 1833.
Schmidt and D. Varr
24. A.
o, CheckVML: A tool for model checking visual modeling languages, in Proc. of UML 2003: 6th International Conference on the Unified Modeling
Language, LNCS Vol. 2863, 2003, pp. 9295.
25. H. St
orrle, Semantics of control-ow in UML 2.0 activities, in: N.N., (ed.), Proc. IEEE
Symposium on Visual Languages and Human-Centric Computing (VL/HCC ), 2004.
26. C. Bock, UML 2 activity and action models Part 4: Object nodes, Journal of Object
Technology, 3(1) (2004) 2741, http://www.jot.fm/issues/issue 2004 01/column3.
27. C. Bock, UML 2 activity and action models Part 3: control nodes, in Journal of Object
Technology 2(6) (2003) 723, http://www.jot.fm/issues/issue 2003 11/column1.

Copyright of International Journal of Software Engineering & Knowledge Engineering is the property of World
Scientific Publishing Company and its content may not be copied or emailed to multiple sites or posted to a
listserv without the copyright holder's express written permission. However, users may print, download, or
email articles for individual use.