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 specication and system conguration descriptions. Keywords: reliability prediction, software measurement, Markov model.

1 Introduction
The reliability of a software system is dened in [IEEE90] as the ability to perform the required functionality under stated conditions for specied 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 scientic quantitative measurement of the reliability of the site. This paper proposes a methodology for an assessment of quality of Web application components through reliability prediction, when a formal model of the Web application could be specied 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 les. Web failure is dened as the inability to correctly deliver information or documents required by Web users. Based on this denition 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 assessment 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 congurations 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 les, the source used for statistical testing in [KT2001]. We give methods for calculating Markov matrices for synchronously interacting Web components 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 important 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 nite 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 dened by the buttons and the whistles specic 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 a different state as specied 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.

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 complex 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 the log le 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 les and other subjective opinions of experts can not be used for predicting the reliability of the system. We contend that the reliability should be 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 the reliability prediction measures. Section 6 concludes the paper with a discussion on our ongoing research directions.

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 realtime 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 sufcient. 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 discussed 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 nite 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 identies, 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 nite number of ports and assigning the ports to the object. Any message dened 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. is a copy of with a name different from the name of any other object An incarnation of an 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 ids. Letting ids 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 dened 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

congurations 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 specied by a nite 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 nite 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 specic 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 are dened 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 specied 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-dened, 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 , denoting that the event occurs at time , at a port called a signal and is represented by a tuple . 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 , receives a signal and there exists a transition object occurs when the object with status specication that can change its status. A computation of an object is a sequence, possibly innite,

. Typically, the Web system is nonof alternating statuses and signals, terminating; consequently, a computation is in general an innite sequence. The set of all computations of an object is denoted by . The computation of the Web system is an innite sequence of system statuses and signals that effect status changes [AAM98]. A period is a nite subsequence of the Web computation such that it starts with some initial state and nishes 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 sufcient to illustrate the reliability calculation. Extension of our approach to more complex and detailed models are not difcult. 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

<<GRC>> User <<PortType>> cr : @C

<<PortType>> @C events : Set = {Get!,Exit!}

<<PortType>> @G events : Set = {Permit!,StopPermit!}

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

<<PortType>> @P events : Set = {Get?,Exit?}

<<PortType>> @S events : Set = {Permit?,StopPermit?}

<<GRC>> Server

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 to 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 satises 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 . The Browser class has two port types, @ with User class has one port type with signature signature , and @ with signature . The Server class has one port type with signature . The gure 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 identier 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 specication includes structural and behavioral information. User Model The statechart diagram for User is shown in Figure 2(a). The signicant 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 the 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 identier 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 (specied 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 (specied 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 specication of the User class is shown in Figure 2(b).

S1: idle

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

S2: toAccess

Exit[ pid=cr && true && TCvar2<6 ] In[ true && true && TCvar1>2 AND TCvar1<4 ]

S4: leave Out

S3: access

(a) User Statechart

Class User [@R] Events: Get!@R, Out, Exit!@R, In States: *idle, access, leave, toAccess Attributes: cr:@C Traits: AttributeFunction: idle ; access ; leave ; toAccess cr ; TransitionSpecications: R1: idle,toAccess ; Get(true); true R2: access,leave ; Out(true); true R3: leave,idle ; Exit(pid = cr); true R4: toAccess,access ; In(true); true TimeConstraints: TCvar2: R1, Exit, [0, 6], ; TCvar1: R1, In, [2, 4], ; end

cr =pid; true; true; true;

(b) User class Specication

Figure 2: User Class

Get[ NOT(member(pid,inSet)) && true ] / inSet=insert(pid,inSet) Get / inSet=insert(pid,inSet) &&TCvar1=0 C1: idle C2: activate

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

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

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

C4: deactivate

C3: monitor

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

(a) Browser Statechart

Class Browser [@P, @Y] Events: Permit!@Y, Get?@P, StopPermit!@Y, Exit?@P States: *idle, activate, deactivate, monitor Attributes: inSet:PSet Traits: Set[@P,PSet] AttributeFunction: inSet ; deactivate inSet ; activate monitor inSet ; idle ; TransitionSpecications: 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); TimeConstraints: TCvar1: R7, Permit, [0, 1], ; TCvar2: R4, StopPermit, [0, 1], ; end

(b) Browser class Specication

Figure 3: Browser class

G1: idle

Permit / true && TCvar1=0

G2: toOpen

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

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

G3: toClose StopPermit / true && TCvar2=0

G3: opened

(a) Server Statechart

Class Server [@S] Events: Permit?@S, Allow, DisAllow, StopPermit?@S States: *Idle, toClose, toOpen, opened Attributes: Traits: AttributeFunction: ; toClose ; Idle toOpen ; opened ; TransitionSpecications: true; R1: Idle,toOpen ; Permit(true); true R2: toOpen,opened ; Allow(true); true true; true; R3: toClose,Idle ; DisAllow(true); true true; R4: opened,toClose ; StopPermit(true); true TimeConstraints: TCvar1: R1, Allow, [0, 1], ; TCvar2: R4, DisAllow, [1, 2], ; end

(b) Server class Specication

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 identier 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 rst 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 specicaiton is shown in Figure 4(b).
@C1 : @C user1 : User Server1 : Server @S1 : @S

@P1 : @P

Browser1 : Browser

@G1 : @G

(a) Collaboration Diagram - Simple System

SCS UserServerBrowser Includes: Instantiate: Server1::Server[@S:1]; User1::User[@C:1]; Browser1::Browser[@P:2, @G:1]; Congure: Browser1.@G1:@G Server1.@S1:@S; Browser1.@P1:@P User1.@C1:@C; end

(b) System Specication - Simple System

user1:User

user2:User

user3:User

user4:User

user5:User

@C1: @C

@C2: @C

@C3: @C

@C4: @C

@C5: @C

@C6: @C

@P1: @P

@P2: @P

@P3: @P

@P4: @P

@P5: @P

@P6: @P

Browser1:Browser

Browser2:Browser

@G1: @G @S1: @S

@G2: @G @S2: @S

Server1:Server

Server2:Server

(c) Collaboration Diagram - Complex System

SCS UserServerBrowser Includes: 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]; Congure: 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 User3.@C4:@C; Browser2.@P5:@P User4.@C5:@C; Browser2.@P6:@P User5.@C6:@C; end

