Reliability Assessment OfWEB Applications

8/3/2019 Reliability Assessment OfWEB Applications

http://slidepdf.com/reader/full/reliability-assessment-ofweb-applications 1/17

Reliability Assessment of WEB Applications£

V. S. Alagar O. Ormandjieva

Department of Computer Science

Concordia University

Montreal, Quebec H3G 1M8, Canada

Phone: +1(514) 848-7810 alagar,ormandj @cs.concordia.ca

February 18, 2002

Abstract

The paper discusses a formal approach for specifying time-dependent Web applications and proposes

a Markov model for reliability prediction. Measures for predicting reliability are calculated from the

formal architectural specification and system configuration descriptions.

Keywords: reliability prediction, software measurement, Markov model.

1 Introduction

The reliability of a software system is defined in [IEEE90] as the ability to perform the required functionality

under stated conditions for specified period of time. In this paper the software system under discussion is

a Web-based system. Web is a large and complex distributed system whose heterogeneous components

interact in various ways to achieve the result of an application. Often, the performance of an application

initiated at a site is rated as good if the server at that site is robust and links are not broken. Such a rating does

give a subjective qualitative assessment, but does not provide a scientific quantitative measurement of thereliability of the site. This paper proposes a methodology for an assessment of quality of Web application

components through reliability prediction, when a formal m odel of the Web application could be specified

in an Objected-oriented formalism.

Many techniques exist to test and statistically analyze traditional software. However, these methods

can not be readily applied to a Web environment. In a recent paper Kallepalli and Tian [KT2001] have

surveyed the characteristics of Web applications and usage and proposed a statistical testing method for

Web applications. Their approach relies on usage and failure information collected in the log files. Web

failure is defined as the inability to correctly deliver information or documents required by Web users.

Based on this definition of failure, they classify types of failures and provide a method for testing source

or content failures. We complement their work by offering a formal time-constrained model of the Web on

which testing and reliability analysis can be done.

£ This work is supported by grants from Natural Sciences and Engineering Research Council, Canada and Concordia University

Graduate Fellowships.



Quality assurance and reliability assessment for Web applications should focus on the prevention of Web

failures or the reduction of chances for such failures. Consequently, we contend that early reliability as-

sessment is necessary for the reduction of testing efforts, and for ensuring a level of operational reliability.

We propose an early analysis on the formal architecture model of the Web application. This uses a Markov

model, which can adapt to changing system configurations that satisfy the architectural design. We may

view Web applications as Markov systems, in which state changes occur with certain probabilities. From

the Markov model of an application, we can calculate a predictive measurement of reliability. Markov

matrices for individual Web components can be constructed from log files, the source used for statistical

testing in [KT2001]. We give methods for calculating Markov matrices for synchronously interacting Webcomponents from the Markov matrices of individual components. Synchrony hypothesis is that two Web

components that interact on a shared message will change their status (states and associated information)

simultaneously. In a typical application, several Web components collaborate to achieve a task. It is impor-

tant to assess the reliability of every collaboration in an application. We provide a method to compute the

reliability of the whole system from the reliability measures of the collaborations in the system.

2 Web and Markov Models: Basic Concepts

The Web is a large network of interconnected components. Conceptually, it is a graph where each vertex

(node) is a computer system providing an interface to the other nodes in the network. A Web application

is multi-layered, with the user at the top of the layer and the information source at the bottom of the layer.

A user interacts with the nodes in the Web through a browser, which has links to the home pages at the

interfaces of the nodes in the network. The sever at a node provides the services for controlled navigation

for accessing and retrieving information from the information sources at that node. We model the Web

components as User , Browser , and Server classes. Objects, instantiated from the classes, interact in a

meaningful way through messages. The behavior of objects in a class is captured by a hierarchical labeled

transition system with finite number of states. A state represents an operational high-level unit. A transition

between two states may be labeled by a message shared by objects of different classes, or by an event internal

to the object. A state, when complex, is itself a hierarchical labeled transition system, with its substates and

transitions defined by the buttons and the whistles specific to that state. That is, a transition from a substate

to another substate

¼ of an object is implicitly labeled by the link name on the page associated with

.

Some Web applications may put time constraints on the navigation paths within their systems. This is

typical when secure information or time-varying information is to be made available. For instance, consider

the home page of a hypothetical on-line brokerage system HOBS. A user may be able to reach the home

page of HOBS using a browser. However, the user must be authenticated to get services at the site. Once

authenticated, the user may be authorized to do one or more business activity at each state of the server

object. A state may include secure information such as user-id , account-number , and account-balance.

Typical states of the HOBS system where time may plays a role can be Stock Trading, Mutual Fund Trading,

Account Overview, Positions, Quotes and Research, Financial Planning, and Services.

The architecture of HOBS design may allow the user to explore the substates of a state or change to adifferent state as specified by the links on the current page. For instance, the hierarchy of stages rooted at

the state Stock Trading may impose timing constraints on the information displayed at its substates. After

reviewing an order at one of its substates, the user may be allowed to change, review or cancel the order.

2



If the activity at the state review is not completed within a certain amount of time, the backward transition

may be disabled. There are two reasons for this: (1) the page contains secure information, and (2) the

information, such as stock price is a time-dependent value. Another instance where time plays a role is

when the user fails to interact for a certain period of time in a state. The system, after waiting for a period

of time, may force a new log in session. These instances illustrate the failure of the system to deliver the

information requested by the user. However, this type of failure is not a fault of the system. The behavior of

the system deviates from the user-expected behavior of the system, yet the system behaves according to the

