Software Theory Change · Previousworks formaloperationsofAGMbeliefchange,see [Alchourrón,Gärdenfors,Makinson(1985)] [Zowghietal. (1996)]requirementsevolutionintermsofbelief

Software Theory Change

Giuseppe Primiero(joint work with Nikos Gorogiannis and Franco Raimondi)

Department of Computer ScienceMiddlesex University, UK

Interactions entre informatique, logique et langage:histoire et philosophie

Lille3

Primiero 21 January 2015 1 / 48

1 Software Change

2 Software Theory

3 Requirements Evolution

4 Inferential-based resilience


1 Software Change

2 Software Theory




Introduction

Software change is a critical step in the life-cycle of computational systems.

The process of modifying or re-defining specification properties ofa system, partly due to its increasing architectural complexity,partly required to improve software quality.


Introduction

Laws of software evolution (e.g. [Lehman (1980), Lehman et al. (1997)])are often considered part of the late life-cycle of the system; see also[Ernst et al. (2009)]:

dictated by architectural degeneration (violation or deviation of thearchitecture, increasing with changes being made to the original, seee.g. [Eick et al. (2001), Lindvall et al. (2002)])

or flexibility requirements (the system property that defines the extentto which the system allows for unplanned modifications,[Port, Liguo (2003)])

Resilience as functionality preservation under such typical changes is ofparamount importance to system evolution.


Introduction

Change classification schemes are largely used to assess, from a qualitativepoint of view, the impact and risk associated with software evolution

[Mens et al. (2005)] formulate an explicit requirement that the notionof change be analysed and integrated in the conventional softwaredevelopment process model;

a model of software change for the early life-cycle of systems (designand implementation stages) is essential to assess and anticipate thepresence of errors or bugs, and in general when determining system’sreliability.


Malfunctioning for both early and late stages

A general understanding of malfunctioning can be addressed at twodifferent levels, see [Floridi et al. (2014)]:

disfunctioning : the system is less reliable or effective than one expectsin performing its function;

misfunctioning : the system produces some negative side-effects whichother systems of the same type do not produce.


Types of change

Testing can only be subsumed under the category of correctivechanges, i.e. those resulting from response to defects.

disfunctioning addressed at early stages of design can be subsumedunder the category of perfective changes, resulting from new orchanged requirements.


Assumptions of this work

1 Software change can be modelled similarly to scientific theory changeto account for both perfective and corrective changes in theimplementation;

2 Software engineering can be regarded abstractly as building andmanaging of the (possibly large) deductive closure of a set of axioms.

3 A violation of the model specification in the implementation leads to arevision of the examined model. Revision is given in terms ofexpansion and safe contraction; property resilience is defined in view ofsuch changes, and generalised to a definition of system resilience.


Previous works

formal operations of AGM belief change, see[Alchourrón, Gärdenfors, Makinson (1985)]

[Zowghi et al. (1996)] requirements evolution in terms of beliefchange operations (but without formal developments).

[Dam, Ghose (2014)], belief revision for change propagation in modelevolution.

software as theory, see e.g. [Moor (1978)], [Rapaport (2014), ch.15].

software testing differs strongly from the theory and practice of testingscientific hypotheses, [Angius (2014)].

software as theory in model checking, [Angius, Tamburrini (2011)]


1 Software Change

2 Software Theory




Model of a Computational System

A representation of the intended system’s behaviour, i.e. the set of law-likeexpressions that formulate requirements of valid input states, and the resultof actions in output states.

Definition (Software Model)A software model Sm is a relation

Sm :=< preconditions ⇒ [p]postconditions >

saying that given a list of preconditions, the execution of program variablep necessarily leads to some state satisfying a list of postconditions.


Model of a Computational System

At early stages, Sm can be interpreted in terms of a list of informalrequirements, program operations and output states.

Identified preconditions are meant to guarantee safety of programexecution.

Identifying preconditions that (may) lead to execution failure of aninstance of p allows to define completeness.


