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