time-constrained functionality imposed by system requirements. In order to model such applications and

their reliability our formal model includes time constraints.

2.1 Markov models

Markov models are one of the most powerful tools available to engineers and scientists for analyzing com-

plex systems. Analysis of Markov models yield results for both the time-dependent evolution of the system

and the steady state properties of the system. The Markov property states that given the current state of the

system, the future evolution of the system is independent of its history.

The Markov model of a Web component may be represented by a state diagram. The states represent the

stages in the Web component that are observable to the users and the transitions between states have assigned

probabilities. The probabilities are calculated from the usage and related failure information collected in thelog file that maintains the Web site. We may use this data as initial transition probabilities. An algebraic

representation of a Markov model is a matrix, called transition matrix, in which the rows and columns

correspond to the states, and the entry Ô

in the

-th row,

-th column is the transition probability for being

in state

at the stage following state

. We use transition matrix representation in reliability calculation

algorithms.

2.2 Discussion

Initial transition probabilities, obtained from various sources including log files and other subjective opinions

of experts can not be used for predicting the reliability of the system. We contend that the reliability shouldbe calculated from the steady state of the Markov system. A steady state or equilibrium state is one in which

the probability of being in a state before and after transitions is the same as time progresses. Computing the

steady state vector for the transition matrix of a large system is hard. However, as in our approach, when the

system is modularly constructed it seems possible to partition the system into smaller components, which

might reduce the complexity of computing steady state vectors.

The formal model of the Web that we discuss in the next section is based on timed labeled transition

system semantics. From the state machine description of a Web component, it is possible to construct the

Markov machine corresponding to that model.

The organization of this paper is as follows. A formal model of the Web is given in Section 3. Section 4

formally describes the method of modeling the Web application as a Markov system. Section 5 presents thereliability prediction measures. Section 6 concludes the paper with a discussion on our ongoing research

directions.

3



3 Formal Model

Web is a reactive system, characterized by the following two important properties:

̄ stimulus synchronization: the Web (process) always reacts to a stimulus from its environment;

̄

response synchronization: the time elapsed between a stimulus and its response is acceptable to the

relative dynamics of the environment, so that the environment is still receptive to the response.

In addition, certain timing constraints are inherent in the design of many Web components. Hence, we may

characterize Web as a real-time reactive system. Real-time constraints are strictly enforced in security related

information browsing and retrieval. When security is related to safety, such real-time constraints are hard

requirements, in the sense that defaulting it would lead to dire consequences. In characterizing Web as real-

time reactive systems, we have taken a stronger view than the traditional one, where the Web is regarded as

an interactive system. For many applications such a soft view is sufficient. However, when time constraints

and secure transactions are part of the Web application, ours is a more appropriate characterization. The

major distinction between the two views is in the available synchronization mechanism: an interactive

system will wait for an input from its environment; whereas, a reactive system is fully responsible for

synchronization with its environment. That is the underlying reason why certain stages in secure transactions

cannot be accessed through backward navigation.

A Timed Reactive Objected-oriented Model for the development of real-time reactive systems is dis-

cussed by Alagar et. al [AAM98]. We model the Web using this formalism. Abstractly, we model a Web

component as a class parameterized with port types. A port type is associated with a signature, a finite set

of messages that can occur at a port of that type. We use the notation

to emphasize that

is an output

message, and write

to emphasize that

is an input message. A class may include attributes of two kinds:

port identifies, and data types such as integer , set , list , and queue.

An object of the class Ä ℄

, whereÄ

is the list of port types, is created by instantiating each port type

inÄ

by a finite number of ports and assigning the ports to the object. Any message defined for a port type

can be received or sent through any port of that type. For instance,

½

Ô

½

Ô

¾

È Õ

½

Õ

¾

Õ

¿

É ℄

, and

¾

Ö

½

È ×

½

×

¾

É ℄ are two objects of the class È É ℄ . The object

½

has two ports Ô

½

and Ô

¾

of type @È

, and three portsÕ

½

,Õ

¾

,Õ

¿

of type @É

. Both Ô

½

and Ô

¾

can receive or send messages of type

@È

; the portsÕ

½

,Õ

¾

, andÕ

¿

can receive and send messages of type @É

. Sometimes the port parameters of

objects are omitted in our discussion below. Messages may also have parameters with basic types.

An incarnation of an object

is a copy of

with a name different from the name of any other object

in the system, and with its port types renamed, if necessary. Several incarnations of the same object can

be created and distinguished by their id s. Letting id s to be positive integers,

½

½ ℄

,

½

¾ ℄

are two distinct

incarnations of the object

½

. Every incarnation of an object retains the same port interfaces. For instance

½

½ ℄

½

¾

È

½

¾

¿

É ℄

and

½

¾ ℄ Ô

½

Ô

¾

È Õ

½

Õ

¾

Õ

¿

É ℄

are two distinct incarnations

of the object

½

Ô

½

Ô

¾

È Õ

½

Õ

¾

Õ

¿

É ℄

. The contexts and behavior of incarnations of an object

are in general independent. The context for the incarnation

℄ is defined by the set of applications

in which it can participate. Hence the context of an incarnation effectively determines the objects with

whom it can interact and the messages it can use in such an interaction. For instance, the incarnations

½

½ ℄

½

¾

È

½

¾

¿

É ℄

and

½

¾ ℄ Ô

½

Ô

¾

È Õ

½

Õ

¾

Õ

¿

É ℄

can be plugged into two distinct

4



configurations for two distinct applications in a system. In the rest of the paper we use the term object to

