**3.1. Capturing system functional behavior**

We use UML collaboration as main specification unit to specify system functional behavior. The UML standard focuses in particular on the structural aspects of UML collaborations. UML does not, however, elaborate detailed semantics of the behavioral implications of the structural composition. Collaborations are intended as a context in which behaviors may be defined. Compared to the other uses of collaborations, and what we need, this is an obvious shortcoming. We will later see how a combination of collaborations with activities may solve this problem [9].

Collaboration is an illustration of the relationship and interaction among software objects in the UML. Objects are shown as rectangles with naming label inside. The relationships between the objects are shown as line connecting the rectangles [11]. As a representative example, we introduce a scenario description utilizing UML collaboration 2. Several users equipped with cell phone or smart phone want to receive weather information of their current location using his/her hand held device. The user request is first transferred to authentication server through base transceiver station to ensure the authenticity of the user. Thereafter, the request of the legitimate user is transferred to the location server to retrieve the location information of the user. The location information is then transferred to weather server for retrieving the weather information according to the location of the user. Figure 2 defines this scenario as UML 2 collaboration. Participants in the system are users, mobile terminals, base transceiver stations, authentication servers, location servers, weather servers which are represented by the collaboration roles user, MT, BTS, AuS, LS, and WS. The users are the part of the environment and therefore labeled as <<external>>.The default multiplicity of the users, mobile terminals, base transceiver stations, authentication servers, location servers, weather servers are one to many, which are denoted by (1..\*). The interactions between the collaboration roles are represented by the collaboration such as mobile terminal and BTS interact through *t*: *transfer*, BTS and authentication server, location server, weather server interact successively through *a*: *authenticate, l: request location info, w: request weather info,* while the user interacts with the mobile terminal by collaboration *g*: *generate request* [6].

**Figure 2.** Collaboration diagram

262 Petri Nets – Manufacturing and Computer Science

Capturing system functional behavior

which at the end reflects the aim of this chapter.

**Figure 1.** Performance modeling framework

**3. Performance modeling framework** 

**3.1. Capturing system functional behavior** 

The following Figure 1 mentions the requirements or factors that we need to consider for the successful performance evaluation of the distributed software systems. In order to capture all the above mentioned factors, it needs an efficient approach or developing a framework that will allow rapid and successful performance evaluation of distributed software system

> Method for effecient deployment mapping

> > Scalable & automated model transformation

> > > Analytical model

Performance result

Approach for incorporating performance information

We already mentioned our main objective in the previous section that will be presented broadly in this section. In order to achieve the main objective, we need to follow an engineering approach that will accelerate the distributed software system development process. We also need to define the method that will be accounted for evaluating the system performance. We limit ourselves to methods targeting system development process using the standards of UML (Unified Modeling Languages) [9]. In the evaluation side we limit ourselves to methods that will analytically solve our problem using the technique SPN (Stochastic Petri Nets). This section mainly presents these two main techniques and also focuses on their

We use UML collaboration as main specification unit to specify system functional behavior. The UML standard focuses in particular on the structural aspects of UML collaborations. UML does not, however, elaborate detailed semantics of the behavioral implications of the

properties that will be utilized to design our performance modeling framework.

The specifications for collaborations are given as coherent, self-contained reusable building blocks. The internal behavior of building block is described by the UML activity. It is declared as the classifier behavior of the collaboration and has one activity partition for each collaboration role in the structural description [6]. For each collaboration, the activity declares a corresponding call behavior action refereeing to the activities of the employed building blocks. Depending on the number of participants, connectivity to other blocks and level of decomposition, we distinguish three different kinds of building blocks [10]:

Performance Evaluation of Distributed System Using SPN 265

Hereby collaborations of Figure 2 are modeled by a call behavior action referring to the activity describing the behavior of the corresponding collaboration [10]. Activity diagram presents complete behavior in a quite compact form and may define connections to other behaviors via input and output pins [6]. Here we specify the behavior of one user request to show how the request is generated from his/her mobile terminal and served by the BTS, authentication server, location server and weather server and later on, compose this behavior to show how the requests will be processed by the BTS, authentication servers, location servers and weather servers so that the overall system behavior can be delineated. The activity *transfer* describes the behavior of the corresponding collaboration shown in Figure 3 (a). It has one partition for each collaboration role: mobile terminal (MT) and base transceiver station (BTS). Activities base their semantics on token flow [1]. The system starts by placing a token in the initial node of the mobile terminal when one request is generated by the user through his/her mobile terminal. The token is then transferred to the BTS where it moves through the fork node generating two flows. One flow places a token in the waiting decision node *w* which is the extension of a decision node with the difference that it may hold a token similar to an initial node, as defined in [1]. *w* is used in combination with join nodes *j1* and *j2* to explicitly model the acceptance or rejection of the user request based on the user authenticity. The other flow is forwarded as input to the authentication server to check whether the user is legitimate to generate service request. If the user is legitimate to generate the request a token is offered to the join node *j1*. If *w* still has its token *j1* can fire which emits a token which then forwarded to the location server for further processing. If the user is not legitimate to generate the request, a token is offered to the join node *j2*. If *w* still has its token *j2* can fire notifying the user upon the cancellation of request and then

