**3.2. Method for efficient Deployment mapping**

Deployment diagram can be used to define the execution architecture of the system by identifying the system physical components and the assignment of software artifacts to those identified physical components [11]. After designing the deployment diagram the relation between system component and collaboration will be delineated to describe the service delivered by the system. The service is delivered by the joint behavior of the system components which may be physically distributed. The necessary partial behavior of the component used to realize the collaboration is represented by the collaboration role. In this way, it is possible to expose direct mapping between the collaboration roles to the system components to show the probable deployment of service components to the physical nodes of the system [6].

We consider two design alternatives of system architecture captured by UML deployment diagram to demonstrate the relationship between collaboration and system component for the scenario mentioned in Figure 2. For our defined scenario the identified system components by the 1st variation of deployment diagram are Mobile terminal, Base transceiver station, Authentication server, Location server and Weather server. After designing the deployment diagram the relationship between system component and collaboration will be delineated to describe the service delivered by the system. The service is delivered by the joint behavior of system components which may be physically distributed. The necessary partial behavior of the components used to realize the collaboration is represented by the collaboration role. Behavior of the components Mobile terminal, Base transceiver station, Authentication server, Location server, Weather server are represented by the collaboration roles MT, BTS, AuS, LS & WS to utilize the collaboration *t: transfer, a: authenticate, l: request location info, w: request weather info*. Here it is one to one mapping between system component & collaboration role shown in Figure 7(a).

We consider other variation of deployment diagram for mentioned scenario. In this variation of deployment diagram the identified system components are mobile terminal, Base transceiver station, application server. In this case, the behavior of the components Mobile terminal and Base transceiver station is represented by the collaboration roles MT and BTS to utilize the collaboration *t: transfer* and the behavior of the component application behavior is represented jointly by the collaboration role AuS, LS and WS to utilize the collaboration *a: authenticate, l: request location info, w: request weather info*. In second case, the mapping between system component & collaboration role is generalized into one to many relations mentioned in Figure 7(b).

**Figure 7.** UML deployment diagram with service components deployment mapping

For large and complex system, conducting the deployment mapping is not straight forward like the previous cases. The deployment mapping has implication with respect to satisfying the non functional properties of the system. So we need for an approach that will be apposite for conducting the deployment mapping for complex system considering constraints and capabilities of the system components. We introduce our approach by considering the system as collection of N interconnected nodes. Our objective is to find a deployment mapping for this execution environment for a set of service components C available for deployment that comprises the service. Deployment mapping M can be defined as *M* :*C N* between a numbers of service components instances c, onto nodes n mentioned in Figure 8. A components ci C can be a client process or a service process, while a node, n N is a physical resource. Generally, nodes can have different responsibilities, such as providing services (*S1*), relaying traffic (*R1*), accommodating clients (*C1*), or a mixture of these (*SC1*). Components can communicate via a set of collaborations. We consider 3 types of requirements in the deployment problem where the term cost is introduced to capture several non-functional requirements those are later on utilized to conduct performance evaluation of the systems:

1. Components have execution costs

268 Petri Nets – Manufacturing and Computer Science

**Figure 6.** (a) Detail behavior of collaborative building block (b). Internal behavior of collaboration

Deployment diagram can be used to define the execution architecture of the system by identifying the system physical components and the assignment of software artifacts to those identified physical components [11]. After designing the deployment diagram the relation between system component and collaboration will be delineated to describe the service delivered by the system. The service is delivered by the joint behavior of the system components which may be physically distributed. The necessary partial behavior of the component used to realize the collaboration is represented by the collaboration role. In this way, it is possible to expose direct mapping between the collaboration roles to the system components to show the probable deployment of service components to the physical nodes

We consider two design alternatives of system architecture captured by UML deployment diagram to demonstrate the relationship between collaboration and system component for the scenario mentioned in Figure 2. For our defined scenario the identified system components by the 1st variation of deployment diagram are Mobile terminal, Base transceiver station, Authentication server, Location server and Weather server. After designing the deployment diagram the relationship between system component and collaboration will be delineated to describe the service delivered by the system. The service is delivered by the joint behavior of system components which may be physically distributed. The necessary partial behavior of the components used to realize the collaboration is represented by the collaboration role. Behavior of the components Mobile terminal, Base transceiver station, Authentication server, Location server, Weather server are represented by the collaboration roles MT, BTS, AuS, LS & WS to utilize the collaboration *t: transfer, a: authenticate, l: request location info, w: request weather info*. Here it is one to one mapping between system component & collaboration role shown in Figure 7(a).

We consider other variation of deployment diagram for mentioned scenario. In this variation of deployment diagram the identified system components are mobile terminal,

**3.2. Method for efficient Deployment mapping** 

of the system [6].


Performance Evaluation of Distributed System Using SPN 271

1 *E*

*<sup>X</sup>* (1)

<sup>0</sup> *q Mc n N c n M* , {| } (2)

*<sup>k</sup> j jj <sup>j</sup> F M Iq MK q MK fk* (3)

*<sup>n</sup> c m <sup>i</sup> <sup>i</sup> <sup>n</sup> <sup>l</sup> fc* . Furthermore the overall cost function F(M)

*n j nk j FM l T F M f* (4)

*<sup>i</sup> <sup>i</sup> fc* . This way, the

given deployment mapping at each node where X defines the total number of physical nodes available in the execution environment. We will strive for an optimal solution of equally distributed cost among the processing nodes and the lowest cost possible, while taking into account the execution cost *f*ci, i = 1….E, communication cost *f*kj, j = 1….K and cost for executing the background process *f*Bj, j = 1….k. *f*ci, *f*kj and *f*Bj are derived from the service

> | | 1

*E <sup>i</sup> <sup>i</sup> T fc*

1 | |

To cater for the communication cost *f*kj, of the collaboration kj in the service, the function