(d) System Specication - Complex System

Figure 5: System Conguration Models and Specications A system conguration specication denes objects instantiated from the three classes and their interactions. Figure 5(a) is a collaboration diagram in UML style for a linear system with one user object, one server object, and one server object. The formal specication for this system is shown in Figure 5(b). A more complex system, that is non-linear, consisting of ve users, two browsers and two servers is shown in Figure 5(c). In this conguration, user3 is allowed to access both browsers, while the other user objects interact with only one browser. The formal specication for this subsystem conguration is shown in Figure 9

5(d). In both specications, there is no included subsystem. In the Instantiate section, objects are created, and in the Congure section compatible ports of objects are linked. The behavior of a system conguration specication can be simulated by applying the operational semantics to the system starting in some initial conguration.

4 Markov Models
We construct the Markov model of a Web system in three steps. In the rst 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 conguration specication. Finally in the third step we construct the Markov model for the fully congured system.

4.1 Step 1: Markov Models for Objects

We associate with each Web object in the architecture another nite 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 dened 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 probability in each state. For the transition from state to state in the Markov model, a xed 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.
of the same type (shared/internal) from state to 2. In case there is more than one transition state , 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 12 S1 p
41

S2 p 23 S3 p
34

S1 S2 S1 0 1 S2 0 S3 0 S4 1 0 0 0

S3 0 1 0 0

S4 0 0 1 0

S4

(a) User Class

p 12 G1 p
41

G2 p 23 G3 p
34

G1 G2 G1 0 1 G2 0 G3 0 G4 1 0 0 0

G3 0 1 0 0

G4 0 0 1 0

G4

(b) Browser Class

p p 12 C1 p
41 22

C2 p 23 p 34 C3 p33

C1 C2 C1 0 1 C2 0 C3 0 C4 1

C3 0

C4 0 0

1/2 1/2

0 0

3/4 1/4

C4

