See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/336319905

Formal Transformation from UML Sequence Diagrams to Queueing Petri Nets

Chapter · October 2019

DOI: 10.3233/FAIA190082

CITATIONS READS

9 150

3 authors, including:

Vu Van Doc Thang Huynh Quyet

University of Economic and Technical Industries Hanoi University of Science and Technology
4 PUBLICATIONS 9 CITATIONS 89 PUBLICATIONS 391 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Thang Huynh Quyet on 08 October 2019.

The user has requested enhancement of the downloaded file.

588 Advancing Technology Industrialization Through Intelligent Software Methodologies, Tools
and Techniques
H. Fujita and A. Selamat (Eds.)
IOS Press, 2019
© 2019 The authors and IOS Press. All rights reserved.
doi:10.3233/FAIA190082

Formal Transformation from UML

Sequence Diagrams to Queueing Petri
Nets
Van-Doc Vua,b, Trong-Bach Nguyena, and Quyet-Thang Huynh a,1
a
School of Information and Communication Technology, Hanoi University of Science
and Technology, Vietnam
b
University of Economics - Technology for Industries, Vietnam

Abstract. In this paper, a formal strongly consistent transformation from UML

Sequence diagrams (SDs) to Queueing Petri Nets (QPNs) is defined. Sequence
diagrams are charts used to identify the sequence of event occurrences of a certain
audience. QPNs are graphical formalisms, at a lower level of abstraction, for which
efficient and mature simulation-based solution techniques are available. We show
how the language of sequence diagrams is mapped onto an equivalent language of
QPNs through formal transformation rules. We develop 12 general rules for formal
SD-to-QPN transformation. We also present applying the proposed rules for a
typical case study of a cloud service system. Experimental results are also provided.

Keywords. Model Transformation, Sequence Diagrams, Queueing Petri Nets.

1. Introduction

The software systems are increasingly complex, so we need to have a more design
approach to successful implementation. Through communication between objects,
sequence diagrams are often used to describe information flow in a system. We combine
formal modeling techniques with software design on UML to model and analyze reliable
software. An ordinary Petri net consists of a set of places and a set of transitions. The
places contain a certain number of tokens. When we start analyzing the Petri net, the
initial marking function determines the initial number of tokens. The number of tokens
required in each connected place to be ready to fire are defined by a forward incidence
function linked with a transition. It deducts that number of tokens from each incoming
place and deposits new tokens in other places if a backward incidence function is defined
when the transition is fired. The Queueing Petri Nets (QPNs) are built on a combination
of Queueing Networks and some extensions of Petri nets such as Generalized Stochastic
Petri Nets and Colored Petri Nets. Queueing Networks and Generalized Stochastic Petri
Nets are the most popular modeling formalisms that have been used in the past decade,
but both have some short-comings. The time a token occupies the server is defined
through a statistical distribution. The token is put into the depository when the time of a

1
Quyet-Thang Huynh, School of Information and Communication Technology, Hanoi University of
Science and Technology, Hanoi, Vietnam, C1 Building, Room 210; E-mail: [email protected].
 V.-D. Vu et al. / Formal Transformation from UML Sequence Diagrams to Queueing Petri Nets 589