This means that 0 *q Mc* ( ,) returns the node *n* that hosts components in the list mapping M. Let collaboration *k cc <sup>j</sup>* 1 2 , . The communication cost of kj is 0 if components c1 and c2 are collocated, i.e. 0 10 2 *q Mc q Mc* ( ,) ( ,) , and the cost is *f*kj if components are otherwise (i.e. the collaboration is remote). Using an indicator function I(x), which is 1 if x is true and 0 otherwise, this expressed as 0 10 2 *Iq Mc q Mc* ( ( , ) ( , )) 1 , if the collaboration is remote and 0 otherwise. In order to determine which collaboration kj is remote, the set of mapping M is used. Given the indicator function, the overall communication cost of service, Fk(M), is the

> | | <sup>1</sup> 0 ,1 0 ,2 , , *<sup>k</sup>*

Given a mapping M = {mn} (where mn is the set of components at node *n* & *n* ϵ N) the total

UML is no doubt a well established language for modeling system functional behavior. But UML has lacking of incorporating non functional parameters in the model while specifying the functional behavior of any system. This needs for an approach or specification to incorporate the performance parameters in the UML for quantitative analysis. That's why we use a specification called the *UML profile for MARTE* for Modeling and Analysis of Real-Time and Embedded systems, provides support for specification, design, and verification/validation stages [1]. This new profile is intended to replace the existing UML Profile for Schedulability, Performance and Time. This specification of a UML profile adds

 | | | | 1 1 ˆ () | | *<sup>B</sup> N k*

becomes (where Ij = 1, if kj external or 0 if kj internal to a node) [15]:

**3.3. Approach for incorporating performance information** 

specification, thus the offered execution cost can be calculated as | |

logic can be aware of the target cost T [15]:

q0(M, c) is defined first [15]:

load can be obtained as ˆ

sum [15]:

**Figure 8.** Service component mapping example

Furthermore, we consider identical nodes that are interconnected each other and are capable of hosting components with unlimited processing demand. We observe the processing cost that nodes impose while host the components and also the target balancing of cost among the nodes available in the network. Communication costs are considered if collaboration between two components happens remotely, i.e. it happens between two nodes [15]. In other words, if two components are placed onto the same node the communication cost between them will not be considered. The cost for executing the background process for conducting the communication between the collaboration roles is always considerable no matter whether the collaboration roles deploy on the same or different nodes. Using the above specified input, the deployment logic provides an optimal deployment architecture taking into account the QoS requirements for the components providing the specified services. We then define the objective of the deployment logic as obtaining an efficient (lowcost, if possible optimum) mapping of components onto the nodes that satisfies the requirements in reasonable time. The deployment logic providing optimal deployment architecture is guided by the cost function F(M). The cost function is designed here to reflect the goal of balancing the execution cost and minimizing the communications cost. This is in turn utilized to achieve reduced task turnaround time by maximizing the utilization of resources while minimizing any communication between processing nodes. That will offer a high system throughput, taking into account the expected execution and inter-node communication requirements of the service components on the given hardware architecture. The evaluation of cost function F(M) is mainly influenced by our way of service definition. Service is defined in our approach as a collaboration of total E components labeled as ci (where i = 1…. E) to be deployed and total K collaborations between them labeled as kj, (where j = 1 … K). The execution cost of each service component can be labeled as *f*ci; the communication cost between the service components is labeled as *f*kj and the cost for executing the background process for conducting the communication between the service components is labeled as *f*Bj. Accordingly, we only observe the total cost ( ˆ *n l* , *n* = 1… X) ofa given deployment mapping at each node where X defines the total number of physical nodes available in the execution environment. We will strive for an optimal solution of equally distributed cost among the processing nodes and the lowest cost possible, while taking into account the execution cost *f*ci, i = 1….E, communication cost *f*kj, j = 1….K and cost for executing the background process *f*Bj, j = 1….k. *f*ci, *f*kj and *f*Bj are derived from the service specification, thus the offered execution cost can be calculated as | | 1 *E <sup>i</sup> <sup>i</sup> fc* . This way, the logic can be aware of the target cost T [15]:

270 Petri Nets – Manufacturing and Computer Science

**Figure 8.** Service component mapping example

Furthermore, we consider identical nodes that are interconnected each other and are capable of hosting components with unlimited processing demand. We observe the processing cost that nodes impose while host the components and also the target balancing of cost among the nodes available in the network. Communication costs are considered if collaboration between two components happens remotely, i.e. it happens between two nodes [15]. In other words, if two components are placed onto the same node the communication cost between them will not be considered. The cost for executing the background process for conducting the communication between the collaboration roles is always considerable no matter whether the collaboration roles deploy on the same or different nodes. Using the above specified input, the deployment logic provides an optimal deployment architecture taking into account the QoS requirements for the components providing the specified services. We then define the objective of the deployment logic as obtaining an efficient (lowcost, if possible optimum) mapping of components onto the nodes that satisfies the requirements in reasonable time. The deployment logic providing optimal deployment architecture is guided by the cost function F(M). The cost function is designed here to reflect the goal of balancing the execution cost and minimizing the communications cost. This is in turn utilized to achieve reduced task turnaround time by maximizing the utilization of resources while minimizing any communication between processing nodes. That will offer a high system throughput, taking into account the expected execution and inter-node communication requirements of the service components on the given hardware architecture. The evaluation of cost function F(M) is mainly influenced by our way of service definition. Service is defined in our approach as a collaboration of total E components labeled as ci (where i = 1…. E) to be deployed and total K collaborations between them labeled as kj, (where j = 1 … K). The execution cost of each service component can be labeled as *f*ci; the communication cost between the service components is labeled as *f*kj and the cost for executing the background process for conducting the communication between the service

components is labeled as *f*Bj. Accordingly, we only observe the total cost ( ˆ

*n*

*l* , *n* = 1… X) ofa

$$T = \frac{1}{|X|} \sum\_{i=1}^{|E|} fc\_i \tag{1}$$