Oracle

A complete description of a model Sm is akin to what in software testingresearch is known as an oracle,

a “procedure that determines what the correct behaviour of asystem should be for all input stimuli with which we wish tosubject the system under test” ([Harman et al. (2013)]).


Oracle as right theory

A model Sm of a correctly functioning computational system – ororacle – mimics the notion of right theory for a software system.

Sm is understood as the perfect description of design-for-testprinciples, which can be accompanied by a (possibly complete) formalspecification of the intended behaviour.

Where completeness is not achieved, a partial or near-complete oracleoffers postconditions for some given inputs, and could offer alternativemeans for other inputs (metamorphic testing and derived informationform executions being examples).


Implementations

An implementation Si should be intended as an actual realization ofthe model;

A working implementation is an artefact in which for every executionof the program p, the actualised properties do not diverge from thecorresponding law-like idealizations in the model;

A malfunctioning implementation is one where divergences from themodel manifest themselves, i.e. a possible execution of p in Si notleading to a state satisfying postconditons as those expressed in Sm.


Malfunctions

Definition (Faulty program execution)An execution of pi ∈ Si is faulty when actual postconditions diverge fromexpected ones of p in Sm.

Definition (Malfunctioning implementation)We say that Si is malfunctioning, and the corresponding abstractspecification near-complete with respect to Sm iff it accommodatespossibly faulty execution of program pi .


Malfunctions

Definition (Faulty program execution)An execution of pi ∈ Si is faulty when actual postconditions diverge fromexpected ones of p in Sm.

Definition (Malfunctioning implementation)We say that Si is malfunctioning, and the corresponding abstractspecification near-complete with respect to Sm iff it accommodatespossibly faulty execution of program pi .


Introducing Changes

In the case of diverging descriptions of Si from Sm, perfective orcorrective changes might be applied to produce a new model S ′

m

S ′m either accommodates the divergences, or eliminates some of the

current (undesired) properties of the model Sm

Under this reading, requirements evolution formally corresponds to amapping Sm 7→ S

′m

the process of approximating from the near-complete model Sm ofspecification of Si to a safe program execution of a new model S ′mcorresponds to arriving at a new correct account of a scientificphenomenon.


1 Software Change

2 Software Theory




Language for the Model

Consider a finite set of formulae

L(Sm) = φ1, . . . , φn

each φi expresses a specific behaviour that the intended software systemSm should display.


A (possible) syntax for the requirements

φi ∈ L(Sm) := [α1 . . . , αn]T [ω1, . . . , ωn]

a set of input actions A = α1, α2, . . . , a set of output states Ω = ω1, ω2, . . . , a set of transition relations T = τ1, τ2, . . .

given input actions α1, . . . αn and a set of transition relations (commands)T for each αi , output states ω1, . . . , ωn obtain.


Toy Example

given an empty array return an error, and otherwise return thenumber of instances of positive numbers contained in the array.

α1: Enter an array as input;τ1: Read the elements in the array, starting by counting the entry atposition 0;τ2: For each element with value greater than zero, add it to the count;ω1: Return the count and stop.


Theory

We refer to Sm as a theory of L(Sm), i.e. its closure under logicalconsequence

Sm = Cn(L(Sm)) := φ | L(Sm) φ

We say that Sm is consistent if Sm ¬(φ ∧ ¬φ). Informally, a formulaφi φj says that a property specification φi holding for a system Sminduces property specification φj .


Consequence Relation (Properties)

1 Sm >

2 Sm (φ1 → φ2) and Sm φ1, implies Sm φ2

3 Sm φ implies Sm 2 ¬φ

4 If Sm φ, then A ⊆ Sm → φ

5 If Sm φ, then there is a A ⊆ Sm such that A φ


Language for the Implementation

Consider a language L′ ⊆ L such that L′(Si ) where Si is an implementationof Sm with possibly diverging post-conditions when executing pi (i.e. aninstance of p from Sm).

