VIATRA2/Examples/performability analysis

Outdated page

This page contains obsolete information about the VPM based VIATRA2 and preserved for archive purposes only.
The currently maintained wiki is available at http://wiki.eclipse.org/VIATRA

Description

This example shows a method for a model-driven performability analysis of reliable systems so that the cost of reliability can be assessed without realizing the whole system. The word performability comes from performance and availability. Performance analysis aims at measuring the cost of dependability, i.e. the performance overhead introduced by using reliable middle-ware.

Overview of the process

Starting from UML component diagrams and non-functional descriptions of services, a platform independent service model (SOA-PIM) is generated, on which performability analysis is carried out by deriving process models for PEPA Toolkit.

UML models

From the point of view of the analysis the relevant part of the UML diagrams is illustrated in the following Figure.

This model specifies to use reliable messaging middle-ware between Vehicle Communication Interface a BankCharge Component. The system engineer who sets the values of the parameters (inactivityTimeout, exponentialBackoff etc.) can make a model-driven performability analysis to find out the cost of reliability which can be compared to the result of performance analysis.

Performability model

The next Figure shows the stochastic model of a service configuration with at-least-once messaging semantics. (Every message is transmitted at least once with possibility of having multiply instances of the same message.)

The two automates represents the behavior of a reliable messaging server and client. The one on the left is the server which has two states (rectangles on the figure): processing a request or waiting for a new one. As a new message arrives (?send), the state of the server changes to processing. After finishing processing, the server sends (!ack) acknowledgment message to the client. (! stands for sending a message and ? means receiving an incoming message. The client is behaving according to at-least-once semantics so the request is resent upon internal timeout events occur until acknowledgment message is received. To avoid infinite working, an upper limit is set on the number of retransmissions (retransmission number). If an acknowledgment arrives, the message transmission is considered successful. Sending and receiving messages (send, resend, ack) is carried out by synchronization between the two processes.

Model parameters

Non-functional parameters of services are used to derive send, resend and acknowledgement rates. These parameters come from UML models shown above.

For example:

inactivityTimeout: after this period of time in no acknowl- edgment message has arrived connection is closed;

retransmissionInterval: after this time resend request is sent by client.

From these parameters retransmission number can be derived:

Transformation result

After performing the chain of transformations, pepa code is generated:

 //Rates
 rateTransmit=1.0;
 rateAck=0.3;
 rateTimeout=0.4;
 rateReset=8.0;
 //Definitions
 BankChargeIdle=(send, infty).Processing;
 Processing=(ack, rateAck).BankChargeIdle + (resend, infty).Processing;
 VehicleCommunicationIdle=(send, rateTransmit).MsgSent1;
 MsgSent1=(ack, infty).Success + (timeout, rateTimeout).Failed1;
 Failed1=(resend, rateTransmit).MsgSent2;
 MsgSent2=(ack, infty).Success + (timeout, rateTimeout).Failed2;
 Failed2=(resend, rateTransmit).MsgSent3;
 MsgSent3=(ack, infty).Success + (timeout, rateTimeout).Failure;
 Failure=(ack, infty).VehicleCommunicationIdle;
 Success=(reset, rateReset).VehicleCommunicationIdle;
 //Equation
 BankChargeIdle[1] < send, resend, ack > VehicleCommunicationIdle[1]