mean incarnation as well.

The behavior of objects in a class is specified by a finite state machine, augmented with state hierarchy,

logical assertions and timing constraints for transitions. A complex state is an encapsulation of a state

hierarchy, and hence another finite state machine, with an initial state, and which can include other complex

states. In our model, Web objects communicate using a synchronous message passing mechanism. An

external event in the system is either an input or an output event, which can only occur at an instance

of a specific port type. Events label the transitions between states. Logical assertions on the attributes

specify a port condition, an enabling condition, and a post condition on each transition. Local clocks aredefined to enforce time constraints associated with a transition. Both time constraints and functionality are

encapsulated in an object.

An abstract model of a Web system is specified as a collection of interacting Web components. A

Web component is an object instantiated from a generic class. A pair of objects in this collection interact

synchronously through shared messages. These messages occur at the compatible ports. Two ports in a

system are compatible if the set of input messages at one port is equal to the set output messages at the other

port. A port link connects two compatible ports. A port link is an abstraction of communication mechanism

between the objects associated with the ports. Since the signature of ports are well-defined, the port links

effectively determine the set of all valid messages that can be exchanged among the objects in a subsystem.

3.1 Operational Semantics

Web objects communicate through messages. A message from an object to another object in the system is

called a signal and is represented by a tuple

Ô

Ø

, denoting that the event

occurs at timeØ

, at a port

Ô

. The status of an object at any timeØ

is the tuple ́ Ê µ

, where the current state

is a simple state,

is

the assignment vector for attributes, andÊ

is the vector of outstanding reactions. A computational step of an

object occurs when the object with status ́ Ê µ

, receives a signal

Ô

Ø

and there exists a transition

specification that can change its status. A computation

of an object

is a sequence, possibly infinite,

of alternating statuses and signals,Ç Ë

¼

¼

Ô

¼

Ø

¼

Ç Ë

½

½

Ô

½

Ø

½

. Typically, the Web system is non-

terminating; consequently, a computation is in general an infinite sequence. The set of all computationsof an object

is denoted by Ó Ñ Ô ́ µ

. The computation of the Web system is an infinite sequence of

system statuses and signals that effect status changes [AAM98]. A period is a finite subsequence of the Web

computation such that it starts with some initial state and finishes with its next appearance in the computation

sequence.

3.2 A Simple Model of the Web

We abstract the multi-layered architecture of Web applications into three Web components: User , Browser ,

and Server . This abstraction, although is simple, is quite expressive and sufficient to illustrate the reliability

calculation. Extension of our approach to more complex and detailed models are not difficult.

In our model, we assume that several users (clients) may use a browser independently and concurrently

to access information from a server. For simplicity, we assume that one browser is associated with a server.

Once again, this restriction is only for the sake of simplicity of exposition, and can be generalized. A user

5



Server

<<GRC>>

@S

events : Set = {Permit?,StopPermit?}

<<PortType>>

@G

events : Set = {Permit!,StopPermit!}

<<PortType>> Browser

<<DataType>> inSet : Set[@P,PSet]

<<GRC>>

User

<<PortType>> cr : @C

<<GRC>>

@P

events : Set = {Get?,Exit?}

<<PortType>>

@C

events : Set = {Get!,Exit!}

<<PortType>>

Figure 1: Class Diagram for User, Browser and Server Entities.

chooses the server of his choice and initiates a request to a server. That is, the user sends a message to

the corresponding browser, which then commands the server t o allow the connection. When the last user

requesting access to a server disconnects, the browser commands the server to close. During this period,

the user- browser-server interaction must work without fault. The security (expressed as a safety property)

requires that the operation of the system satisfies certain timing constraints, the server remains open, and

provides the requested information (not violating time constraints) during every period of transaction.

A high-level class structure diagram of the model in UML-based notation is shown in Figure 1. The

User class has one port type with signature Ø Ü Ø

. The Browser class has two port types, @È

with

signature Ø Ü Ø

, and @

with signature È Ö Ñ Ø Ë Ø Ó Ô È Ö Ñ Ø

. The Server class has one port

type with signature È Ö Ñ Ø Ë Ø Ó Ô È Ö Ñ Ø

. The figure shows that a port type, modeled as a class, has

an aggregation relationship with the class for which it is intended. An association relationship between

compatible port types is shown. A port identifier is declared as a variable of type @

in User class, and a

variable of typeË Ø

is introduced in Browser class. Time constraints and functionality of objects of classes

are described in statechart diagrams. A formal specification includes structural and behavioral information.

User Model

The statechart diagram for User is shown in Figure 2(a). The significant states of a User object are idle,

toAccess, access, leave. At any instant, a user is in one of these states. In the Idle state, a user has not

initiated any request. To access the server, the user sends t he event Get to the browser used by it in state

Idle, and changes his state to toAccess. In state toAccess, the attribute cr is set to pid , the identifier of the

port where Get occurs. This transition is the constraining transition for two time constraints, labeled TCvar1

and TCvar2. Within 2 to 4 units of time of outputting the request (specified by TCvar1), the user accesses

the server. That is, the user changes his state to access by initiating the internal event In. The state leave

is reached when the user has retrieved the information requested, and this happens within 6 units of time

(specified by TCvar2) from the instant the user requested access to the server. The user sends the message Exit to the browser and reaches the initial state. The formal specification of the User class is shown in

Figure 2(b).

6



S1: idle

S3: accessS4: leave

Exit[ pid=cr && true && TCvar2<6 ]

S2: toAccess