For some φi , a theorySi = Cn(L(Si ))

is such that Si φi and Sm 2 φi or Sm ¬φi .


Toy Example

public class Testing

public int countPositive (int[] x)

int count = 0;for (int i=0; i < x.length; i++)

if (x[i] >= 0)

count++;

return count;


Toy Example (cont.)

α1: Enter an array as input;τ1: Read the elements in the array, starting by counting the entry atposition 0;τ2: For each element with value greater than or equal to zero, add itto the count;ω1: Return the count and stop.


Divergence resolution

Perfective change: change the model so that the current input in theimplementation becomes valid; Sm is expanded as to include φi , henceone handles a form of requirement incompleteness;

Corrective change: remove the specification that makes ourexperimental result wrong; Sm is contracted as to remove ¬φi : thedivergence between the implementation and the oracle reflects here aform of inconsistency.


Expansion

S ′m = (Sm)+φi

is defined by the logical closure of Sm and φi ,

(Sm)+φ = Cn(L(Sm) ∪ φ)

We take this to define the creation of a theory by considering our startingpoint Sm 2 φ, for any φ.


Contraction

(Sm)−φi= Cn(L(Sm)/φi )

where the latter indicates the result of L(Sm) once φi has been removed.We denote with L′ the language obtained from L by such removal. Thecontraction operator is then a mapping function:

Sm × L′ 7→ S ′m := (Sm, φi ) 7→ (Sm)−φi

from the set of all complete theories of Sm to a new model whoseimplementations have languages that do not imply φi .


Ordering on expressiveness

Contraction should remove with a minimal loss of functionalities; imposean ordering φi ≤ φj saying that φj is at least as embedded as φi in view ofthe functionalities of the system.

1 Transitivity: if φi ≤ φj and φj ≤ φk , then φi ≤ φk ;2 (Anti-)Dominance: if φi φj , then φj ≤ φi ;3 Conjunctiveness: either φi ≤ φi ∧ φj or φj ≤ φi ∧ φj ;4 Minimality: if Sm is consistent, then φi /∈ Sm iff φi ≤ φj for all φj ;5 Maximality: if φj ≤ φi for all φj , then φi ∈ Cn(∅).


Safe contraction

Definition (Safe Contraction, [Alchourrón, Makinson (1985)])Given a theory Sm of the language L(Sm) ordered by a transitivenon-circular relation < (or hierarchy); let φi ∈ L(Sm) express a property wewish to eliminate from Sm; then we say that a property expressed byφj ∈ L(Sm) is safe with respect to φi modulo <, if and only if φj is not aminimal element under < of any minimal L′ ⊂ L such thatφi ∈ Cn(L′(Sm)).


Safe contraction

1 (Sm)−φi∈ Sm

2 (Sm)−φi⊆ Sm