token finished, which then behaves like an immediate place for connected transitions.
Only tokens in the depository are considered as available for the incidence function.
Meedeniya in [1] proposed a formal representation for UML sequence diagrams
with a specific language, some additional notions of traces. The author presented formal
transformation rules to obtain an equivalent Colored Petri Net from a given sequence
diagram. In particular, the author defined an additional set of state locations associated
with a sequence diagram formally. These state locations correspond to the states of the
object instances that occur before as well as after events. The author has shown the
transformation rules that guarantee a one-to-one correspondence between the set of legal
traces of both source and target models. In a specific way, the transformation rules from
SDs to CPNs are split into main transformation rules, additional transformation rules and
rules about transformations of interaction fragment, and complex models.
In [7,9,13,21], the authors defined a QPN as an 8-tuple QPN = (P; T; C; I-; I+; M0;
Q; W). However, this is just a formal definition for a single QPN. To be deal with multi-
level QPNs, we used a new parameter to know if a place is a subnet place and how its
internal structure is. Subnet place is a place that can contain a QPN, and this child may
have other subnet places.
Based on the above analysis, we formulate formal rules to transform UML SDs into
QPNs. Our rules should be classified into two groups: (i) general transformation rules
and (ii) interaction fragment rules. For the general transformation rules, we focus on
transforming SD-QPN by solving all significant structures. For the other rules, we
describe different kinds of interaction fragments which are available in UML sequence
diagrams and how they are best represented in QPNs. In this research, only general
transformation rules are considered.
Our main contribution in this paper is as follows: We extend the QPN definition by
adding the subnet parameter. We also propose a collection of transformation rules from
Sequence Diagrams to Queueing Petri Nets, which has strongly consistent in the
respective languages. The transformation rules reflect an injection function between the
legal traces of both two model. We provide a case study to prove the effectiveness of our
rulers.
The remaining part of the paper organizes as follows. Section 2 discusses about
related work. We review some features of a sequence diagram and a queueing Petri Net
in section 3 then give detailed formal definitions. Section 4 provides our formal
transformation rules, defining the rules for the formal SD-to-QPN transformation.
Section 5 presents a case study that validates our model transformation approach. The
conclusion and future work are discussed in Section 6.

2. Related work

Queueing networks and Petri nets are powerful models for such a form of analysis
[3,8,12]. Several approaches have been proposed for performance systems modeling:
based on the stochastic models such as Queueing Nets or Stochastic Petri Nets. Building
the stochastic models requires experience in stochastic modeling and analysis. The
researchers have proposed the low-level predictive models are automatically generated
by high-level network modeling.
When reviewing performance modeling tools, some recent surveys have focused on
model-based prediction [21], evaluation of component-based systems [23], and
analyzing software architectures. In [17], the authors deal with the problem of calculating
590 V.-D. Vu et al. / Formal Transformation from UML Sequence Diagrams to Queueing Petri Nets

the response time in a distributed web systems environment. The authors have
demonstrated the potential in modeling distributed web systems using Queueing Petri
Nets which a monolithic modeling technique to assess the performance.
In [10,13,19], QPN is considered the most effective method to evaluate software
performance. However, due to the semantic difference between QPN and UML
Sequence Diagram, it is challenging to create correspondences between them, and
always requires a lot of manual intervention. Therefore, it is necessary to build an
intermediate model to be able to solve the semantic difference between UML SD and
QPN, lay the foundation for transformation from UML to QPN.
Our approach is that give a detailed formal definition of Queueing Petri Nets and
Sequence Diagrams. We develop the transformation rules for the formal SD-to-QPN as
follows (Fig.1):

Figure 1. The transformation from formal SDs to formal QPNs

3. Formal Presentations of Sequence and QPN

3.1. Sequence Diagram.

The UML SD is the most common kind of Interaction Diagram [5]. The lifelines
interact with each other through messages; that sequence is important to understand the
situation. A bit detailed description for the semantics of a sequence diagram is given in
this section. They are following the standardization of the UML 2.5 sequence diagrams
[6].

3.1.1. Basic Sequence Diagram

Sequence diagrams often are used for capturing inter-object behavior [4,6]. A
sequence diagram has two dimensions: a horizontal dimension representing the instances
participating in the scenario, and the other representing time. An instance can correspond
to a particular object or a role played in the interaction. A vertical dashed line called
lifeline represents the existence of the instance at a particular time. The order in which
events occur is also the order of events along a lifeline. A message is shown as a line
from the sender to the receiver [5]. The send and receive events may both be on the same
lifeline.
Each interaction fragment has at least one operator held at the upper left corner of
the fragment. There are several possible operators, for example, alternative behavior (alt),
parallel behavior (par), forbidden behavior (neg), mandatory behavior (assert), iterative
 V.-D. Vu et al. / Formal Transformation from UML Sequence Diagrams to Queueing Petri Nets 591

