The EDM Design Problem

The EDM design problem concerns the derivation of a boolean predicate over program variables that can be used for the detection of erroneous system state, i.e., errors. In contrast to the substantial body of knowledge that relates to the location of EDMs, comparatively little is known that pertains to the design of efficient error detection predicates for EDMs, particularly for real-world, infinite state software systems. Note that the phrase “infinite-state software systems” is used to refer to software systems whose state space makes finite-state modelling impractical. Indeed, most real-world software systems will be of this kind, as given a software system with a reasonably small number of program variables, even where these variables have a limited set of associated states, the state space of the software system can be too large for a human to interpret and analyse as a set of actions and state transitions.

The efficiency properties of an error detection predicate can be characterised along two dimensions; accuracy and completeness. The accuracy property re- flects the capability of an error detection predicate to avoid detecting non- erroneous states as errors, whilst completeness refers to the capability of an error detection predicate to detect erroneous states as errors [70]. In the con-

2. Software Dependability

text of finite state systems, which are typically represented as state transition systems, the issue of error detection predicate design has been well considered. In particular, research in [70] and [91] developed polynomial-time algorithms for the automatic refinement of error predicates predicates, i.e., algorithms capable of improving the efficiency properties of an existing error detection predicate in polynomial-time. However, as finite-state systems can be viewed as an ap- proximation to real-world, infinite state software systems, these approaches are not applicable for most real-world software systems. Indeed, the EDM design problem has received little attention in existing research literature.

The research presented in this thesis is primarily concerned with addressing the EDM design problem for real-world, infinite state software systems. More specifically, the work presented provides novel approaches for (i) the automated identification of program variables that must be captured by efficient error de- tection predicates, (ii) the generation of efficient error detection predicates, and dependability enhancement through the protection of identified program vari- ables with software-wrappers implementing efficient EDMs. Crucially, when taken in contribution these contribution serve to support the thesis that an ef- ficient EDM consists of a set of critical variables.

The concepts described in this chapter are by no means exhaustive in their coverage of topics in software dependability. However, the overview of topics presented provides a sufficient perspective on software dependability to allow the contributions of this thesis to be appreciated.

CHAPTER

3

Models

The models described in this chapter provide information about the context in which the contributions made by this thesis have been developed. In particular, the software system model assumed in the development of these contributions, and the fault model under which they were evaluated are detailed in this chapter. Information regarding the experimental setup that embodied these models is also provided in this chapter, including full details of all target systems, test cases, system failure specifications, software system instrumentation procedures, and dependability validation techniques used throughout this thesis.

3. Models

3.1

System Model

A software systemS is considered to be a tuple, consisting of a set of software modules,M1. . . Mn, and a set of connections. A software moduleMkconsists of

an import interfaceIk, an export interfaceEk, a set of non-composite program

variablesVk and a sequence of actionsAk1. . . Aki. Each program variable inVk

has a specific domain of values. Each action inAk1. . . Akimay read or write to

a subset of Vk. Two software modulesMk andMl are connected if the export

interface of Mk is matched with the import interface ofMl, i.e., a connection

exists if Ek is matched with Il. Thus, a software system S = (M OD, CON),

where M OD = _{M1. . . Mn}, and CON = {(Mka, Mla)}, where Mk exports

to the import interface of Ml over connectiona. We assume a software mod-

ule ENV that exports inputs to the software system and imports output from the software system. Figure 3.1 shows an example of the assumed system model. Relating this example to the definitions given, it follows that if a soft- ware system S = (M OD, CON), then M OD ={EN V, M1, M2, M3, M4} and CON = {(Mb 1, M2b), (M1c, M3c), (M1d, M3d), (M2e, M3e), (M f 2, M f 4), (M g 3, M g 4), (EN Va, M1a), (M4h, EN Vh)}.

A software system is assumed to be grey box, meaning that access to source code is permitted, but knowledge of functionality, implementation details and structure is not assumed. It is the variable-centric focus of the contributions made in this thesis that necessitates this white box access, whilst the adoption of a generic model of software systems is motivated by the desire to ensure that the contributions made are widely applicable.