3 (φi /∈ Cn(L(Sm))→ ((Sm)−φi= Sm)

4 (φi /∈ Cn(∅))→ φi /∈ Cn(L(Sm)/φi )

5 (φi ∈ Cn(L(Sm))→ Sm ⊆ (S−φi)+φi

6 (φi ≡ φj)→ (Sm)−φi= (Sm)−φj


Properties

Definition (Counter-Continuing Down)If φi < φj , and φk φj , then φi < φk , for all φi ,j ,k ∈ Sm. In other words, ifφi is less secure for contraction than φj (hence the former should be easierto remove than the latter) and φk is more inferentially powerful than φj(hence the former should be harder to remove than the latter), then φi isalso less secure for contraction than φk .


Properties

Definition (Counter-Continuing Up)If φi φj , and φi < φk , then φj < φk , for all φi ,j ,k ∈ Sm. This says that ifφi is inferentially more powerful than φj (hence the former should be harderto remove than the latter), and φi is also strictly less secure fromcontraction than φk , then φj is strictly more secure from contraction thanφk .


1 Software Change

2 Software Theory




Previous Definitions

(graded) ability to perform a correct computation under varied orperturbated specifications

inability of the system to distinguish between behaviours that areessentially the same, see [Peled (1997)]

the ability of a system to retain functional and non-functional identity(ability to perceive environmental changes; understand theimplications; plan and enact adjustments, [De Florio (2013)])

in view of possibly conflicting value-based future configurations, abilityof the system to admit of new relations accommodating them,[Barn et al. (forthcoming)].


Inferential-based approach

Definition (Property Resilience)

Consider property specifications φi ,j ,k ∈ L(Sm). Then φk is more resilientthan φj with respect to the contraction of φi from Sm if it is not amaximally vulnerable element of some minimal L′(Sm) ⊂ L(Sm) implyingφi .


Inferential-based approach

Definition (System Resilience)Consider a software system Sm, with a property specification formulated byφi . Then Sm is said to be resilient with respect to the function expressedby φi if the latter is not a maximally vulnerable element of the set ofspecifications required to consider Sm minimally well-functioning.


Conclusions

Future research: consider the update operation, which explicitlyformulates changes in the environment ad hence qualifies as adaptivechange;

Questions and comments welcome!


References I

Alchourrón, Carlos E., Gärdenfors, P. Makinson, David (1985). On thelogic of theory change: Partial Meet Contracgtion and RevisionFunctions, Journal of Symbolic Logic, vol. 50, pp. 510-530.

Alchourrón, Carlos E., Makinson, David (1985). On the logic of theorychange: Safe contraction, Studia Logica, vol. 44, n.4, pp. 405-422.

Alchourrón, Carlos E., Makinson, David (1986). Maps between somedifferent kinds of contraction function: The finite case, Studia Logica,vol. 45, n.2, pp. 187-198.

Angius, N. (2014). The Problem of Justification of EmpiricalHypotheses in Software Testing, Philosophy & Technology, September2014, Volume 27, Issue 3, pp 423-439.


References II

Angius, N., Tamburrini, G. (2011). Scientific Theories ofComputational Systems in Model Checking, Minds and Machines, May2011, Volume 21, Issue 2, pp 323-336.

Barn, B., Barn, R., Primiero, G. (forthcoming). Value-sensitiveCo-Design for resilient Information Systems. Proceedings ofIACAP2014, Conference of the International Association of Computingand Philosophy, Synthese Library Series, Springer.

Bloem, R., Chatterjee, K., Greimel, K., Henzinger, T.A., Jobstmann,B. (2010). Robustness in the presence of Liveness, in Touili, Cook,Jackson (eds.), Computer Aided Verification, Lecture Notes inComputer Science, vol. 6174, pp.410-424.

Bloem, R., Greimel, K., Henzinger, T.A., Jobstmann, B. (2010).Synthesizing Robust Systems, Acta Informatica vol. 51, issue 3-4, pp.193-220.


References III

Buckley, J., Mens, T., Zenger, M., Rashid, A., Kniesel, G. (2005).Towards a taxonomy of software change, Journal of SoftwareMaintenance and Evolution: Research and Practice, Volume 17, Issue5, pages 309–332.

Dam H.K, and Ghose, A. (2014). Towards rational and minimal changepropagation in model evolution, CoRR, abs/1402.6046, 2014,http://arxiv.org/abs/1402.6046.

De Florio, V. (2013). On the Constituent Attributes of Software andOrganisational Resilience. Interdisciplinary Science Reviews, vol. 38,no. 2, Maney Publishing.

Eick, S.G., Graves, T.L., Karr, A.F., Marron, J.S., Mockus, A. (2001),Does code decay? assessing the evidence from change managementdata, IEEE Transactions on Software Engineering, 27(1), pp. 1-12,2001.


http://arxiv.org/abs/1402.6046

References IV

Ernst, N.A., Mylopoulos, J., Wang, Y. (2009), Requirements Evolutionand What (Research) to Do about It, in K. Lyytinen et al. (eds.)Design requirements Workshop, LNBIP 14, pp. 186-214, 2009.

Floridi, L., Fresco, N., Primiero, G. (2014). On MalfunctioningSoftware, Synthese, doi: 10.1007/s11229-014-0610-3.

Harman, M. and McMinn, P. and Shahbaz, M. and Yoo, S. (2013). AComprehensive Survey of Trends in Oracles for Software Testing,University of Sheffield, Department of Computer Science,CS-13-01,http://philmcminn.staff.shef.ac.uk/publications/pdfs/2013-techreport.pdf.


http://philmcminn.staff.shef.ac.uk/publications/pdfs/2013-techreport.pdf

http://philmcminn.staff.shef.ac.uk/publications/pdfs/2013-techreport.pdf

References V

Le, QuangLoc and Sharma, Asankhaya and Craciun, Florin and Chin,Wei-Ngan (2013). Towards Complete Specifications with an ErrorCalculus, in Brat, Guillaume and Rungta, Neha and Venet, Arnaud(eds.), NASA Formal Methods, Lecture Notes in Computer Science,vol. 7871, pp.291-306,http://dx.doi.org/10.1007/978-3-642-38088-4_20.

Lehman, M. (1980). Programs, life cycles, and laws of softwareevolution, Proceedings of the IEEE, 68(9), pp.101-103.

Lehman, M. M.; J. F. Ramil; P. D. Wernick; D. E. Perry; W. M. Turski(1997). Metrics and Laws of Software Evolution - The Nineties View,Proc. 4th International Software Metrics Symposium (METRICS ’97).pp. 20?32. doi:10.1109/METRIC.1997.63715

Lientz, B., Swanson B., Software maintenance management,Addison-Wesley, 1980.


http://dx.doi.org/10.1007/978-3-642-38088-4_20

References VI

Lindvall, M., Tesoriero, R., Costa, P. (2002). Avoiding architecturaldegeneration: an evaluation process for software architecture,Proceedings of the 8th IEEE Symposium on Software Metrics, pp.77-86, 2002.

Mens, T., Wermelinger, M., Ducasse, S., Demeyer, S., Hirschfeld, R.,Jazayeri, M., (2005). Challenges in Software Evolution, Proceedings ofthe 2005 Eigth International Workshop on Principles of SoftwareEvolution, 2005.

Moor, James H. (1978). Three Myths of Computer Science, BritishJournal for the Philosophy of Science, 29(3) (September): 213-222.

Peled, D. (1997). Verification for robust specification, in Gunter, E.and Felty, A. (eds.), Theorem Proving in Higher Order Logics, LectureNotes in Computer Science, vol. 1275, pp. 231-241,http://dx.doi.org/10.1007/BFb0028397.


http://dx.doi.org/10.1007/BFb0028397

References VII

Port, D., Liguo, H. (2003). Strategic architectural flexibility,Proceedings of the International Conference on SOftware Maintenance,pp. 389-396, 2003.

William J. Rapaport (2004). Philosophy of Computer Science,University at Buffalo, The State University of New York, Draft,November 14, 2014.

Sommerville, I. (2004). Software Engineering, 7th ed., Addison-Wesley,2004.

Turner, R. (2011). Specification. Minds and Machines, 21(2), 135?152.

Williams, B.J., Carver, J.C. (2010). Characterizing softwarearchitecture changes: A systematic review, Information and SoftwareTechnology, vol. 52, pp.31-51.


References VIII

Zowghi, D., Ghose, A., Peppas, P. (1996). A framework for reasoningabout requirements evolution, in PRICAI’96: Topics in ArtificialIntelligence, Lecture Notes in Computer Science, vol. 1114, pp.157-168.


Documents

Software Theory Change · Previousworks formaloperationsofAGMbeliefchange,see [Alchourrón,Gärdenfors,Makinson(1985)] [Zowghietal. (1996)]requirementsevolutionintermsofbelief