behavior (loop), reference another diagram (ref), and so on. An interaction fragment can
contain one or more operands depending on the chosen operator.

3.1.2. Formal representation of SD

For the formal representation of SD, we use the definition as in [1] with the name is
d  N formally as a tuple SD. Let Ω be a set of interaction operators given Ω = {alt, par,
loop, option, break, critical, assert, neg, strict, seq, consider, ignore, ref}, and Env be a
finite set of environment instances.

Definition 1 (A Sequence Diagram) A sequence diagram is a tuple SD = (d, I, E, <,

M, T, F, X, Exp) where
1. d  N is the name of the sequence diagram;
2. I is a finite set of object instances;
3. E = ‫׫‬i  I Ei is a set of events such that satisfy any i ≠ j ‫ א‬I, Ei ∩ Ej = I ;
4. < is a set of partial orders <i Ž Ei× Ei with i ‫ א‬I;
5. M is a finite set of message labels;
6. T is a set of local transitions such that T Ž E × M × E and for
t1, t2  T if t1 = (e11, m1, e12) ≠ t2 = (e21, m2, e22) then e11 ≠ e12 ≠ e21 ≠ e22,
7. F is the set of interaction fragment identifiers in d such that:
x f: F → Ω × N is a function that associates an operator and a number of
operands to an interaction fragment identifier
x g: F × N → 2E is a function that associates a set of events to a pair (id, n)
where id is an interaction fragment identifier and n is nth operand of the
fragment. It is only defined if f(id) = (o, m) and n ≤ m. For arbitrary n ≠ k
with n, k ≤ m, g(id, n) ∩ g(id, k) = I
x h: F × N → 2F is a function that associates a set of interaction fragment
identifiers to a pair (id, n) where id is an interaction fragment identifier and
n is the nth operand of the fragment. It is only defined if f(id) = (o, m) and
n ≤ m, and further satisfying the following properties for id 1, id2 ‫ א‬F with
id1 ≠ id2, f(id1) = (o1,n1) and f(id2) = (o2, n2):
1. id1  h(id1, x) for any x ≤ n1;
2. if id1  h(id2, m2) and id2  h(id1, m1) with arbitrary m1 ≤ n1 and m2 ≤
n2, then g(id1, m1) ∩ g(id2, m2) = ‫׎‬
3. if id2 ‫ א‬h(id1, m1) then g(id1, m1) ‫׫ ل‬n≤n2 g(id2, n)
8. X = {Xi}i‫א‬I is an I-indexed family of local variables;
9. Exp is a set of expressions such that guard: T → Exp is a partial function that
associates an expression to a local transition.

A state location describes the status during the life of an object after finishing some
activities or waiting for an event. In the formal representation, we use the definition as
in [1]. There are three types of a state location classified by the location in the instance
contains it. They are initial, internal and end state locations. The following is the
definition of a state location:

Definition 2. (State Location) Let SDd be a sequence diagram for a named diagram
d. The set Sd gives its associated set of state locations:
592 V.-D. Vu et al. / Formal Transformation from UML Sequence Diagrams to Queueing Petri Nets

x Sd = ‫׫‬i‫א‬I+ Si where Si are the state locations for instance i, and Si ∩ Sj = ‫ ׎‬for
arbitrary i ≠ j ‫ א‬I+;
x Si = Siini ‫ ׫‬Siint ‫ ׫‬Siend is a set of initial, internal and end state locations
for instance i ‫ א‬I+ respectively. Each instance has exactly one initial
and one end state location. For i ‫ א‬Env, Siint = ‫;׎‬
x μi : M × Ei → Si is an I+-indexed function that given a pair (m, e) of
a message m and an event e associates it with a next state location of
instance i. It is only defined if there is a t ‫ א‬T with t = (e, m, e’) or
t = (e’, m, e);
೔
x λi: F × N → ʹௌ is an I+-indexed function that given a pair (id, n) associates
operand n of fragment id with a set of state locations of instance
i ‫ א‬j(id), indicating all its state locations in the operand;
x θi: F → Si is an I+-indexed function that given an interaction fragment
id returns one state location for instance i ‫ א‬j(id) which is associated
with the end of the fragment.