To cater for the communication cost *f*kj, of the collaboration kj in the service, the function q0(M, c) is defined first [15]:

$$\mathfrak{q}\_0\left(M,\mathfrak{c}\right) = \{\mathfrak{n} \in \mathcal{N} \mid \exists \left(\mathcal{c} \to \mathcal{n}\right) \in M\}\tag{2}$$

This means that 0 *q Mc* ( ,) returns the node *n* that hosts components in the list mapping M. Let collaboration *k cc <sup>j</sup>* 1 2 , . The communication cost of kj is 0 if components c1 and c2 are collocated, i.e. 0 10 2 *q Mc q Mc* ( ,) ( ,) , and the cost is *f*kj if components are otherwise (i.e. the collaboration is remote). Using an indicator function I(x), which is 1 if x is true and 0 otherwise, this expressed as 0 10 2 *Iq Mc q Mc* ( ( , ) ( , )) 1 , if the collaboration is remote and 0 otherwise. In order to determine which collaboration kj is remote, the set of mapping M is used. Given the indicator function, the overall communication cost of service, Fk(M), is the sum [15]:

$$F\_k\left(M\right) = \sum\_{j=1}^{\left\lfloor \left\lfloor k \right\rfloor} I\left(q\_0\left(M, K\_{j,1}\right) \neq q\_0\left(M, K\_{j,2}\right)\right) \cdot fk\_j\right.\tag{3}$$

Given a mapping M = {mn} (where mn is the set of components at node *n* & *n* ϵ N) the total load can be obtained as ˆ *<sup>n</sup> c m <sup>i</sup> <sup>i</sup> <sup>n</sup> <sup>l</sup> fc* . Furthermore the overall cost function F(M) becomes (where Ij = 1, if kj external or 0 if kj internal to a node) [15]:

$$F(M) = \sum\_{n=1}^{|N|} |\hat{l}\_n - T| + F\_k \left( M \right) + \sum\_{j=1}^{|k|} f\_{\mathbb{B}\_j} \tag{4}$$

#### **3.3. Approach for incorporating performance information**

UML is no doubt a well established language for modeling system functional behavior. But UML has lacking of incorporating non functional parameters in the model while specifying the functional behavior of any system. This needs for an approach or specification to incorporate the performance parameters in the UML for quantitative analysis. That's why we use a specification called the *UML profile for MARTE* for Modeling and Analysis of Real-Time and Embedded systems, provides support for specification, design, and verification/validation stages [1]. This new profile is intended to replace the existing UML Profile for Schedulability, Performance and Time. This specification of a UML profile adds

#### 272 Petri Nets – Manufacturing and Computer Science

capabilities to UML for model-driven development of Real Time and Embedded Systems (RTES) [1].

Performance Evaluation of Distributed System Using SPN 273

2. *deadline* defines the maximum time bound on the completion of the particular execution segment that must be met. The overhead cost and communication cost between the service components are specified by this tagged value in the annotated UML model that is later on used as well by the performance model to conduct the performance evaluation.

We already mentioned that SPN model will be generated as analytical model from the UML specification style to conduct the performance evaluation. This needs for an efficient, scalable and automated approach to conduct the model transformation for large, complex and multifaceted distributed system. In this literature, the approach for efficient model transformation is realized by producing model transformation rules that can be applied in generalized way for various application domains. As we generate SPN model as analytical model we will give a brief introduction about SPN model. SPN model has the following elements: Finite set of the places (drawn as circles), finite set of the transition defined as either timed transition (drawn as thick transparent bar) or immediate transition (drawn as thin black bar), set of arcs connecting places and transition, multiplicity associated with the arcs, marking that denotes the number of token in each place. SPN model is mentioned

**K**: T → {Timed (time>0), Immediate (time = 0)} specifies the type of the each transition

**m**: Φ {0, 1, 2...} is the marking that deno → tes the number of tokens for each place in Φ. The

By utilizing the above formal representation of the SPN model, we initiate the model transformation rules that will generate SPN model from UML collaboration and activity oriented approach that captures the system functional behavior. The model transformation

*Rule 1:* The SPN model of a collaboration role is represented by the 6-tuple in the following

**3.4. Scalable and automated model transformation** 

formally by the 6-tuple {**Φ, T, A, K, N, m0**}:

**A** {Φ × T} {T × Φ} is a set of arcs connecting Φ and T

**A** = {{(Pi × do) (do × di)}, {(di × exit) (exit × Pi)}}

**N** = {(Pi × do) → 1, (do × di) → 1, (di × exit) → 1, (exit × Pi)→ 1}

**K** = (do → Timed, exit → Immediate)

**N**: A→ {1, 2, 3…} is the multiplicity associated with the arcs in A

**Φ** = Finite set of the places **T** = Finite set of the transition

initial marking is denoted as **m0**.

rules are the following:

**mo** = {(Pi → 1}, (di → 0)}

way:

**Φ**= {Pi, di} **T** = {do, exit}

MARTE defines foundations for model-based descriptions of real time and embedded systems. These core concepts are then refined for both modeling and analyzing concerns. Modeling parts provides support required from specification to detailed design of real-time and embedded characteristics of systems. MARTE concerns also model-based analysis. In this sense, the intent is not to define new techniques for analyzing real-time and embedded systems, but to support them. Hence, it provides facilities to annotate models with information required to perform specific analysis. Especially, MARTE focuses on performance and schedulability analysis. But it defines also a general analysis framework that intends to refine/specialize any other kind of analysis. Among others, the benefits of using this profile are thus [1]:


We apply several stereotypes of MARTE that permit us to map model elements into the semantics of an analysis domain such as schedulability, and give values for properties that are needed in order to carry out the analysis [1]. Specific tagged values are also applied. Tagged values are a kind of value slots associated with attributes of specific UML stereotypes [1]. In order to annotate the UML diagram we use several stereotypes and tag values according to the UML profile for MARTE. The stereotypes are the following [1]:


The tagged values are the following [1]:

1. *execTime*: The duration of the execution time is mentioned by the tagged value *execTime*  which is the average time in our case. The execution cost of service component is expressed by this tagged value in the annotated UML model that is later on used by the performance model to conduct the performance evaluation.

2. *deadline* defines the maximum time bound on the completion of the particular execution segment that must be met. The overhead cost and communication cost between the service components are specified by this tagged value in the annotated UML model that is later on used as well by the performance model to conduct the performance evaluation.

#### **3.4. Scalable and automated model transformation**

We already mentioned that SPN model will be generated as analytical model from the UML specification style to conduct the performance evaluation. This needs for an efficient, scalable and automated approach to conduct the model transformation for large, complex and multifaceted distributed system. In this literature, the approach for efficient model transformation is realized by producing model transformation rules that can be applied in generalized way for various application domains. As we generate SPN model as analytical model we will give a brief introduction about SPN model. SPN model has the following elements: Finite set of the places (drawn as circles), finite set of the transition defined as either timed transition (drawn as thick transparent bar) or immediate transition (drawn as thin black bar), set of arcs connecting places and transition, multiplicity associated with the arcs, marking that denotes the number of token in each place. SPN model is mentioned formally by the 6-tuple {**Φ, T, A, K, N, m0**}:

**Φ** = Finite set of the places

272 Petri Nets – Manufacturing and Computer Science

using this profile are thus [1]:

following [1]:

verification, code generation, etc.

system resources are made.

The tagged values are the following [1]:

according to a specific access control policy [1].

performance model to conduct the performance evaluation.

hardware and software characteristics.

(RTES) [1].

capabilities to UML for model-driven development of Real Time and Embedded Systems

MARTE defines foundations for model-based descriptions of real time and embedded systems. These core concepts are then refined for both modeling and analyzing concerns. Modeling parts provides support required from specification to detailed design of real-time and embedded characteristics of systems. MARTE concerns also model-based analysis. In this sense, the intent is not to define new techniques for analyzing real-time and embedded systems, but to support them. Hence, it provides facilities to annotate models with information required to perform specific analysis. Especially, MARTE focuses on performance and schedulability analysis. But it defines also a general analysis framework that intends to refine/specialize any other kind of analysis. Among others, the benefits of

1. Providing a common way of modeling both hardware and software aspects of an RTES

2. Enabling interoperability between development tools used for specification, design,

3. Fostering the construction of models that may be used to make quantitative predictions regarding real-time and embedded features of systems taking into account both

We apply several stereotypes of MARTE that permit us to map model elements into the semantics of an analysis domain such as schedulability, and give values for properties that are needed in order to carry out the analysis [1]. Specific tagged values are also applied. Tagged values are a kind of value slots associated with attributes of specific UML stereotypes [1]. In order to annotate the UML diagram we use several stereotypes and tag values according to the UML profile for MARTE. The stereotypes are the

1. *saStep* is a kind of step that begins and ends when decisions about the allocation of

2. *ComputingResource* represents either virtual or physical processing devices capable of storing and executing program code. Hence its fundamental service is to compute. 3. *Scheduler* is defined a kind of ResourceBroker that brings access to its brokered ProcessingResource or resources following a certain scheduling policy mentioned by tag value *schedPolicy.* The ResourceBroker is a kind of resource that is responsible for allocation and de-allocation of a set of resource instances (or their services) to clients

1. *execTime*: The duration of the execution time is mentioned by the tagged value *execTime*  which is the average time in our case. The execution cost of service component is expressed by this tagged value in the annotated UML model that is later on used by the

in order to improve communication between developers.

**T** = Finite set of the transition

**A** {Φ × T} {T × Φ} is a set of arcs connecting Φ and T

**K**: T → {Timed (time>0), Immediate (time = 0)} specifies the type of the each transition

**N**: A→ {1, 2, 3…} is the multiplicity associated with the arcs in A

**m**: Φ {0, 1, 2...} is the marking that deno → tes the number of tokens for each place in Φ. The initial marking is denoted as **m0**.

By utilizing the above formal representation of the SPN model, we initiate the model transformation rules that will generate SPN model from UML collaboration and activity oriented approach that captures the system functional behavior. The model transformation rules are the following:

*Rule 1:* The SPN model of a collaboration role is represented by the 6-tuple in the following way:

**Φ**= {Pi, di} **T** = {do, exit} **A** = {{(Pi × do) (do × di)}, {(di × exit) (exit × Pi)}} **K** = (do → Timed, exit → Immediate) **N** = {(Pi × do) → 1, (do × di) → 1, (di × exit) → 1, (exit × Pi)→ 1} **mo** = {(Pi → 1}, (di → 0)}

Performance Evaluation of Distributed System Using SPN 275

*Rule 3:* The SPN model of a collaboration where collaboration connects only two collaboration roles those deploy on the same physical node can be represented by the 6-

**A** = {(Pi × doi) (doi × di), (PPn × doi) (doi × PPn), (di × tij) (tij × Pi), (Pj × doj) (doj × dj),

**N**= {((Pi × doi), (doi × di), (PPn × doi), (doi × PPn), (di × tij), (tij × Pi), (Pj × doj), (doij × dj), (PPn ×

Here timed transition **tij** in the SPN model is only realized by the overhead cost as service components *i* and *j* deploy on the same physical node which makes the communication cost

The SPN model of a collaboration where collaboration connects only two collaboration roles those deploy on the different physical node can be represented by the 6-tuple in the

**A** = {(Pi × doi) (doi × di), (PPn × doi) (doi × PPn), (di × tij) (tij × Pi), (Pj × doj) (doj × dj),

tuple in the following way in Figure 11:

(PPn × doj) (doj × PPn), (dj × tij) (tij × Pj)}

**mo** = {(Pi→ 1), (di → 0), (Pj→ 1) (dj → 0), (PPn → q)}

doj), (doj × PPn), (dj × tij), (tij × Pj)) → 1}

**Figure 11.** Model transformation rule 3

(PPm × doj) (doj × PPm), (dj × tij) (tij × Pj)}