In[ true && true && TCvar1>2 AND TCvar1<4 ]In[ true && true && TCvar1>2 AND TCvar1<4 ]

Out

Get / cr’=pid && TCvar1=0 AND TCvar2=0

(a) User Statechart

Class User [@R]Events: Get!@R, Out, Exit!@R, InStates: *idle, access, leave, toAccessAttributes: cr:@CTraits:Attribute–Function:

idle ; access ;

leave

; toAccess

cr

;Transition–Specifications:R1:

idle,toAccess

; Get(true); true

cr¼ =pid;R2:

access,leave

; Out(true); true

true;R3:

leave,idle

; Exit(pid = cr); true

true;R4: toAccess,access ; In(true); true true;

Time–Constraints:TCvar2: R1, Exit, [0, 6],

;TCvar1: R1, In, [2, 4], ;

end

(b) User class Specification

Figure 2: User Class

C2: activate

C4: deactivate C3: monitor

Get[ NOT(member(pid,inSet)) && true ] / inSet’=insert(pid,inSet)

C1: idle

Get[ NOT (member(pid,inSet)) &&true ] / inSet’=insert(pid,inSet)

Get / inSet’=insert(pid,inSet) &&TCvar1=0

Permit[ true && true && TCvar1>0 AND TCvar1<1 ]

Exit[ member(pid,inSet) && size(inSet)=1 ] / inSet’=delete(pid,inSet) && TCvar2=0

Exit[ member(pid,inSet) && size(inSet)>1 ] / inSet’=delete(pid,inSet)

StopPermit[ true && true && TCvar2>0 AND TCvar2 < 1 ]

(a) Browser Statechart

Class Browser [@P, @Y]Events: Permit!@Y, Get?@P, StopPermit!@Y, Exit?@PStates: *idle, activate, deactivate, monitorAttributes: inSet:PSetTraits: Set[@P,PSet]Attribute–Function:

activate

inSet

; deactivate

inSet

;monitor inSet ; idle ;

Transition–Specifications:R1: activate,monitor ; Permit(true);

true true;

R2: activate,activate ; Get(NOT(member(pid,inSet)));true inSet ¼ = insert(pid,inSet);

R3: deactivate,idle ; StopPermit(true);true true;

R4: monitor,deactivate ; Exit(member(pid,inSet));size(inSet) = 1 inSet ¼ = delete(pid,inSet);

R5: monitor,monitor ; Exit(member(pid,inSet));size(inSet)

1

inSet ¼ = delete(pid,inSet);R6:

monitor,monitor

; Get(!(member(pid,inSet)));true

inSet ¼ = insert(pid,inSet);R7: idle,activate ; Get(true);

true inSet ¼ = insert(pid,inSet);Time–Constraints:

TCvar1: R7, Permit, [0, 1],

;TCvar2: R4, StopPermit, [0, 1], ;

end

(b) Browser class Specification

Figure 3: Browser class

7



G1: idle G2: toOpen

G3: toClose G3: opened

Allow[ true && true && TCvar1>0 AND TCvar1 < 1 ]

StopPermit / true && TCvar2=0

Permit / true && TCvar1=0

DisAllow[ true && true && TCvar2 >1 AND TCvar2< 2 ]

(a) Server Statechart

Class Server [@S]Events: Permit?@S, Allow, DisAllow, StopPermit?@SStates: *Idle, toClose, toOpen, openedAttributes:Traits:Attribute–Function:

Idle ; toClose ;toOpen

; opened

;

Transition–Specifications:R1:

Idle,toOpen

; Permit(true); true

true;R2:

toOpen,opened

; Allow(true); true

true;R3:

toClose,Idle

; DisAllow(true); true

true;R4:

opened,toClose

; StopPermit(true); true

true;Time–Constraints:

TCvar1: R1, Allow, [0, 1], ;TCvar2: R4, DisAllow, [1, 2], ;

end

(b) Server class Specification

Figure 4: Server class

Browser Model

The statechart diagram for Browser is shown in Figure 3(a). A Browser object can be in one of four states:

idle, activate, monitor , deactivate. In its initial state Idle the object receives the Get message from a user

object. In response, it synchronously changes its state to activate and includes the identifier of the port where

the message was received in its attribute inSet . In activate state, the browser object may either receive the

Get message from another user object or may send the message Permit to the server object associated with

it. In the former case, it includes the pid where the message was received to its attribute inSet , and stays in

the same state. In the later case, it changes its state to monitor within 1 time unit from the instant it received

the first Get message. In state monitor three possible situations arise:

1. The object receives the Get message from another user object. The response is identical to its response

for the Get message in state activate.

2. The object receives the Exit message from a user. In response, it removes the user object from inSet ,

and as a result of this deletion if inSet is empty (signifying that there are no more users) it changes its

state to deactivate or it stays in the same state.

Within 1 and 2 units of time of reaching deactivate state, it sends the message StopPermit to the server and

changes its state to idle.

Server Model

The statechart diagram for Server is shown in Figure 4(a). A Server object can be in one of four states: idle,

toOpen, opened , toClose. Initially the server is in idle state. Upon receiving the event Permit , it changes its

state synchronously with the Browser object and goes to toOpen state. Within one unit of time of receiving

8



the Permit event, the Server object initiates the internal event Allow and reaches the state opened . It stays

in that state until receiving the event StopPermit from the Browser object. Within 1 and 2 units of time

of receiving StopPermit , the Server will return to idle state from toClose state. The formal specificaiton is

shown in Figure 4(b).

Server1 : Serveruser1 : User

Browser1 : Browser@P1 : @P