(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 rst 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 rst, and the remaining measure is distributed to transitions labeled by internal events. 11

Algorithm SPM Step 1. Step 2.

row sum 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 then

calculate probabilities for transitions due to shared events (Normalization Factor); ;

Step 3.1 For each event Step 3.2 Step 3.3 Step 3.4

, if

nd the (set of) states

( ) and

() such that

Step 3.5 Step 4. If then

calculate probabilities for transitions due to internal events

(Normalization Factor);

; then

Step 4.1 For each event nd the state

, if

( ) such that if

else nd the state

( ) such that if

Step 5. If Step 6.If For each

, the

row is deleted from

do

12

P 12
S1,C1 S2,C2

23

S1,C1 S2,C3 S1,C1 S2,C2 0 0 0 0 0 1

S2,C2 1 0 0 0 0 0

S2,C3 0 1 0 0 0 0

S3,C3 S4,C3 0 0 1 0 0 0 0 0 0 1 0 0

S1,C4 0 0 0 0 1 0

P 61 P 56
S1,C4 S4,C3

P 34 P 45
S3,C3

S2,C3 S3,C3 S4,C3 S1,C4

Figure 7: Markov Model and State Transition Matrix for Synchronous Product of User and Browser Step 7. If For each

do

Step 8. If For each

do

do

Step 9. To ll 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 conguration, when partitioned, produces two types of subsystem components: (1) linear subsystem conguration, as shown in Figure 8(a), and (2) non-linear subsystem conguration 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 2. for

(Apply Algorithm SPM)

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

Ini

User

Browser

Server

synchronize

synchronize

(a) Linear Architecture

S1 C1 G1

P 89
S1 C1 G4
S1 C1 G1 S2 C2 G1 S2 C3 G2 S2 C3 G3 S3 C3 G3 S4 C3 G3 S1 C4 G3 S1 C1 G4

P 12
S2 C2 G1

P 78
S1 C4 G3

S1 C1 G1 S2 C2 G1 S2 C3 G2 S2 C3 G3

P 23
S2 C3 G2

P 67
S4 C3 G3

S3 C3 G3 S4 C3 G3 S1 C4 G3

P 34 P 45
S2 C3 G3

P 56
S3 C3 G3

S1 C1 G4

0 0 0 0 0 0 0 1

1 0 0 0 0 0 0 0

0 1 0 0 0 0 0 0

0 0 1 0 0 0 0 0

0 0 0 1 0 0 0 0

0 0 0 0 1 0 0 0

0 0 0 0 0 0 0 0

0 0 0 0 0 0 1 0

(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 dont leave the system. Let be the intervals of the -th user joins the system successive arrivals of users. That is, for 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:

. . .

. . .

denotes the direct product operator for matrices. The justication In the above calculation, the symbol for direct product computation is based on the observations: 14

User 1

User 2

User 3

User n

Browser

Server

(a) Non-Linear Architecture

S1 C1 G1

P 91
S1 C1 G4

P 89
S1 C1 G1 S2 C2 G1 S2 C3 G2 S2 C3 G3 S3 C3 G3 S4 C3 G3 S1 C3 G3 S1 C4 G3 S1 C1 G4

P 12 P 22
S2 C2 G1

P 74
S1 C3 G3

S1 C1 G1 S2 C2 G1

77

S2 C3 G2 S2 C3 G3

P 23 P
33

P67
S4 C3 G3

P 68
S1 C4 G3

S3 C3 G3 S4 C3 G3 S1 C3 G3

S2 C3 G2

P 66 P 34 P 56 P 45
S2 C3 G3 S3 C3 G3

S1 C4 G3

P
44

P55

S1 C1 G4

0 0 0 0 0 0 0 0 1

1 0 0 0 0 0 0 1/2 1/2 0 0 0 0 0 0 1/2 1/2 0 0 0 0 0 0 1/2 1/2 0 0 0 0 0 0 1/2 1/2 0 0 0 0 0 0 1/3 1/2 1/6 0 0 1/2 0 0 1/2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 1 0

(b) Markov Model

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

the event from a new User object can come when the current system conguration 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): At time 4: (3 users): At time 5: (4 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 conguration with users where is the direct product , taken times. is When users leave the system, the transition matrix is computed as follows: Let there be users in users leave. If , then the transition matrix is not dened. If , the system when 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 time steps.

for

users have evolved over

Reliability Measures
reactive objects is dened as the level

The reliability prediction for a system conguration composed from of certainty quantied 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 . The object. For a transition matrix the steady state distribution vector satises the property 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 congurations of the case study shown in Figure 8 and 9.

where of the Browser:

. For calculating we will need the the steady vector . Then, . Therefore,

. :

We calculate the reliability for Figure 9 at time step

, and

, where

Therefore, . The above measurement data collected on two different congurations for the case study given above, tests the consistency of the reliability measures. The reliability prediction for a system is dened as the least reliability measure value among its subsystems:

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 congured system changes when the system undergoes change. The calculation of the Markov matrix for the recongured system would allow to compare the systems based on reliability prediction. If the system conguration changes to the conguration , we need to calculate the reliability of the conguration and compare it with the reliability of the conguration :

16

where is a subsystem of

, and

where is a subsystem of . If , then the uncertainty present in the recongured system is less than the uncertainty that existed in the current system. The reliability measurement will allow the recongured system to be deployed. However, if , then there is more uncertainty present in the reconguration. This would suggest to determine the subsystem(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 rewalls, and hence a model of rewall 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 congurations 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 congurations. 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, (rst version 1996, revised 1998), Concordia University, 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 Statistical Web Testing. IEEE Transactions on Software Engineering, Nov. 2001 (Vol.27, No.11), pp.10231036. [O2002] Olga Ormandjieva. Quality Measurement for Real-Time Reactive Systems Ph.D thesis, Department of Computer Science, Concordia University, Montreal, Canada, January 2002.

17