following way in Figure 11:

**Φ**= {Pi, di, Pj, dj PPn, PPm}

**T**= {doi, doj, tij}

**Φ**= {Pi, di, Pj, dj PPn}

**K** = {(doi, doj, tij) → Timed}

**T**= {doi, doj,tij}

= 0.

**Figure 9.** Model transformation rule 1

SPN model of a collaboration role is mentioned in Figure 9 (where Pi = Processing of ith collaboration role and di = Processing done of the ith collaboration role).

*Rule 2:* When the collaboration role of a building block deploys onto a physical node the equivalent SPN model is represented by 6-tuple in following way:

**Φ**= {Pi, di, PPn}

**T**= {do, exit}

**A** = {{(Pi × do) (do × di)}, {(PPn × do) (do × PPn)}, {(di × exit) (exit × Pi)}}

**K** = (do → Timed, exit → Immediate)

$$\mathbf{N} = \{ (\mathbf{P}\_{\mathbf{i}} \times \mathbf{do}) \xrightarrow{\sim} \mathbf{1}, \, (\mathbf{do} \times \mathbf{di}) \xrightarrow{\sim} \mathbf{1}, \, (\mathbf{PP}\_{\mathbf{n}} \times \mathbf{do}) \xrightarrow{\sim} \mathbf{1}, \, (\mathbf{do} \times \mathbf{PP}\_{\mathbf{n}}) \xrightarrow{\sim} \mathbf{1} \, (\mathbf{di} \times \mathbf{exit}) \xrightarrow{\sim} \mathbf{1}, \, (\mathbf{exit} \times \mathbf{P}\_{\mathbf{i}}) \xrightarrow{\sim} \mathbf{1}$$

$$\mathbf{m}\_{\bullet} = \{ (\mathbf{P}\_{\mathbf{i}} \rightharpoonup 1), (\mathbf{d}\_{\mathbf{i}} \rightharpoonup 0), (\mathbf{P}\_{\mathbf{i}} \rightharpoonup \mathbf{q}) \}$$

Initially place PPn contains **q** (where integer **q** > 0) tokens which define the upper bound of the execution of the process in parallel by a physical node *n* and the timed transition *do* will fire only when there is a token available in both the place Pi and PPn. The place PPn will again get back it's token after firing of the timed transition *do* indicating that the node is ready to execute other processes deployed on that physical node. The equivalent SPN model when a collaboration role deploy on a physical node is mentioned in Figure 10:

**Figure 10.** Model transformation rule 2

*Rule 3:* The SPN model of a collaboration where collaboration connects only two collaboration roles those deploy on the same physical node can be represented by the 6 tuple in the following way in Figure 11:

$$\boldsymbol{\Phi} = \{ \mathbf{P}\_{\mathsf{i}} \ \mathsf{d}\_{\mathsf{i}} \ \mathsf{P}\_{\mathsf{i}} \ \mathsf{d}\_{\mathsf{i}} \ \mathsf{P} \mathbf{P}\_{\mathsf{n}} \}$$

**T**= {doi, doj,tij}

274 Petri Nets – Manufacturing and Computer Science

**Figure 9.** Model transformation rule 1

**K** = (do → Timed, exit → Immediate)

**mo** = {(Pi→ 1}, (di → 0), (PPn → q)}

**Figure 10.** Model transformation rule 2

**Φ**= {Pi, di, PPn}

**T**= {do, exit}

SPN model of a collaboration role is mentioned in Figure 9 (where Pi = Processing of ith

*Rule 2:* When the collaboration role of a building block deploys onto a physical node the

**N**= {(Pi × do) → 1, (do × di) → 1, (PPn × do) → 1, (do × PPn) → 1(di × exit) → 1, (exit × Pi)→ 1}

Initially place PPn contains **q** (where integer **q** > 0) tokens which define the upper bound of the execution of the process in parallel by a physical node *n* and the timed transition *do* will fire only when there is a token available in both the place Pi and PPn. The place PPn will again get back it's token after firing of the timed transition *do* indicating that the node is ready to execute other processes deployed on that physical node. The equivalent SPN model

collaboration role and di = Processing done of the ith collaboration role).

**A** = {{(Pi × do) (do × di)}, {(PPn × do) (do × PPn)}, {(di × exit) (exit × Pi)}}

when a collaboration role deploy on a physical node is mentioned in Figure 10:

equivalent SPN model is represented by 6-tuple in following way:

**A** = {(Pi × doi) (doi × di), (PPn × doi) (doi × PPn), (di × tij) (tij × Pi), (Pj × doj) (doj × dj), (PPn × doj) (doj × PPn), (dj × tij) (tij × Pj)}

**K** = {(doi, doj, tij) → Timed}

**N**= {((Pi × doi), (doi × di), (PPn × doi), (doi × PPn), (di × tij), (tij × Pi), (Pj × doj), (doij × dj), (PPn × doj), (doj × PPn), (dj × tij), (tij × Pj)) → 1}

$$\mathbf{m}\_{\bullet} = \{ (\mathbf{P}\_{\mathbf{i}} \rightharpoonup \mathbf{1}), (\mathbf{d}\_{\bullet} \rightharpoonup \mathbf{0}), (\mathbf{P}\_{\mathbf{i}} \rightharpoonup \mathbf{1}) \text{ (d)} \rightharpoonup \mathbf{0} \text{ (PP}\_{n} \rightharpoonup \mathbf{q})\}$$

Here timed transition **tij** in the SPN model is only realized by the overhead cost as service components *i* and *j* deploy on the same physical node which makes the communication cost = 0.

**Figure 11.** Model transformation rule 3

The SPN model of a collaboration where collaboration connects only two collaboration roles those deploy on the different physical node can be represented by the 6-tuple in the following way in Figure 11:

**Φ**= {Pi, di, Pj, dj PPn, PPm}

**T**= {doi, doj, tij}

**A** = {(Pi × doi) (doi × di), (PPn × doi) (doi × PPn), (di × tij) (tij × Pi), (Pj × doj) (doj × dj), (PPm × doj) (doj × PPm), (dj × tij) (tij × Pj)}

**K** = {(doi, doj, tij) → Timed}

**N**= {((Pi × doi), (doi × di), (PPn × doi), (doi × PPn), (di × tij), (tij × Pi), (Pj × doj), (doij × dj), (PPm × doj), (doj × PPm), (dj × tij), (tij × Pj)) → 1}

Performance Evaluation of Distributed System Using SPN 277

Fk(M) = 0 (defined in section 3.2.); as in this case processes connected by the

Now we evaluate the cost between each pair of subnet with respect to the subnet's own processing cost, overhead cost and the cost associated with the communication with other

Csnpy = cost of the yth subnet pair (y = 1….n; n is the total number of subnet pair in the

Fk(M) = 1 (defined in section 3.2.2); as in this case processes connected by the

As a representative example, we consider the scenario dealing with heuristically clustering of modules and assignment of clusters to nodes [15, 17]. This scenario is sufficiently complex to show the applicability of our performance modeling framework. The problem is defined in our approach as a service of collaboration of *E* = 10 components or collaboration roles (labeled *C1 . . . C10*) to be deployed and *K* = 14 collaborations between them depicted in Figure 12. We consider three types of requirements in this specification. Besides the execution cost, communication cost and overhead cost, we have a restriction on components *C2, C7, C9* regarding their location. They must be bound to nodes *n***2***, n***1***, n***3,** respectively. The internal behavior of the collaboration *Ki* of our example scenario is realized by the call behavior action through same UML activity diagram mentioned in Figure 6(b). The detail behavior of the collaboration role *C* is realized through same UML activity diagram already illustrated in Figure 6(a). However, there is no behavior modeled in detail, only that collaboration between processes deployed on different physical nodes. The UML collaboration diagram can be modeled by the activity that may model the detail behavior but the level of details must be selected with care in order for the model to scale while generating the performance model.

In this example, the target environment consists only of *N* = 3 identical, interconnected nodes with a single provided property, namely processing power and with infinite communication capacities depicted in Figure 13. The optimal deployment mapping can be observed in Table. 1. The lowest possible deployment cost, according to equation (4) is 17 +

network where each subnet pair corresponds between two subnets)

Csni , Csni = cost of the ith and jth subnet (where (i, j) ϵ x and i≠j)

collaboration deploy on the different physical nodes

max , *<sup>B</sup>* ( )} *Csnp Csn Csn f F M x ij j <sup>k</sup>* (6)