@S1 : @S@C1 : @C

@G1 : @G

(a) Collaboration Diagram - Simple System

SCS UserServerBrowserIncludes:Instantiate:

Server1::Server[@S:1];User1::User[@C:1];Browser1::Browser[@P:2, @G:1];

Configure:Browser1.@G1:@G

–

Server1.@S1:@S;Browser1.@P1:@P – User1.@C1:@C;

end

(b) System Specification - Simple System

user2:User

@C2: @C @C3: @C @C4: @C @C5: @C @C6: @C

@P6: @P@P5: @P@P4: @P@P3: @P@P2: @P@P1: @P

Browser2:Browser

@G2: @G

@S2: @S

Server2:Server

@S1: @S

@G1: @G

Browser1:Browser

user1:User

@C1: @C

user3:User user4:User user5:User

Server1:Server

(c) Collaboration Diagram - Complex System

SCS UserServerBrowserIncludes:Instantiate:

Server1::Server[@S:1];Server2::Server[@S:1];User1::User[@C:1];User2::User[@C:1];User3::User[@C:2];User4::User[@C:1];User5::User[@C:1];Browser1::Browser[@P:3, @G:1];Browser2::Browser[@P:3, @G:1];

Configure:Browser1.@G1:@G – Server1.@S1:@S;Browser2.@G2:@G – Server2.@S2:@S;

Browser1.@P1:@P

–

User1.@C1:@C;Browser1.@P2:@P – User2.@C2:@C;Browser1.@P3:@P

–

User3.@C3:@C;Browser2.@P4:@P

–


–


–

User5.@C6:@C;end

(d) System Specification - Complex System

Figure 5: System Configuration Models and Specifications

A system configuration specification defines objects instantiated from the three classes and their inter-

actions. Figure 5(a) is a collaboration diagram in UML style for a linear system with one user object, oneserver object, and one server object. The formal specification for this system is shown in Figure 5(b). A

more complex system, that is non-linear, consisting of five users, two browsers and two servers is shown

in Figure 5(c). In this configuration, user3 is allowed to access both browsers, while the other user objects

interact with only one browser. The formal specification for this subsystem configuration is shown in Figure

9



5(d). In both specifications, there is no included subsystem. In the Instantiate section, objects are created,

and in the Configure section compatible ports of objects are linked. The behavior of a system configuration

specification can be simulated by applying the operational semantics to the system starting in some initial

configuration.

4 Markov Models

We construct the Markov model of a Web system in three steps. In the first step we construct the Markov

models for Web objects. In the second step we construct the Markov models for every pair of interacting

objects in the system configuration specification. Finally in the third step we construct the Markov model

for the fully configured system.

4.1 Step 1: Markov Models for Objects

We associate with each Web object in the architecture another finite state machine, called its Markov model.

The states in the Markov model of an object are the states of the object in the formal design. A transition

between two states in the Markov model is defined only if there exists at least one transition between those

states in the statechart of the object. For instance, the states and transitions of User object Markov model are

the same as those in User statechart but for labels and constraints. In the absence of statistical information

gathered by experts on the usage and failure, we will assume that all the external events have equal proba-

bility in each state. For the transition from state

to state

in the Markov model, a fixed probability Ô

of

it going into state

at the next time step is calculated as follows:

1. The initial probabilities for all the transitions in the state machine of the reactive object are calculated.

The algorithm for calculating such probabilities for a state is based on the following assumptions: 1)

all external events that can happen at the state have the same probability; 2) all internal events that can

happen at the state have the same probability, and (3) these are in general different.

2. In case there is more than one transition Ð

½

Ð

Ò

of the same type (shared/internal) from state

tostate

, then the above mentioned transitions are substituted by one whose probability is

È ½ ´ ½ È Ð

½

µ ¢ ´ ½ È Ð

Ò

µ

3. The probabilities of all the transitions for a state have to sum to½

.

The Markov models and transition probabilities for User , Browser , and Server objects are shown in Figure 6.

4.2 Step 2: Markov Model for Object Pairs

The interaction between two objects is due to shared events. We compute the state machine for an interacting

pair of objects and compute the Markov model with transition probabilities from the transitions at each state

of the product machine.

10



p

p

p

p

12

23

34

41

S2

S3S4

S1

S1 S2 S3 S4

S4

S3

S2

S1 0 010

0

0

0 0

0 0

000

1

1

1

(a) User Class

p

p

p

p

12

23

34

41

G2

G3G4

G1

G1 G2 G3 G4

G4

G3

G2

G1 0 010

0

0

0 0

0 0

000

1

1

1

(b) Browser Class

p

p p

12

2341

C2

C3C4

C1

C1 C2 C3 C4

C4

C3

C2

C1 0 010

0

0

0

0

0001

1/2 1/2

3/4 1/4

p22

p33

p34

(c) Server Class

Figure 6: Markov Models

Algorithm for Transition Matrix for the Synchronous Product Machine

Let

½

and

¾

be the sets of internal events in the statechartsÈ

andÉ

of interacting objects, and

denote

the set of shared events. LetÅ

½

andÅ

¾

be the transition matrices forÈ

andÉ

. LetÊ

be the synchronized

product machine of È

andÉ

. Algorithm SPM computes the transition matrixÅ

of Ê

by first computing

the synchronous product machineÊ

, and next determining the transition probabilities for transitions in each

state of Ê

. If all the transitions in a state are labeled by internal events or if all of them are labeled by

shared events the probabilities are obtained by normalizing the probabilities in their respective machines.