[1] also introduced the two functions, next and previous, for determining events or state
locations with the next or previous index over instances. We will skip the latter, and just
show formally the first as follows:

Definition 3. (Function: next) Let SD be a sequence diagram and S be a set

of state locations in this SD. Nexti as an I+-indexed function defined over state locations
೔
and events such that nexti : Si ‫ ׫‬Ei → ʹௌ ‫׫‬୉౟ Let id  F be an arbitrary interaction
fragment in the diagram with f(id) = (o, m), and j be a natural number ranging 1 ≤ j ≤ m

nexti(x) = {min(Ei)} ֚ x ‫ א‬Siini

{μi(m, x)} ֚ x ‫ א‬Ei and μi(m, x) defined for some m ‫ א‬M
{s1, . . . , sm} ֚ x ‫ א‬Ei, x = min(gi(id)) and sj = min(λi(id, j))
{θi(id)} ֚ x ‫ א‬Ei, x = max(gi(id)) and o ≠ break
{max(gi(id))}֚ x ‫ א‬Siint , x = max(λi(id, j)) and o ≠ {par, loop}
{e’} ֚ x ‫ א‬Siint , not covered by the cases above with μi(m, e) = x
for some m ‫ א‬M, e ‫ א‬Ei and e → e’
٣֚ x ‫ א‬Si

For behaviour with par, loop and break interaction fragments we define nexti() as
follows:

nexti(x) = {e’} ‫ڂ ׫‬௣ஷ௝ ݃ሺ݅݀ǡ ‫݌‬ሻ ֚ x ‫ א‬Siini , x ‫ א‬λi(id, j), o = par,

x ≠ min(λi(id, j)), μi(m, e) = x for some m ‫ א‬M,
e ‫ א‬Ei and e → e̓
{min(gi(id)) ‫ ׫‬max(gi(id))} ֚ x ‫ א‬Siini , x = max(λi(id, j)) and o = loop
{θi(id̓)} ֚ x ‫ א‬Ei , x = max(g(id)i), o = break,
f(id’) = (loop, 1) and h(id’, 1) = id
 V.-D. Vu et al. / Formal Transformation from UML Sequence Diagrams to Queueing Petri Nets 593

3.2. Queueing Petri nets

QPN (Queueing Petri Net) is a performance model with a strong mathematical base,
formed from several extensions of Petri net such as CPN, SPN, GSPN and CGSPN and
also supplemented the properties of a queue of Queueing Networks [8].
Another type of element that has not been considered in those studies is subnet place.
An subnet place is capable of containing a child QPN with specialized ordinary place
including one input place, one output place and one actual population place which is used
to control tokens deposited to the subnet.
In [7,9,13,21], the authors defined a Queueing Petri Net as an 8-tuple QPN = (P; T;
C; I-; I+; M0; Q; W). However, this is just a formal definition for a single QPN. If we
want to deal with the QPN hierarchy, it is necessary to add the new parameter to know
if the type of place is subnet place. Also we can use it to describe the internal structure
in a subnet. The “new” QPN definition is as follows:

Definition 4. (Queueing Petri Net) A Queueing Petri Net is a 9-tuple QPN = (P; T;
C; I-; I+; M0; Q; W,S) where:
1. P = {p1; p2;…; pn} is a finite set of places, and P is non-empty
2. T = {t1; t2; … ; tm} is a finite and non-empty set of transitions, P ∩ T = I,
3. C is a color function that assigns a finite and nonempty set of colors to each
place and a finite and nonempty set of modes to each transition.
x C(p) is a finite and nonempty set of colors to each place p P
x C(p)MS is a finite set of the multiset of C(p)
x C(t) is a finite and set of modes to each transition.
4. I- is the backward incidence function defined on P × T, such that I-(p,t)  [C(t)
o C(p)MS], (p; t)  P x T
5. I+ is the forward incidence function defined on P × T, such that I+(p, t)  [C(t)
o C(p)MS], (p; t)  P x T
6. M0 is an initial marking function defined on P, M0(p)  C(p)MS
7. Q = (ܳଵ̱ ; ܳଶ̱ ; (q1;…; q|P|)) where
x ܳଵ̱ ‫ ك‬P is the set of timed queueing places,
x ܳଶ̱ ‫ ك‬P is the set of immediate queueing places,
x If pi is a queueing place, qi denotes the description of a queue taking all
colors of C(pi) into consideration. Otherwise, pi is the keyword ‘null’.
8. W= (ܹଵ̱ ; ܹଶ̱ ; (w1;…; w|p|)) where
x ܹଵ̱ ‫ ك‬T is the set of timed transitions
x ܹଶ̱ ‫ ك‬T is the set of immediate transitions, ܹଵ̱ ∩ ܹଶ̱ ∩ = I; , ܹଵ̱ ‫ܹ ׫‬ଶ̱ =
T;
x wi  [C(ti) o R+] such that  c  C(ti): wi(c)  R+. If ti  ܹଵ̱ , wi(c) is a
rate of a negative exponential distribution specifying the firing delay due
to color c. If ti  ܹଶ̱ , wi(c) is a firing weight specifying the relative firing
frequency due to color c.
9. S = (s1, s2, … , s|p|) where si  SQPN if pi is a subnet place, otherwise si is the
keyword ‘null’.
594 V.-D. Vu et al. / Formal Transformation from UML Sequence Diagrams to Queueing Petri Nets

4. Formal Transformation rules

In this section, we define the rules to map the formal UML sequence diagram to
Queueing Petri Nets. We split the rules in general and interaction fragment rules. The
latter are skipped in this paper.
The rules 1,2,3 and 4 are shown in Fig. 2.

Rule 1. Let SDd be a sequence diagram with name d. The QPN obtained by
transformation τ, τ(SDd) = QPNd has the same name d.
We transform a SD space to a QPN space. The elements in a SD should be mapped
to the matching elements in the respective QPNd

Rule 2. For all object instances in a SD, there exists a corresponding color in the
QPN: i  I,  o  C(t) ‫ ׫‬C(p) where τ(i) = o.
For each object instance in SD, there is a corresponding color in the QPN.

Rule 3. For all state locations of instances in an SD, there are some corresponding
places which contain the color of the underlying instance:  s  Si, i  I+,  p  P: τ(s)
= p and c(p) ‹ τ(i);

Rule 4. For each initial state location in a SD, the initial number for colors inside
the respective place are always set to 1.
x s  Siini , i I+ : m(τ(s))(f) = 1, τ(s)  P, fc(τ(s))
x s  Siini , i I+ : m(τ(s))(f) = 0, τ(s)  P, fc(τ(s))
The function m specifies the initial marking of the places in the net.

Rules Sequence Diagram QPN Explain

Rule 1

The obtained QPN has the

same name with the SD

Rule 2
For all object instances in
a sequence diagram, there
exists a corresponding
color in the QPN.
Each state locations in a
SD correspond to a place
Rule 3 in the QPN.
The number of all colors in
places which are
respective with initial state
Rule 4 locations are set to 1 at the
initial marking state. The
other places do not have
the property.
Figure 2. Transformation rules: 1-4
V.-D. Vu et al. / Formal Transformation from UML Sequence Diagrams to Queueing Petri Nets 595

Figure 3. Transformation rules: 5-12

596 V.-D. Vu et al. / Formal Transformation from UML Sequence Diagrams to Queueing Petri Nets

The rules from 5 to 12 are shown in Fig. 3.

Rule 5.  e  Ei ;  t  T: τ(e) = t and c(t) = {z} where {z} is the set of modes in
transition t.

Rule 6. Let m ‫ א‬M be a message label associated with a local transition. Then, m
 M; o  C(p) : τ(m) = o;

