Post on 06-Apr-2018
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.
8/3/2019 Reliability Assessment OfWEB Applications
http://slidepdf.com/reader/full/reliability-assessment-ofweb-applications 2/17
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
8/3/2019 Reliability Assessment OfWEB Applications
http://slidepdf.com/reader/full/reliability-assessment-ofweb-applications 3/17
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
8/3/2019 Reliability Assessment OfWEB Applications
http://slidepdf.com/reader/full/reliability-assessment-ofweb-applications 4/17
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
8/3/2019 Reliability Assessment OfWEB Applications
http://slidepdf.com/reader/full/reliability-assessment-ofweb-applications 5/17
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
8/3/2019 Reliability Assessment OfWEB Applications
http://slidepdf.com/reader/full/reliability-assessment-ofweb-applications 6/17
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
8/3/2019 Reliability Assessment OfWEB Applications
http://slidepdf.com/reader/full/reliability-assessment-ofweb-applications 7/17
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
8/3/2019 Reliability Assessment OfWEB Applications
http://slidepdf.com/reader/full/reliability-assessment-ofweb-applications 8/17
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
8/3/2019 Reliability Assessment OfWEB Applications
http://slidepdf.com/reader/full/reliability-assessment-ofweb-applications 9/17
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
–
User3.@C4:@C;Browser2.@P5:@P
–
User4.@C5:@C;Browser2.@P6:@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
8/3/2019 Reliability Assessment OfWEB Applications
http://slidepdf.com/reader/full/reliability-assessment-ofweb-applications 10/17
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
8/3/2019 Reliability Assessment OfWEB Applications
http://slidepdf.com/reader/full/reliability-assessment-ofweb-applications 11/17
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
8/3/2019 Reliability Assessment OfWEB Applications
http://slidepdf.com/reader/full/reliability-assessment-ofweb-applications 12/17
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
8/3/2019 Reliability Assessment OfWEB Applications
http://slidepdf.com/reader/full/reliability-assessment-ofweb-applications 13/17
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
8/3/2019 Reliability Assessment OfWEB Applications
http://slidepdf.com/reader/full/reliability-assessment-ofweb-applications 14/17
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
8/3/2019 Reliability Assessment OfWEB Applications
http://slidepdf.com/reader/full/reliability-assessment-ofweb-applications 15/17
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):Å
´ ¾ µ
Å
¾
½
Ä
Å
½
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 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
8/3/2019 Reliability Assessment OfWEB Applications
http://slidepdf.com/reader/full/reliability-assessment-ofweb-applications 16/17
Å
́ Ö µ
℄
. 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
8/3/2019 Reliability Assessment OfWEB Applications
http://slidepdf.com/reader/full/reliability-assessment-ofweb-applications 17/17
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