However, if both internal events and shared events occur at the state, the probabilities for the shared events

are calculated first, and the remaining measure is distributed to transitions labeled by internal events.

11



Algorithm SPM

Step 1. Ô ½

;

row sum

Step 2. Ü

½

is a shared event occurring at state

(È

) and at state

(É

)

Ü

¾

is an internal event occurring at state

(È

)

is an internal event occurring at state

(É

)

Step 3. If Ü

½

calculate probabilities for transitions due to shared events

thenÆ ¼

(Normalization Factor);× Ø

½

;

Step 3.1 For each event ¾ Ü

½

find the (set of) states

¼

(È

) and

¼

(É

) such that

¼

,

¼

Step 3.2 Ý Ý

¼

¼

, if

¼

¼

¾ Ý

Step 3.3 Æ Æ · Å

½

¼

℄ ¢ Å

¾

¼

℄

Step 3.4 Å ́

¼

µ ́

¼

µ ℄ Å

½

¼

℄ ¢ Å

¾

¼

℄

Step 3.5 × Ø

½

× Ø

½

́

¼

µ

Step 4. If Ü

¾

calculate probabilities for transitions due to internal events

thenÆ

¼

¼

(Normalization Factor);× Ø

¾

;

Step 4.1 For each event ¾ Ü

¾

, if ¾ Å

½

then

find the state

¼

(Å

½

) such that

¼

;

Ý Ý

¼

,

if

¼

, ¾ Ý

;

Å ́ µ ́

¼

µ ℄ Å

½

¼

℄

;Æ

¼

Æ

¼

· Å ́ µ ́

¼

µ ℄

;

× Ø

¾

× Ø

¾

́

¼

µ

else

find the state

¼

(Å

¾

) such that

¼

;

Ý Ý

¼

if

¼

¾ Ý

;

Å ́ µ ́

¼

µ ℄ Å

¾

¼

℄

;Æ

¼

Æ

¼

· Å ́ µ ́

¼

µ ℄

;

× Ø

¾

× Ø

¾

́

¼

µ

Step 5. If Ü

½

Ü

¾

, the ́ µ

row is deleted fromÅ

Step 6.If Ü

½

Ü

¾

For each ́

¼

¼

µ ¾ × Ø

¾

do

Å ́ µ ́

¼

¼

µ ℄

Å ́ µ ́

¼

¼

µ ℄

Æ

¼

12



S2,C3

S4,C3

0S1,C1

1

S1,C4

000001S1,C4

1

0

1

1

1

0

0

0

0

0

0

0

0

S4,C3 S3,C3

S2,C3S2,C2

S1,C4

S2,C2

S3,C3

S4,C3

0S1,C1

S1,C1 S2,C2 S2,C3 S3,C3

0

0 0

0 0 0

0

0

0

0

0

0

0

0

61

56 45

34

2312

P

P

P

P

P

P

Figure 7: Markov Model and State Transition Matrix for Synchronous Product of User and Browser

Step 7. If Ü

½

Ü

¾

For each ́

¼

¼

µ ¾ × Ø

½

do

Å ́ µ ́

¼

¼

µ ℄

Å ́ µ ́

¼

¼

µ ℄

Æ

Step 8. If Ü

½

Ü

¾

do

For each ́

¼

¼

µ ¾ × Ø

¾

do

Å ́ µ ́

¼

¼

µ ℄

´ ½ Æ µ ¢ Å ́ µ ́

¼

¼

µ ℄

Æ

¼

Step 9. To fill in the matrixÅ

with¼

where there are no entries

The Markov model and transition probability matrix for the synchronous product of User and Browser

objects is shown in Figure 7.

4.3 Step 3: Markov Model for a System

A partitioning method given in [O2002], is the basis of our discussion in this section. A system configu-ration, when partitioned, produces two types of subsystem components: (1) linear subsystem configuration,

as shown in Figure 8(a), and (2) non-linear subsystem configuration as shown in Figure 9(a).

4.4 Case 1: Linear System

In a linear system, objects synchronize in the past. If Ó

½

Ó

Ò

are objects in the linear system and

Å

½

Å

Ò

are respectively their transition matrices, then the transition matrixÅ

of the linear system

is computed as follows:

1. ComputeÅ Å

½

ª Å

¾

(Apply Algorithm SPM)

2. for ¿

toÒ

computeÅ Å ª Å

(Apply Algorithm)

The Markov model and the transition matrix for the linear system (Figure 5(a)) are shown in Figure 8(b).

13



User ServerBrowserIni

synchronize

synchronize

(a) Linear Architecture

S4 C3 G3S1 C1 G1 S2 C2 G1

S1 C1 G4

S1 C1 G1

S2 C2 G1

S3 C3 G3S2 C3 G3S2 C3 G2

S1 C4 G3

S4 C3 G3 S4 C3 G3

S3 C3 G3

S2 C3 G3

S2 C3 G2

S1 C1 G4

S1 C1 G4S1 C4 G3

S1 C4 G3

S1 C1 G1

S2 C2 G1

S2 C3 G2

S2 C3 G3 S3 C3 G3

P

P

P

P

P

12

23

34

45

56

67

89

P78

P

P

0 0 0

0 0 0 0 01

1

1

1

0

0 0 0 0 0

00000

0 0 0 0 0

000000

1

0 0 0 0 0

0 0

0

0001

0

0

0

0

0

0

0

00

0

0

0

1

0

0

00

(b) Markov Model

Figure 8: User-Browser-Server Linear Model

4.5 Case 2: Non-linear System