*C Net Csnp Csnp* \_ max ,....,...., <sup>1</sup> *<sup>n</sup>* (7)

*E N Throughput C Net* (8)

( ) \_

collaboration deploy on the same physical node

subnet in the network.

**4. Case study** 

100 + 70 = 187 [15, 17].

Here:

**mo** = {(Pi→ 1), (di → 0), (Pj→ 1), (dj → 0), (PPn → q), (PPm → q)}

Here timed transition **tij** in the SPN model is realized by both the overhead cost and communication cost as service components *i* and *j* deploy on the different physical node.

#### **3.5. Performance model Evaluation**

We focus on measuring the throughput of the system from the developed SPN model. We are interested in throughput calculation as a measure of job that a system can process in a given time period which in turn justify the efficiency of our deployment logic mentioned in section 3.2 in accordance with system performance evaluation. Before deriving formula for throughput estimation, we consider several assumptions that will allow us to determine the parameters necessary for the throughput calculation of our system.


The above assumption is important for retrieving the parameters necessary for the throughput calculation from our system specification. We define the throughput as function of expected number of jobs in the system, E(N) and cost of the network, C\_Net which defines the time required to complete the expected number of jobs in the system. The value of E(N) is calculated by solving the SPN model using SHARPE [16]. Cost of the network, C\_Net is defined in the following: First the cost of a subnet (Csn) will be calculated as follows:

$$\text{Csn}\_{\text{x}} = \sum\_{i=1}^{|m|} f \mathbf{c}\_{i} + \max \left\{ f\_{\mathbb{B}\_{j}} \right\} + F\_{k} \text{ (M)}$$

$$= \sum\_{i=1}^{|m|} f \mathbf{c}\_{i} + \max \left\{ f\_{\mathbb{B}\_{j}} \right\} \tag{5}$$

Here:


 Fk(M) = 0 (defined in section 3.2.); as in this case processes connected by the collaboration deploy on the same physical node

Now we evaluate the cost between each pair of subnet with respect to the subnet's own processing cost, overhead cost and the cost associated with the communication with other subnet in the network.

$$\text{Csn}p\_x = \left\{ \max\left( \text{Csn}\_{i'}, \text{Csn}\_{j} \right) \right\} + f\mathbf{s}\_j + F\_k \text{ (M)}\} \tag{6}$$

Here:

276 Petri Nets – Manufacturing and Computer Science

doj), (doj × PPm), (dj × tij), (tij × Pj)) → 1}

**3.5. Performance model Evaluation** 

2. All the communications occur in parallel.

follows:

Here:

comprises the network)

collaboration in the xth subnet)

collaboration in the xth subnet)

 *f*ci *=* execution cost of the ith process of the xth subnet

 *m* = total number of service components deployed on the xth subnet

**mo** = {(Pi→ 1), (di → 0), (Pj→ 1), (dj → 0), (PPn → q), (PPm → q)}

parameters necessary for the throughput calculation of our system.

1. Executions of the processes occur independently each other.