In order to validate the user identity (mobile number in this case) provided by a user who requests for service, BTS participates in the collaboration *authenticate* together with the authentication server. This is specified by collaboration *a: authenticate* where BTS plays the role of client and the authentication server plays the role of server. The behavior of the collaboration defined by the UML activity which is divided into two partitions, one for each collaboration role: client & server shown in Figure 3(b). The activity is started on the client side, when user id is provided as parameter *u\_id* at the input pin. The input is then directly sent to the server, where it is converted into a database request in the call behavior action *processing*. Thereafter, it is the task of the collaboration between the server and the database to provide the stored user information. In order to get the information, the request leaves the activity *authenticate* and the server waits for the reception of the response. This is modeled with the input and output pins *request* and *response*. Depending on the validity of the user id, the server may decide to report *ok* or *nok* (not ok) to the client by the call behavior action *validate*. The result is then forwarded to the corresponding output pin in the client side and the activity is terminated. The semantics of all the pins are given in [12]. Likewise, we can describe the behavior of collaboration *l: Request Location info* ( shown in Figure 3(c)) and w: *Request Weather info* through activity partition of client and server where BTS plays the role of client and location server and weather server play the role of server to

deliver the requested information to the user through his/her mobile terminal.

terminates the activity.


**Figure 3.** Activity diagram for expressing the internal behavior of collaboration

Hereby collaborations of Figure 2 are modeled by a call behavior action referring to the activity describing the behavior of the corresponding collaboration [10]. Activity diagram presents complete behavior in a quite compact form and may define connections to other behaviors via input and output pins [6]. Here we specify the behavior of one user request to show how the request is generated from his/her mobile terminal and served by the BTS, authentication server, location server and weather server and later on, compose this behavior to show how the requests will be processed by the BTS, authentication servers, location servers and weather servers so that the overall system behavior can be delineated. The activity *transfer* describes the behavior of the corresponding collaboration shown in Figure 3 (a). It has one partition for each collaboration role: mobile terminal (MT) and base transceiver station (BTS). Activities base their semantics on token flow [1]. The system starts by placing a token in the initial node of the mobile terminal when one request is generated by the user through his/her mobile terminal. The token is then transferred to the BTS where it moves through the fork node generating two flows. One flow places a token in the waiting decision node *w* which is the extension of a decision node with the difference that it may hold a token similar to an initial node, as defined in [1]. *w* is used in combination with join nodes *j1* and *j2* to explicitly model the acceptance or rejection of the user request based on the user authenticity. The other flow is forwarded as input to the authentication server to check whether the user is legitimate to generate service request. If the user is legitimate to generate the request a token is offered to the join node *j1*. If *w* still has its token *j1* can fire which emits a token which then forwarded to the location server for further processing. If the user is not legitimate to generate the request, a token is offered to the join node *j2*. If *w* still has its token *j2* can fire notifying the user upon the cancellation of request and then terminates the activity.

264 Petri Nets – Manufacturing and Computer Science

a building block as service collaboration.

with other building blocks.

activity blocks. They are represented by activities.

**Figure 3.** Activity diagram for expressing the internal behavior of collaboration

The specifications for collaborations are given as coherent, self-contained reusable building blocks. The internal behavior of building block is described by the UML activity. It is declared as the classifier behavior of the collaboration and has one activity partition for each collaboration role in the structural description [6]. For each collaboration, the activity declares a corresponding call behavior action refereeing to the activities of the employed building blocks. Depending on the number of participants, connectivity to other blocks and

1. The most general building block is collaboration with two participants providing functionality that is intended to be composed with other functionality. We refer to such

2. Building blocks that involve only local behavior of one participant are referred to as

3. A special building block is system collaboration, which is collaboration on the highest composition level. In contrast to a service, a system is closed and cannot be composed

(a) (b)

(c)

level of decomposition, we distinguish three different kinds of building blocks [10]:

In order to validate the user identity (mobile number in this case) provided by a user who requests for service, BTS participates in the collaboration *authenticate* together with the authentication server. This is specified by collaboration *a: authenticate* where BTS plays the role of client and the authentication server plays the role of server. The behavior of the collaboration defined by the UML activity which is divided into two partitions, one for each collaboration role: client & server shown in Figure 3(b). The activity is started on the client side, when user id is provided as parameter *u\_id* at the input pin. The input is then directly sent to the server, where it is converted into a database request in the call behavior action *processing*. Thereafter, it is the task of the collaboration between the server and the database to provide the stored user information. In order to get the information, the request leaves the activity *authenticate* and the server waits for the reception of the response. This is modeled with the input and output pins *request* and *response*. Depending on the validity of the user id, the server may decide to report *ok* or *nok* (not ok) to the client by the call behavior action *validate*. The result is then forwarded to the corresponding output pin in the client side and the activity is terminated. The semantics of all the pins are given in [12]. Likewise, we can describe the behavior of collaboration *l: Request Location info* ( shown in Figure 3(c)) and w: *Request Weather info* through activity partition of client and server where BTS plays the role of client and location server and weather server play the role of server to deliver the requested information to the user through his/her mobile terminal.

The collaborative building blocks with help of activities specify overall system functional behavior which is introduced in Figure 4 for our scenario. For specifying detail behavior, UML collaborations and activities are used complementary to each other; UML collaborations focus on the role binding and structural aspect, while UML activities complement this by covering also the behavioral aspect for composition. For this purpose, call behavior actions are used. Each sub-service is represented by a call behavior action referring to the respective activity of the building blocks. Each call behavior action represents an instance of a building block. For each activity parameter node of the referred activity, a call behavior action declares a corresponding pin. Pins have the same symbol as activity parameter nodes to represent them on the frame of a call behavior action. Arbitrary logic between pins may be used to synchronize the building block events and transfer data between them. By connecting the individual input and output pins of the call behavior actions, the events occurring in different collaborations can be coupled with each other. There are different kinds of pins described as follows [10]:

Performance Evaluation of Distributed System Using SPN 267

**Figure 4.** Activity diagram for detail system behavior

**Figure 5.** Collaboration diagram in generalized way

collaboration *t: transferij* (where ij = AB).

behavior action *forward.*

general structure of the building block *t* is given in Figure 5 where it only declares the participants A and B as collaboration roles and the connection between them is defined as collaboration use *tx* (x=1…nAB (number of collaborations between collaboration roles A and B)). The internal behavior of the same building block is shown in Figure 6(b). The activity *transferij* (*where ij = AB*) describes the behavior of the corresponding collaboration. It has one activity partition for each collaboration role: A and B. Activities base their semantics on token flow [1]. The activity starts by placing a token when there is a response (indicated by the streaming pin *res*) to transfer by either participant A or B. After completion of the processing by the collaboration role A and B the token is transferred from the participant A to participant B and from participant B to Participant A which is represented by the call

The detailed behavior of collaboration is given in following Figure 6(a). The initial node (∙) indicates the starting of the activity. The activity is started at the same time from each participant A and B. After being activated, each participant starts its processing of the request which is mentioned by call behavior action *Pi* (Processingi, where i = A, B). Completions of the processing by the participants are mentioned by the call behavior action *di* (Processing\_donei, i = A, B). After completion of the processing, the responses are delivered to the corresponding participants indicated by the streaming pin *res*. The response of the collaboration role A will be forwarded to B and vice versa which is mentioned by

**B A tx: transferAB**


Figure 4 shows the activity diagram for our system to highlight the overall behavior of the system by composing all the building blocks. The initial node (∙) marks the starting of the activity. The activity is started on the client side. When a user service request is generated via mobile terminal, *g: Generate request* will transfer the user service request as parameter *u\_req* to the BTS via collaboration *t: Transfer*. Once the request arrived at the BTS the user id as parameter *u\_id* is transferred to the authentication server to check whether the user is authentic to accept the service and the activity is represented by *a: authenticate*. The activity *authenticate* initiates a database request, modeled by collaboration *d1: DBRetrieve* and terminates with one of the alternative results *ok* or *nok*. After arriving the positive response at the BTS, request for location information is forwarded to the location server represented by activity *Request location info*. Location server makes a database request which is modeled by *d1: DBRetrieve* and terminates with result *l\_info* (Location information). After getting the location information, request for weather information according to user current location is forwarded by the BTS to the weather server represented by activity *Request weather info.*  Weather server makes a database request which is modeled by *d2: DBRetrieve* and terminates with result *w\_info* (Weather information). After that, the final result is transferred to the user hand held device by BTS via activity *t: Transfer*. But if the user is failed to prove his/her identity then immediately a *nok* is sent to the user's hand held device.