In a non-linear system, as in Figure 9(a), several objects interact with an object. These interactions may be

initiated at different times. The synchronous product machine dynamically changes as and when users join

or leave the system, and hence the transition probability matrices also change, and should be recomputed.

For one scenario, the synchronous product of a non-linear system and its corresponding Markov model

are illustrated in Figure 9(b). In the state machine diagram, interpret eachË

as a vector, with number

of components equal to the number of users in the system. For simplicity of discussion we assume that

users join the system one at a time, but don’t leave the system. Let¼

½

¾

Ò ½

be the intervals of

successive arrivals of users. That is, for ½

the

-th user joins the system

½

́ ¼ µ

time units after

½

-st user joined the system. LetÅ

½

be the transition matrix of the Markov model for the linear system

composed fromÍ × Ö

½

Ö Ó Û × Ö

½

Ë Ö Ú Ö

½

, andÅ

½

be its transition matrix at time step

. The transition

matrix forÅ

́ Ò µ

,Ò ¾

, users interacting with one browser and one server is calculated as follows:

Å

´ ¾ µ

Å

½

½

Ä

Å

½

Å

´ ¿ µ

Å

´ ¾ µ

℄

¾

Ä

Å

½

...

Å

́ µ

Å

́ ½ µ

℄

½

Ä

Å

½

,¾ Ò

...

In the above calculation, the symbolÄ

denotes the direct product operator for matrices. The justification

for direct product computation is based on the observations:

14



User User UserUser1 2 3 n

Server

Browser

(a) Non-Linear Architecture

S1 C3 G3

S1 C4 G3

S1 C4 G3

S2 C3 G2

S2 C3 G3

S3 C3 G3

S1 C4 G3S1 C3 G3 S1 C1 G4S4 C3 G3S3 C3 G3S2 C3 G3

S1 C1 G1

S2 C2 G1S1 C1 G1

S4 C3 G3

S1 C1 G4

S2 C2 G1

S2 C3 G2

S1 C3 G3

S3 C3 G3S2 C3 G3

S2 C3 G2

S2 C2 G1

S1 C1 G1 S1 C1 G4

S4 C3 G3

P

P

PP

P12

23

34

45

8991

P68

P44

P

P66

P77

74

P

56

55

67

33P

P22

P

PP

0 0 0 0 0 0 0

0 0 0 0 0 0 0

1

1

0

0 0 0 0 0 0

000000

0 0 0 0 0

0000

0

0

0

0

0

0

0 0

0

0 0

0

00

0

1

0 0 0 0 0

0

0

0

0

0

0

0

1/61/2

0

1/2 1/2

1/2 1/2

1/2 1/2

1/2 1/2

1/2 1/2

0

1/3

(b) Markov Model

Figure 9: User-Browser-Server Non-Linear Model

̄

the event Ø

from a new User object can come when the current system configuration is in any one

of its states in which the Browser object can receive it, (i.e; Get? is not time constrained); that isÅ

½

for the new User-Browser-Server interaction is independent of Å

́ ½ µ

℄

½ , and

̄

when a new user joins the system there will be a three-fold increase in the size of the transition matrix

For the non-linear system in Figure 5(c), assume that users join the system,one at a time, at times¼

,¾

,

,

.So,

½

¾

¾

¾

¿

½

. The transition matrix of the system at different time points are shown below:

At time 0 or 1: (1 user):Å

½

At time 2: (2 users):Å

´ ¾ µ

Å

¾

½

Ä

Å

½


´ ¿ µ

Å

´ ¾ µ

℄

¾

Ä

Å

½


´ µ

Å

´ ¿ µ

℄

Ä

Å

½

Let us consider the general case whenÖ ½

users simultaneously join the system, say when there are ½

users in the system. It is easy to see that the transition matrix for the new configuration withÖ · ½

users

isÅ

́ Ö · ½ µ

Å

́ ½ µ

℄

½

Ä

Å

́ Ö µ

½

whereÅ

́ Ö µ

½

is the direct productÅ

½

Ä

Å

½

Ä

Å

½

, takenÖ

times.

When Ö users leave the system, the transition matrix is computed as follows: Let there be ́ ¾ µ users in

the system whenÖ ´ ½ Ö µ

users leave. If Ö

, then the transition matrix is not defined. If Ö

,

there are Ö

users left in the system. If

is the interval of time that elapsed between the latest time when

there were Ö

users in the system and the current instant, then the new transition probability matrix is

15



Å

́ Ö µ

℄

. The rationale is that the transition probability matrixÅ

́ Ö µ

for Ö

users have evolved over

time steps.

5 Reliability Measures

The reliability prediction for a system configuration composed from

reactive objects is defined as the level

of certainty quantified by the source Ü × × Ò Ø Ö Ó Ô Ý

:

Ê Ð Ð Ø Ý ́ Ë Ù × Ý × Ø Ñ µ

½

À

À

whereÀ

È

Ú

È

Ô

Ð Ó Ô

is a level of uncertainty of the Markov system corresponding to a

subsystem;Ú

is a steady state distribution vector for the corresponding Markov system and the Ô

values

are the transition probabilities.À

is a level of uncertainty in a Markov system corresponding to a reactive

object. For a transition matrixÈ

the steady state distribution vectorÚ

satisfies the propertyÚ È Ú

. The

level of uncertaintyÀ

is related exponentially to the number of paths that are ”statistically typical” of the

Markov system. Thus, higher entropy value implies that more sequences must be generated in order to

accurately describe the asymptotic behavior of the Markov system. We illustrate the calculation of our