Rule 7. Let ei ‫ א‬Ei and ej ‫ א‬Ej where i, j ‫ א‬I, t ‫ א‬T where t = (ei, m, ej), ei  nexti (s0i ),
ej  nextj(s0j), μi (m,ei ) = s1i and μj(m,ej) = s1j. The color set of place p0j = τ(s0j) contains
not only τ(j) but also τ(m): c(p0j) = {τ(j), τ(m)}

Rule 8. Let ei ‫ א‬Ei and ej ‫ א‬Ej where i, j ‫ א‬I, t ‫ א‬T where t = (ei, m, ej), ei  nexti(s0i),
ej  nextj(s0j), μi(m, ei) = s1i and μj(m, ej) = s1j; f {τ(m)}; z c(τ(ei)):
I+(τ(s0j),τ(ei )(f)(z))) =1

Rule 9. s  Siini‫ ׫‬Siint , f c(τ(s)), z c(τ(next(s)):

I-(τ(s),τ(nexti (s)))(f)(z) =1.

Rule 10.  s  Siint ‫ ׫‬Si end , f  (c(τ(s)), z c(τ(previous(s)):

I+(τ(s),τ(previousi (s)))(f)(z) = 1.

Rule 11. (Open workload) s  Siini ,f {τ(i),; z c(τ(next(s)):

I+(τ(s),τ(next(s)))(f)(z) = 1.

Rule 12. (Closed workload) sei  ܵ௘௡ௗ ௜

, s0i  ܵ௜௡௜
௜
where i is the instance starting
the interaction of a SD;  t  T; τ(t) =z:
I-(τ(sei ),t)(f)(z) =1; f c(τ(sei )
I+(τ(s0i ),t)(f)(z) =1; f c(τ(soi )
௝
I (τ(s0j), τ(next(s0j))(f)(z) =1; jI\{i}; s0j  ܵ௜௡௜ ; f  c(τ(soj); z c(τ(next(S0j))
+

5. Experiment and Evaluation

We have shown that our model transformation as defined is semantically correct. In

this section, we test its applicability and usability in practice. In fact, it is quite difficult
to find a detailed sequence diagram which has all the elements mentioned in the above
parts.

5.1. Case study

The cloud service described in this section illustrates the parametric transformation
technique and the associated transformation rules defined in the previous section. The
scenario is described as a set of functional asynchronization between Client, Cloud API
& Gateway and Cloud Worker Role. It is assumed that the client has already
authenticated [1].
 V.-D. Vu et al. / Formal Transformation from UML Sequence Diagrams to Queueing Petri Nets 597

Let’s consider the sequence diagram shown in Fig.4 with three instances where
events and state locations along instance lifelines are indicated explicitly. The interaction
SD Cloud Service is initiated by a local transition with the message label requestTask()
is sent from instance Client to the instance Cloud API & Gateway. Cloud API & Gateway
then executes a self-transition to get subscription information for the client and places a
new task on the instance Cloud Worker Role. In this high-level design, the client’s
subscription type (given by value s) is passed explicitly to the instance SDGetResources
as an argument and used internally as needed. Here, based on the tenancy type, the
instance of Cloud Worker Role requests resources from a Dedicated Resource or a
Shared Resource.

Figure 4. A Cloud System sequence diagram

5.2. Discussion and evaluation

All of the components in the SD in Fig. 4 are transformed into a behaviorally

equivalent QPN by the basic transformation rules defined in Section 4. By using Java,
we converted an XML file exported from a UML Sequence Diagram which designed in
Visual Paradigm [25] to another XML file denotes a QPN.
598 V.-D. Vu et al. / Formal Transformation from UML Sequence Diagrams to Queueing Petri Nets

Figure 5. The obtained QPN for the Cloud System Sequence Diagram
 V.-D. Vu et al. / Formal Transformation from UML Sequence Diagrams to Queueing Petri Nets 599

Figure 6. The obtained colors of the QPN for the Cloud System Sequence Diagram

We use a tool named QPME [13] to see the graphical view of the obtained QPN.
The application of our proposed rules are as follows:
x Rule 1 is used for naming the QPN.
x We apply rule 2 to transform the Client instance, Cloud API instance and
Cloud Worker Roll from SD to colors in the QPN.
x Rule 3 and rule 4 are applied to map all state locations in SD to places in
QPN and specify the initial marking.
x We use rule 5 to get all transitions and their modes.
x Rule 6 and 7 make a color set of places more complete.
x Two rules 8, 9 and 10 are applied to know connections between obtained
places and transitions.
x We use open workload for the case study, then rule 11 is used meanwhile
rule 12 is ignored.

Figure 5 shows the generated QPN corresponding to the cloud system sequence
diagram. For instance, in the first vertical life, there are some places Client(x) and
transitions tClient(x). They came from rule 3 and rule 5. The connections between those
places and transitions are specified by applying rule 8, 9, 10 and 11. The message 1:
requestTask is handled with related to places Client1, Client2, Cloud API & Gateway 1,
and transitions tClient (using rule 5, 7 and 8).
The target model consists of 25 places, 25 transitions, and 9 colors shown in Fig. 6.
The obtained colors of the QPN for the cloud system sequence diagram include of:
x Three colors Client, Cloud API & GateWay and Cloud Worker Role are
corresponding to three instanses in SD (rule 2).
x The remaining colors are corresponding to 6 messages in the SD (rule 6).
This result is entirely consistent with the theoretical parts presented in section 3 and
section 4.

6. Conclusion and future work

In this paper, we added the subnet parameter to the definition of QPN to define QPN
generally. We presented a collection of transformation rules from a SD model to a QPN
600 V.-D. Vu et al. / Formal Transformation from UML Sequence Diagrams to Queueing Petri Nets

model, showing that the rules guarantee two languages to be strongly consistent. Our
proposed rules guarantee a one-to-one mapping between the set of legal traces of both
Sequence Diagram and Queueing Petri Nets. We also applied a case study to prove the
effectiveness of these rulers.
The following points outline the main ideas in our future work:
x First, we formulate interaction fragment rules to transform UML Sequence
Diagrams into Queueing Petri Nets. It will be very much related to the use
of subnet in QPN.
x Second, we built a complete tool to convert SDs to QPNs automatically
based on existing rules.

References
[1] Dulani A. Meedeniya, Correct model-to-model transformation for formal verification. A Thesis Submitted
for the Degree of PhD at the University of St Andrews, (2013). https://research-repository.st-
andrews.ac.uk/handle/10023/3691
[2] Joao António Custódio Soares, Bruno Lima and Joao Pascoal Faria, Automatic Model Transformation from
UML Sequence Diagrams to Colored Petri Nets. In: 6th International Conference on Model-Driven
Engineering and Software Development MODELSWARD, (2018).
[3] Dulani Meedeniya, Indika Perera and Juliana Bowles, Tool support for transforming Unified Modelling
Language sequence diagram to colored Petri nets. Maejo International Journal of Science and
Technology, vol. 10(03), (2016), 272-283,
[4] Juliana Bowles and Dulani Meedeniya: Formal Transformation from Sequence Diagrams to Colored Petri
Nets. Asia Pacific Software Engineering Conference, IEEE Computer Society (2010), 216–225.
[5] Bowles, J. and Meedeniya, D: Parametric transformations for flexible analysis. In Proceedings of the 19 th
Asia Pacific Software Engineering Conference (APSEC ’12), IEEE Computer Society (2012), 634–643.
[6] OMG Unified Modeling Language TM (OMG UML) Version 2.5.1, December 2017 https: //www.
omg.org/spec/UML/About-UML/ last accessed 2018/04/22
[7] Samuel Kounev, Simon Spinner, J¨urgen Walter, QPME User’s Guide v2.1: A software tool for
performance modeling and analysis using queueing Petri nets, 2015.
[8] Falko Bause, Pieter S.Kritzinger, Stochastic Petri Net: An Introduction to the Theory, 2nd Edition,
Vieweg+Teubner Verlag, 2002
[9] Samuel Kounev, Simon Spinner, Philipp Meier, Introduction to Queueing Petri Nets: Modeling Formalism,
Tool Support and Case Studies, ICPE '12 Proceedings of the 3rd ACM/SPEC International Conference
on Performance Engineering, Boston, Massachusetts, USA, (2012), 9-18
[10] Tomasz Rak, Performance Modeling Using Queueing Petri Nets, International Conference on Computer
Networks (), Computer Networks (2017), 321-335
[11] Issam Al-Azzoni, ATL Transformation of Queueing Networks to Queueing Petri Nets, Proceedings of the
5th International Conference on Model-Driven Engineering and Software Development - Volume 1:
MODELSWARD, (2017), 261-268
[12] Tony Spiteri Staines , Transforming UML Sequence Diagrams into Petri Nets, Journal of Communication
and Computer 10 (2013), 72-81
[13] Samuel Kounev, Christofer Dutz, QPME - A Performance Modeling Tool Based on Queueing Petri Nets,
ACM SIGMETRICS Performance Evaluation Review 36(4) (2009),46-51
[14] Samuel Kounev and Alejandro Buchmann, On the Use of Queueing Petri Nets for Modeling and
Performance Analysis of Distributed Systems, Petri Net, Theory and Applications, Vedran Kordic (Ed.)
(2008),534-563
[15] Piotr Rygielski ; Samuel Kounev, Data Center Network Throughput Analysis using Queueing Petri Nets,
IEEE 34th International Conference on Distributed Computing Systems Workshops (ICDCSW), (2014),
100-105
[16] Tomasz Rak, Performance Analysis of Distributed Internet System Models using QPN Simulation,
Federated Conference on Computer Science and Information Systems (2014), 769–774
[17] Tomasz Rak, Response Time Analysis of Distributed Web Systems Using QPNs, Mathematical Problems
in Engineering Volume 2015, 10 pages
[18] Ribeiro O.R., Fernandes J.M, Some Rules to Transform Sequence Diagrams into Colored Petri Nets‫ څ‬, 7th
Workshop and Tutorial on Practical Use of Colored Petri Nets and the CPN Tools (CPN 2006), 237-256.
[19] Vu Van Doc, Huynh Quyet Thang, Nguyen Trong Bach, Development of the Rules for Transformationof
UML Sequence Diagrams into Queueing Petri Nets, INISCOM 2018 - 4th EA International Conference
on Industrial Networks and Intelligent Systems (2018), 122-144.
 V.-D. Vu et al. / Formal Transformation from UML Sequence Diagrams to Queueing Petri Nets 601

[20] An'an Luo ; Chuang Lin ; Kai Wang ; Fengyuan Ren ; Limin Miao, Performance Modeling and
Evaluation using Queuing Petri Nets in IMS, Communications and Networking in China, 2009
ChinaCOM 2009. Fourth International Conference on (2009), 1-5
[21] Samuel Kounev and Alejandro Buchmann, Performance Modelling of Distributed E-Business
Applications using Queueing Petri Nets. In the Proceedings of the 2003 IEEE International Symposium
on Performance Analysis of Systems and Software (ISPASS-2003)
[22] Nico de Wet; Pieter Kritzinger, Using UML models for the performance analysis of network systems,
Computer Networks: The International Journal of Computer and Telecommunications Networking
Telecommunications and UML languages, Volume 49 (2005), 627-642
[23] Steffen Becker ; Heiko Koziolek; Ralf Reussner, The Palladio component model for model-driven
performance prediction, Journal of Systems and Software Volume 82,(2009), 3-22
[24] Woodside, M., Franks, G., Petriu, The Future of Software Performance Engineering, Conference: Future
of Software Engineering, (2007), 171–187
[25] Visual Paradigm Enterprise 15.0, https://www.visual-paradigm.com/last accessed 2018/09/5

View publication stats