So far, we introduced the system functional behavior with respect to specific example. Now we would like to introduce the specification in more generalized way. For example, the

**Figure 4.** Activity diagram for detail system behavior

266 Petri Nets – Manufacturing and Computer Science

behavior.

node.

There are different kinds of pins described as follows [10]:

The collaborative building blocks with help of activities specify overall system functional behavior which is introduced in Figure 4 for our scenario. For specifying detail behavior, UML collaborations and activities are used complementary to each other; UML collaborations focus on the role binding and structural aspect, while UML activities complement this by covering also the behavioral aspect for composition. For this purpose, call behavior actions are used. Each sub-service is represented by a call behavior action referring to the respective activity of the building blocks. Each call behavior action represents an instance of a building block. For each activity parameter node of the referred activity, a call behavior action declares a corresponding pin. Pins have the same symbol as activity parameter nodes to represent them on the frame of a call behavior action. Arbitrary logic between pins may be used to synchronize the building block events and transfer data between them. By connecting the individual input and output pins of the call behavior actions, the events occurring in different collaborations can be coupled with each other.

1. Starting pins activate the building block, which is the precondition of any internal

Figure 4 shows the activity diagram for our system to highlight the overall behavior of the system by composing all the building blocks. The initial node (∙) marks the starting of the activity. The activity is started on the client side. When a user service request is generated via mobile terminal, *g: Generate request* will transfer the user service request as parameter *u\_req* to the BTS via collaboration *t: Transfer*. Once the request arrived at the BTS the user id as parameter *u\_id* is transferred to the authentication server to check whether the user is authentic to accept the service and the activity is represented by *a: authenticate*. The activity *authenticate* initiates a database request, modeled by collaboration *d1: DBRetrieve* and terminates with one of the alternative results *ok* or *nok*. After arriving the positive response at the BTS, request for location information is forwarded to the location server represented by activity *Request location info*. Location server makes a database request which is modeled by *d1: DBRetrieve* and terminates with result *l\_info* (Location information). After getting the location information, request for weather information according to user current location is forwarded by the BTS to the weather server represented by activity *Request weather info.*  Weather server makes a database request which is modeled by *d2: DBRetrieve* and terminates with result *w\_info* (Weather information). After that, the final result is transferred to the user hand held device by BTS via activity *t: Transfer*. But if the user is failed to prove

his/her identity then immediately a *nok* is sent to the user's hand held device.

So far, we introduced the system functional behavior with respect to specific example. Now we would like to introduce the specification in more generalized way. For example, the

2. Streaming pin may pass tokens throughout the active phase of the building block. 3. Terminating pins mark the end of the block's behavior. If collaboration is started and terminated via several alternative pins, they must belong to different parameter sets. This is visualized in UML diagram by an additional box around the corresponding

general structure of the building block *t* is given in Figure 5 where it only declares the participants A and B as collaboration roles and the connection between them is defined as collaboration use *tx* (x=1…nAB (number of collaborations between collaboration roles A and B)). The internal behavior of the same building block is shown in Figure 6(b). The activity *transferij* (*where ij = AB*) describes the behavior of the corresponding collaboration. It has one activity partition for each collaboration role: A and B. Activities base their semantics on token flow [1]. The activity starts by placing a token when there is a response (indicated by the streaming pin *res*) to transfer by either participant A or B. After completion of the processing by the collaboration role A and B the token is transferred from the participant A to participant B and from participant B to Participant A which is represented by the call behavior action *forward.*

**Figure 5.** Collaboration diagram in generalized way

The detailed behavior of collaboration is given in following Figure 6(a). The initial node (∙) indicates the starting of the activity. The activity is started at the same time from each participant A and B. After being activated, each participant starts its processing of the request which is mentioned by call behavior action *Pi* (Processingi, where i = A, B). Completions of the processing by the participants are mentioned by the call behavior action *di* (Processing\_donei, i = A, B). After completion of the processing, the responses are delivered to the corresponding participants indicated by the streaming pin *res*. The response of the collaboration role A will be forwarded to B and vice versa which is mentioned by collaboration *t: transferij* (where ij = AB).

Performance Evaluation of Distributed System Using SPN 269

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

**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:

(a) (b)

2. Collaborations have communication costs and costs for running of background process

3. Some of the components can be restricted in the deployment mapping to specific nodes

relations mentioned in Figure 7(b).

1. Components have execution costs

which are called bound components.

known as overhead cost

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