reliability measure on two configurations of the case study shown in Figure 8 and 9.

Ê Ð Ð Ø Ý ́ Ù Ö µ À

Í × Ö

· À

Ë Ö Ú Ö

· À

Ö Ó Û × Ö

À

Ù Ö

whereÀ

Í × Ö

À

Ë Ö Ú Ö

À

Ù Ö

¼

. For calculatingÀ

Ö Ó Û × Ö

we will need the the steady vector

of the Browser:Ú

Ö Ó Û × Ö

½ ¾ ¾ ½ ¾

. Then,À

Ö Ó Û × Ö

¾ · ½ ¼

. Therefore,

Ê Ð Ð Ø Ý ́ Ù Ö µ ¼

.

We calculate the reliability for Figure 9 at time step ¼

:

Ê Ð Ð Ø Ý ́ Ù Ö µ À

Í × Ö

· À

Ë Ö Ú Ö

· À

Ö Ó Û × Ö

À

Ù Ö

, whereÀ

Í × Ö

À

Ë Ö Ú Ö

¼ À

Ö Ó Û × Ö

¼

, andÀ

Ù Ö

= ́ Ú

¾

· Ú

¿

· Ú

· Ú

· Ú

µ ¢ Ð Ó

½

¾

· Ú

¢ ́

¿

Ð Ó

¿

·

½

Ð Ó

½

µ ¼

.

Therefore,Ê Ð Ð Ø Ý ́ Ù Ö µ Ê Ð Ð Ø Ý ́ Ù Ö µ

. The above measurement data collected on

two different configurations for the case study given above, tests the consistency of the reliability measures.

The reliability prediction for a system is defined as the least reliability measure value among itsÑ

subsys-

tems:

Ê Ð Ð Ø Ý ́ Ë Ý × Ø Ñ µ Ñ Ò Ê Ð Ð Ø Ý ́ Ë Ù × Ý × Ø Ñ

µ

Ñ

We chose the minimum value due to the safety-critical character of the real-time reactive systems. Higher

value of reliability measure implies less uncertainty present in the model, and thus higher level of software

reliability.

The Markov model of a configured system changes when the system undergoes change. The calculation

of the Markov matrix for the reconfigured system would allow to compare the systems based on reliability

prediction. If the system configuration

½

changes to the configuration

, we need to calculate the

reliability of the configuration

and compare it with the reliability of the configuration

½

:

Ê Ð Ð Ø Ý ́

½

µ Ñ Ò Ê Ð Ð Ø Ý ́ Ë

µ

Ñ

16



whereË

is a subsystem of

½

, and

Ê Ð Ð Ø Ý ́

µ Ñ Ò Ê Ð Ð Ø Ý ́ Ë

¼

µ

Ñ

whereË

¼

is a subsystem of

. If Ê Ð Ð Ø Ý ́

µ Ê Ð Ð Ø Ý ́

½

µ

, then the uncertainty present in the

reconfigured system is less than the uncertainty that existed in the current system. The reliability measure-

ment will allow the reconfigured system to be deployed. However, if Ê Ð Ð Ø Ý ́

µ Ê Ð Ð Ø Ý ́

½

µ

,

then there is more uncertainty present in the reconfiguration. This would suggest to determine the subsys-

tem(s) of

that are responsible for lowering the overall reliability.

6 Conclusions and Research Directions

The main result of this paper is a formal approach to calculate the reliability of a time-dependent Web

application. The Web model discussed in the paper is simple, yet representative of the different Web layers.

The model can be generalized to include more Web components:

̄

a browser linked to several servers,

̄

users interacting with Agents, who in turn interact with browsers/servers, and

̄

servers protected by firewalls, and hence a model of firewall will have to be included as well.

In a practical setting, the number of Web components and their interactions will be large. There are also other

factors such as resource constraints, load factor, and communication complexity. From a reliability point of

view, we require a good formal model which takes these factors into account. In the formal model proposed

in this paper the load factor and communication delays can be brought in as synchronization constraints, and

resources can be modeled within each class (such as the Set in Browser class) and timing constraints may be

imposed on database transactions. Calculation of transition probabilities for large evolving configurations

involves multiplying fairly large matrices. The density of the transition probability matrix of a system

depends on the number of transitions in the product matrix, which due to synchronization constraints, might

be sparse. The sparsity of the matrix and the availability of very fast powering and multiplication algorithms

for matrices may be used to speed up reliability calculation for changing configurations.One of our goals is to empirically evaluate the reliability model. This is one aspect of our ongoing study

in metrics and measurements for real-time reactive systems.

References

[AAM98] V.S. Alagar, R. Achuthan, D. Muthiayen. TROMLAB: A Software Development Environment for Real-Time Reactive Systems. Technical Report, (first version 1996, revised 1998), Concordia Univer-sity, Montreal, Canada.

[IEEE90] IEEE Standard Glossary of Software Engineering Terminology. IEEE Std 610.12.1990.

[KT2001] Chaitanya Kallepalli, Jeff Tian. Measuring and Modeling Usage and Reliability for StatisticalWeb Testing. IEEE Transactions on Software Engineering, Nov. 2001 (Vol.27, No.11), pp.1023–1036.

[O2002] Olga Ormandjieva. Quality Measurement for Real-Time Reactive Systems Ph.D thesis, Departmentof Computer Science, Concordia University, Montreal, Canada, January 2002.

17

Date post:	06-Apr-2018
Category:	Documents
Upload:	prakhar-asthana
View:	225 times
Download:	0 times

Reliability Assessment OfWEB Applications

Documents