Software Component Independence - Semantic Scholar

1 downloads 0 Views 117KB Size Report
Nov 13, 1998 - component independence and use the CPS trans- formation to convert ..... amount of free memory or the time of day, are cer- tainly state in the ...
Software Component Independence Denise M. Woit dwoit@scs .ryerson.

David V. Mason ca dmason@sc s.ryerson

.ca

School of Computer Science Ryerson Polytechnic University 350 Victoria Street Toronto, Ontario Canada M5B 2K3 1998 November 13

Abstract Independence is a fundamental requirement for calculating system reliability from component reliabilities, whether in hardware or software systems. Markov analysis is often used in such calculation; however, procedures as conventionally used do not qualify as nodes in a Markov system. We outline the requirements for several classes of component independence and use the CPS transformation to convert conventional procedures into fragments appropriate to Markov analysis.

1 Introduction

or some mixture [6, 5, 4, 8, 3].

In Markov

models, system behavior is modeled by a set  

 , and transiof system states,   tion rates/probabilities among states,     ! . The Markov model assumes "#  de pends only upon  . This is known as the Markov property. Without loss of generality, in the sequel  we will refer to the  as nodes rather than states. This is necessary to reduce ambiguity, because we will use the term state to refer to program state.  In hardware systems, an  is usually considered some distinct combination of working and  failed components. For each  , each $  is composed of the failure rates or repair rates of its com-

Markov or semi-Markov models are typically

ponents. Nodes are partitioned into those repre-

used to calculate estimations of overall sys-

senting system failure, and those not. Reliability

tem reliability from constituent component re-

is calculated as the probability of the system resid-

liabilities.

ing in a non-failure node [6].

Such modeling is typical for sys-

tems whose components are hardware, software,

A similar approach has been presented for sys-

tems comprised entirely or partly of software com ponents [5, 3, 2, 11]. A node,  is a set of components under execution. "#  is the probability   of execution transition from  to  . For sys tems with sequential execution properties, an  contains only one component; for systems with  non-sequential execution properties, an  contains more than one component. In the sequel, we consider sequential systems, without loss of gen   , where   is the  comerality; thus,  ponent of the system, and "#  is the probability of

 execution transition from

 to

 . The ordering  of the components is not relevant except that 



must be distinguished as the start component–that which is initially executed upon system start-up. For systems comprised entirely or partly of software components Markov models have been used to calculate measures such as steady-state system availability and system reliability from the reliabilities of constituent hardware/software components [5, 3, 2].

lieve that typical systems involving software components have properties such that modeling these systems in a Markovian fashion is not feasible. Because the underlying Markov property is violated, the resulting system reliability estimations are not meaningful. In Section 2 we will show that systems involving software components have component transition properties which do not coincide with the underlying structure of the Markov models. We then present a method by which systems can be transformed (or designed) so that their transition properties can be adequately represented by Markov models.

The independence assumption is one

that is necessary for computing system reliability from component reliability, regardless of the model used [4, 5, 3, 2]. A small portion of the independence problem is addressed by the methods of Section 2. The remainder of the problem is addressed in Section 3. In this section we outline properties of component independence, and we il-

When Markov and semi-Markov models are uti-

lustrate that the restricted level of independence

lized for systems with software components, the

typically assumed necessary for Markov calcula-

resulting reliability estimations are not meaning-

tions is not normally present in existing systems.

ful unless the Markov model is a good represen-

We outline methods by which components can

tation of the actual system. Because they relate

be constructed so that the independence proper-

to establishing the Markov property, the following

ties are satisfied. Section 4 describes methods

two factors significantly influence the adequacy of

by which models can be constructed so that they

the representation: (1) the nature of physical tran-

can adequately incorporate all notions of inde-

sition properties within the given system; (2) com-

pendence among components, rather than the re-

ponent independence in the given system. We be-

stricted version of Section 3.

2 State Transition Properties and CPS In this section we identify inconsistencies between software systems and the Markov models typically used to represent them. We outline how these problems can be overcome by using Continuation Passing Style (CPS)[1]. Parnas [10] differentiates between the mutually exclusive relations “uses” and “invokes”.      USES(   ) = iff  calls  and  will be con-



sidered incorrect if  does not function properly.     INV(   ) = iff  passes control to  but does

void A() { (define (A) 1 int x=0; (define x 0) 2 do { (define (loop) 3 if (x%2==0 ) (if (even? x) 4 B(x); (B x) 5 else 6 C(x); (C x)) 7 x=x+1; (set! x (+ x 1)) 8 } while (x