**N**= {((Pi × doi), (doi × di), (PPn × doi), (doi × PPn), (di × tij), (tij × Pi), (Pj × doj), (doij × dj), (PPm ×

Here timed transition **tij** in the SPN model is realized by both the overhead cost and communication cost as service components *i* and *j* deploy on the different physical node.

We focus on measuring the throughput of the system from the developed SPN model. We are interested in throughput calculation as a measure of job that a system can process in a given time period which in turn justify the efficiency of our deployment logic mentioned in section 3.2 in accordance with system performance evaluation. Before deriving formula for throughput estimation, we consider several assumptions that will allow us to determine the

3. Finally the communications between interconnected nodes will be started following the completion of all the processing and communication inside each physical node.

The above assumption is important for retrieving the parameters necessary for the throughput calculation from our system specification. We define the throughput as function of expected number of jobs in the system, E(N) and cost of the network, C\_Net which defines the time required to complete the expected number of jobs in the system. The value of E(N) is calculated by solving the SPN model using SHARPE [16]. Cost of the network, C\_Net is defined in the following: First the cost of a subnet (Csn) will be calculated as


Csnx = cost of the xth subnet (where x = 1….n; n is the total number of subnet that

*f*Bj = overhead cost of collaboration j (where j =1….n; n is the total number of

 *f*kj = communication cost of collaboration j (where j =1….n; n is the total number of

*x i jk <sup>i</sup> Csn fc f F M*

 | | <sup>1</sup> max *<sup>B</sup>*

*m*

*m*

<sup>1</sup> max ( ) *<sup>B</sup>*

*i j <sup>i</sup> fc f* (5)

**K** = {(doi, doj, tij) → Timed}


$$\mathbb{C}\\_Net = \max\left\{ \mathbb{C}sup\_1, \dots, \dots, \mathbb{C}sup\_n \right\} \tag{7}$$

$$Throughput = \frac{E(N)}{C\_{-}Net} \tag{8}$$

#### **4. Case study**

As a representative example, we consider the scenario dealing with heuristically clustering of modules and assignment of clusters to nodes [15, 17]. This scenario is sufficiently complex to show the applicability of our performance modeling framework. The problem is defined in our approach as a service of collaboration of *E* = 10 components or collaboration roles (labeled *C1 . . . C10*) to be deployed and *K* = 14 collaborations between them depicted in Figure 12. We consider three types of requirements in this specification. Besides the execution cost, communication cost and overhead cost, we have a restriction on components *C2, C7, C9* regarding their location. They must be bound to nodes *n***2***, n***1***, n***3,** respectively. The internal behavior of the collaboration *Ki* of our example scenario is realized by the call behavior action through same UML activity diagram mentioned in Figure 6(b). The detail behavior of the collaboration role *C* is realized through same UML activity diagram already illustrated in Figure 6(a). However, there is no behavior modeled in detail, only that collaboration between processes deployed on different physical nodes. The UML collaboration diagram can be modeled by the activity that may model the detail behavior but the level of details must be selected with care in order for the model to scale while generating the performance model.

In this example, the target environment consists only of *N* = 3 identical, interconnected nodes with a single provided property, namely processing power and with infinite communication capacities depicted in Figure 13. The optimal deployment mapping can be observed in Table. 1. The lowest possible deployment cost, according to equation (4) is 17 + 100 + 70 = 187 [15, 17].

#### 278 Petri Nets – Manufacturing and Computer Science

Performance Evaluation of Distributed System Using SPN 279

– T | Internal collaborations

17 100 117

(Figure 14) as collaborations in example scenario are associated with two kinds of cost:


By considering the above deployment mapping and the transformation rules, the corresponding SPN model of our example scenario is depicted in Figure 15. Figure 15 sketches the resulting SPN model by illustrating details of all the places and transitions. According to the transformation rule 1, each collaboration role is defined by the two places *Pi* and *di* and the passing of token from place *Pi* to *di* is realized by the timed transition *ti*

n1 c4, c7, c8 70 2 k8, k9 n2 c2, c3, c5 60 8 k3, k4 n3 c1, c6, c9, c10 75 7 k11, k12, k14

*l*

*l*

communication cost and overhead cost.

Node Components *<sup>n</sup>*

∑ cost

**Figure 15.** SPN model of our example scenario

**Table 1.** Optimal deployment mapping in the example scenario [15, 17]

**Figure 12.** Collaborations and components in the example scenario

**Figure 13.** The target network of hosts

**Figure 14.** Annotated UML model

In order to annotate the UML diagram in Figure 12 and 13 we use the stereotypes *saStep, computingResource, scheduler* and the tag values *execTime, deadline* and *schedPolicy* which are already described in section 3.3. Collaboration *Ki* is associated with two instances of *deadline*


(Figure 14) as collaborations in example scenario are associated with two kinds of cost: communication cost and overhead cost.

278 Petri Nets – Manufacturing and Computer Science

**Figure 12.** Collaborations and components in the example scenario

In order to annotate the UML diagram in Figure 12 and 13 we use the stereotypes *saStep, computingResource, scheduler* and the tag values *execTime, deadline* and *schedPolicy* which are already described in section 3.3. Collaboration *Ki* is associated with two instances of *deadline*

**Figure 13.** The target network of hosts

**Figure 14.** Annotated UML model

By considering the above deployment mapping and the transformation rules, the corresponding SPN model of our example scenario is depicted in Figure 15. Figure 15 sketches the resulting SPN model by illustrating details of all the places and transitions. According to the transformation rule 1, each collaboration role is defined by the two places *Pi* and *di* and the passing of token from place *Pi* to *di* is realized by the timed transition *ti*

**Figure 15.** SPN model of our example scenario

**Table 1.** Optimal deployment mapping in the example scenario [15, 17]

which is derived from the annotated UML model. Initially, there will be a token from place *P1* to *P10*. According to rule 2, in order to define the upper bound of the execution of parallel processes by a network node, we introduce three places *PP1*, *PP2* and *PP3* in the SPN model for the corresponding three physical nodes and initially, these three places will contain *q* (*q* > 0) tokens where *q* will define the maximum number of the process that will be handled in parallel by a physical node at certain time. In order to ensure the upper bound of the parallel processing of a network node *n1*, we introduce arcs from place *PP1* to transition *t4*, *t7* and *t8*. That means, components *C4*, *C7* and *C8* can start their processing if there is token available in place *PP1* as the firing of transitions *t4*, *t7* and *t8* not only depend on the availability of the token in the place *P4*, *P7* and *P8* but also depend on the availability of the token in the place *PP1*. Likewise, to ensure the upper bound of the parallel processing of a network node *n2* and *n***3**, we introduce arcs from place *PP2* to transition *t2*, *t3* and *t5* and from place *PP3* to transition *t1, t6, t9, t10*.

Performance Evaluation of Distributed System Using SPN 281

calculation though we present here the throughput calculation of some of the deployment mappings of the software artifacts but obviously, the approach presented here confirms the

**Deployment Mapping Possible total cost Throughput n1 n2 n3** *{c4, c7, c8} {c2, c3, c5} {c1, c6, c9, c10} 187 (min) 0.0663 (max)*  { c4, c7}, {c2, c3, c5, c6,} {c1, c8, c9, c10} 232 0.0603 {c4, c6, c7, c8} {c2, c3, c5} {c1, c9, c10} 218 0.0575 {c5, c7, c8} {c2, c3, c4} { c1, c6, c9, c10} 227 0.0574 {c1, c6, c7, c8} {c2, c3, c4} {c5, c9, c10} 247 0.0545 { c3, c7, c8} {c2, c4, c5} {c1, c6, c9, c10} 252 0.0538 {c4, c7, c8} { c1, c2, c3, c5} { c6, c9, c10} 217 0.0532 { c1, c6, c7, c8} {c2, c3, c5} { c4, c9, c10}} 257 0.052 {c3, c6, c7, c8} {c1, c2, c4, c5}, {c9, c10} 302 0.0469 {c6, c7, c8} { c1, c2, c4, c5} {c3, c9, c10}} 288 0.0464

The contribution of this chapter is to develop a framework that focuses on the performance evaluation of the distributed system using SPN model. The developed framework recognizes the fact of rapid and efficient way of capturing the system dynamics utilizing reusable specification of software components that has been utilized to generate SPN performance model. The deployment logic presented here, is applied to provide the optimal, initial mapping of components to hosts, i.e. the network is considered rather static. Performance related QoS information is taken into account and included in the SPN model with equivalent timing and probabilistic assumption for enabling the evaluation of performance prediction result of the system at the early stage of the system development process. However, our eventual goal is to develop support for run-time redeployment of components, this way keeping the service within an allowed region of parameters defined by the requirements. Our modeling framework support that, our logic will be a prominent candidate for a robust and adaptive service execution platform for assessing a deployment of service components on an existing physical topology. Future work includes providing a

**Table 2.** Deployment mapping in the example scenario along with throughput

tool based support of the developed performance modeling framework.

*Norwegian University of Science & Technology, Trondheim, Norway* 

optimality.

**5. Conclusion** 

**Author details** 

Kazi Wali Ullah

Razib Hayat Khan and Poul E. Heegaard

*Aalto University, Helsinki, Finland* 

For generating the SPN model from annotated UML model, firstly, we will consider the collaboration roles deploy on the processor node *n1* which are *C4*, *C7* and *C8*. Here components *C7* connects to *C4* and *C8*. The communication cost between the components is zero but there is still cost for execution of the background process. So according to rule 3, after the completion of the transition from place *P7* to *d7* (places of component *C7*), from *P4* to *d4* (places of component *C4*) and from *P8* to *d8* (places of component *C8*) the places *d7*, *d4* and *d7*, *d8* are connected by the timed transition *k8* and *k9* to generate the SPN model. Collaboration roles *C2*, *C3* and *C5* deploy on the processor node *n2*. Likewise, after the completion of the transition from place *P2* to *d2* (places of component *C2*), from *P3* to *d3* (places of component *C3*) and from *P5* to *d5* (places of component *C5*) the places *d2*, *d3* and *d2*, *d5* are connected by the timed transition *k3* and *k4* to generate the SPN model according to rule 3. Collaboration roles *C6*, *C1*, *C9* and *C10* deploy on the processor node *n3*. In the same way, after the completion of the transition from place *P1* to *d1* (places of component *C*1), from *P6* to *d6* (places of component *C6*), *P9* to *d9* (places of component *C9*) and from *P10* to *d10* (places of component *C10*) the places *d1*, *d6*; *d1*, *d9* and *d9*, *d10* are connected by the timed transition *k11*, *k12* and *K14* to generate the SPN model following rule 3. In order to generate the system level SPN model we need to combine the entire three SPN model generated for three processor nodes by considering the interconnection among them. In order to compose the SPN models of processor node *n1* and *n2*, places *d4* and *d3* are connected by the timed transition *k1* and places *d4* and *d5* are connected by the timed transition *k2* according to rule 3. Likewise, to compose the SPN models of processor node *n2* and *n3*, places *d2* and *d1* are connected by the timed transition *k5* and places *d5* and *d1* are connected by the timed transition *k6* according to rule 3. In order to compose the SPN models of processor node *n1* and *n3*, places *d7* and *d1* are connected by the timed transition *k7*, places *d8* and *d6* are connected by the timed transition *k10* and places *d8* and *d9* are connected by the timed transition *k13* according to rule 3. By the above way, the system level SPN model is derived and all these are done automatically. The algorithm for automatic generation of SPN model from the annotated UML model is beyond the scope of this chapter.

The throughput calculation according to equation (8) for the different deployment mapping including the optimal deployment mapping is shown in Table 2. The optimal deployment mapping presented in Table 1 (first entry) also ensures the optimality in case of throughput


calculation though we present here the throughput calculation of some of the deployment mappings of the software artifacts but obviously, the approach presented here confirms the optimality.

**Table 2.** Deployment mapping in the example scenario along with throughput
