Scientific rigour, an answer to a pragmatic question: a linguistic framework for software engineering’

AM Haeberer Department of Informatics

Faculty of Sciences, University of Lisbon Campo Grande, 1700 Lisboa

Portugal armando@ haeberer.com

Abstract Discussions of the role of mathematics in software engi- neering are common and have probably not changed much over the last few decades. There is now much dis- cussion about the “intuitive” nature of software con- struction and analogies are drawn (falsely) with graphic design, (conventional) architecture, etc. The conclusion is that mathematics is an unnecessary lux- ury and that, like these other disciplines, it is not needed in everyday practice. We attempt to refute these arguments by recourse to ideas from the Philosophy of Science developed over the past century. We demon- strate why these ideas are applicable, why they estab- lish a framework (in the sense of Carnap) in which many central ideas in software engineering can be for- malised and organised, why they refute the simplistic recourse to “intuition”, and why they provide a scien- t8clengineering pamework in which contributions to the theory and practice of software engineering can be judged.

Keywords: Design methods; Environments: organi- sation and integration principles; Formal methods; Measurement, metrics, and empirical methods; Require- ments engineering; Software process; Systems design; Testing, analysis, and verification; Design Theory; Engineering; Epistemology; Frameworks

1. Introduction

Two strands of discussion motivate this paper. The first of these concerns discussions about the nature of software engineering (SE) encountered recently at the highest levels of academic computer science. The second is a long term discussion between the authors on the epistemological nature of SE and the basis on which

Nihil habemus in nostra scientia nissi nostra mathematica Nicholas of Cusa (1401 - 14H)

TSE Maibaum Department of Computer Science

King’s College London Strand, London WC2R 2 LS, UK

tom @ maibaum .org

we should judge our work and that of others with respect to its contribution to the advancement of knowledge and practice in the subject.

The former set of discussions took place recently in two contexts. The first of these was a discussion on the role of mathematics in the curriculum of SE at the second author’s institution, so as to include in our course the best available ideas on SE for students who intend to become chartered engineers. The second discussion took place in a very nice hotel on the Italian Riviera during a workshop entitled “Modelling Software System Structures in a fastly moving scenario”.

The discussion about the role of mathematics in the SE curriculum rehearses many discussions of the same nature and the participants will forgive us if we carica- ture their contributions! Although a good dose of maths is supposed to be good for the soul (pardon the mixed metaphor!), it is not seen as being all that good for “real” programming. Programming is said to be akin to graphic design or conventional architecture. It was claimed that neither subject required mathematical knowledge and that the creative, intuitive elements were the right analogy with programming. (The fact that the basic assumption underlying the claim is actually false is pretty obvious to us. An architect cannot function without sophisticated knowledge of the analysis methods required to make sure that a projected building will actually stand up, and have the other necessary properties. The architect does not simply leave these calculations to the structural engineers, as the only recourse would then be to the equivalent of the old defi- nition of AI programming: you start with the empty building and debug until it works! Similarly, the graphic designer has a more sophisticated knowledge of prac- tical Euclidean (and sometimes non-Euclidean) geom- etry than the average person on the street does.)

1. The work reported here was supported by EPSRC, CNPq, DAAD, and the FundaqHo Para a Ciincia e aTecnologia whilst the first author was on leave at Imperial College, the Ludwig-Maximilians-Universitat Miinchen, and the University of Lisbon.

463 0-7695-1050-7/01 $10.00 0 2001 IEEE

Our response was the following: “Would you rather fly in an aeroplane designed by a graphic designer or an engi- neer?” Our expectations for the answer should be obvious! It seems to us that the real problem here was not the fact that mathematics is necessary, as the simple analysis of our “artistic” endeavours illustrates, but that people associate mathematics with that of theoretical computer science, rather than some appropriate “engineering maths”. Further, they underestimate the importance of the role of systematic method in engineering. There will be further discussion of this point below.

(There are numerous examples of the limits of “artistic design”, amongst which we find the following well known case of Howard Hughes’s Spruce Goose. He was, amongst many other things, an amateur airplane designer, famous for designing by “intuition”. For instance, on September 12, 1935, in an airplane of his own design, he established the world‘s landplane speed record of 352.46 miles per hour. However, from 1942 he worked on the design of an eight- engine, wooden flying boat intended to carry 750 passen- gers, the Spruce Goose. After many criticisms and comments about the inability of the plane to fly, Hughes piloted this machine on November 2,1947 on its only flight, which spanned just one mile at a height of a few meters over the sea and took only 70 seconds .)

The discussions at the workshop contained a number of annoying elements, most of which need not detain us. (Perhaps the most annoying point being made by some participants was how wonderful the state of SE was! We had learned so much and so many systems were working so well, in spite of not having recourse to mathematically based techniques. There was reference to Tony Hoare’s invited talk at ICSE 18 in Berlin: “How did software get so reliable without proof?” [16]. The systems we are aware of certainly do not have the properties of dependably engi- neered artefacts, fit for purpose, delivered on time and within projected costs! (All of these properties of almost all engineered artefacts.)) The discussion came to the same conclusion: mathematically based techniques were not required and, perhaps even more strongly, not appropriate for most software engineers involved in building most systems. There was a role for mathematics in a small portion of a small number of systems that are critical, because we have no other method of describing and analysing such crucial system components. Building systems was again really an artistic, intuitive activity! (The week before, the authors were delayed for 2 hours returning form Limerick (ICSE 2000) to London, due to a failure earlier in the day of the air traffic control system at Heathrow, which caused air travel confusion across Europe for almost a. day. This was repeated a week later.)

We believe that there is a fundamental confusion here between the scientifically and mathematically based prac-

tice of engineers and the day to day use of said mathe- matics* in the engineering praxis. This confusion results in discussions about “formal” versus “rigorous”, as if the dichotomy being explored was that between science/mathe- matics, on the one hand, and engineering, on the other. Only good mathematicians and scientists are capable of doing rigorous mathematics. Students and less skilled math- ematicians and scientists are capable of using only the formal, formulaic versions. Engineers use quite different scientific principles and mathematical techniques in their daily work [24]. It is with respect to these daily uses of mathematics and science that engineers develop “intui- tions”.

As a response to the Riviera discussion, we formulated a number of ad hoc principles that we would like to put forward and discuss. We will do this in the context of some ideas from epistemology that we believe can provide a framework for discussions of the nature of (Software) Engi- neering and for forming critical judgements of contributions to research and practice in the subject.

The principles are: Intuition is a necessary but not sufficient basis for engineering design. Intuitions are very difficult to use in complex situa- tions without well-founded abstractions or mental models. (The term “mental model” is used here as a synonym of a (somewhat vague) abstraction of a framework in the Carnapian sense; see below.) An engineer has our permission to act on intuition only wHen: Intuitions can be turned into mathematics and science, and Intuitions are used in the context of “normal design” processes (see below). The abstractions, mental models, cognitive maps, ontologies used by engineers are not the same as those used by mathematicians and scientists.

We will proceed as follows in the remainder of the paper. In section 2 we will introduce very briefly some ideas about the so-called Statement View of scientific theories. In section 3 we discuss some ideas about the nature of engi- neering.

2. The Statement View

The Statement View of Scientific Theories, (The State- ment View) was developed by Carnap in the 38 years between 1928 and 1966. The version we use is based on Camap’s presentation in [2], influenced by the criticisms and by the developments addressed by other logical empir- icists, such as Nagel [19] and Mary Hesse [14]. Moreover,

2. By “mathematics” for the purposes of software engineers we include discrete mathematics, logic and metamathematics.

464

given that we address the Computer Science and Software Engineering communities, we have also modified the nota- tion.

The primary motivation for the Statement View is to explain the language (and practice) of science. In particular, Carnap focused on Physics, but intended his ideas to cover all “scientific” activity, He was interested in so-called scientific theories which had “empirical content”, i.e., had an empirical interpretation. He wanted to characterise in an exact manner the meaning of words like “theory”, “empir- ical”, “interpreted”, etc.

In the context of the Statement View, whenever we have an empirically interpreted theory3 ST, ,relating some scien- tific theory to observable phenomena, we have two disjoint subtheories of it:

a theoretical one, not interpreted in terms of observable entities, whose presentation is ST, = (Z, , A X , ) , and a pure1 observational one, whose presentation is

related by a set of correspondence rules, denoted by CST = (XF, AX:) which connect the two subtheories.

We call ZF , Z F , and ZF the (extralogical) language4 of ST,, STo and C S T , respectively. We call A x p , Ax: and Ax: the axioms of ST,, STo and C S T , respectively. Actually, because CST provides a bridge from the theoret- ical level of discourse to the observational level, its language is contained in the union of Zy and Z F ?

We will refer to the languages (expressionshentences) generated by these various languages collections of extra- logical symbols) as L F , L r and L c , respectively. The corresponding extralogical languages, logical symbols/ connectives and variables are used to form the expressions in these lan ua es. Observable facts are stated in the language L o , which supports limited forms of expression and reasoning. Normally, we would expect statements in this language to be ground atomic formulae (observations) and some formulae built in terms of these. Perhaps the most limiting factor to take note of is that the domain of quanti- fiers is normally finite, constituting, at best, empirical generalisations, but not universal laws, which might require quantifiers with infinite domains. The language of the theo- retical level is a more powerful logic that somehow incor- 3. We use theory here in the sense of logic. That is, we have a logic in terms of which we describe something via putative properties. We distin- guish a theory,per se, which is deductively complete (meaning that every- thing which follows from the properties via the logic is already in the theory) from (theory) presenrations, which axiomatically state the key properties on which we depend, and from which the whole theory can be deduced using the logic. 4. The extralogical language provides us with the terminology (ontology) to use in the theory to represent in the language of the logic concepts and relationships that are of interest. 5. There are a number of formal restrictions to be made concerning the nature of these languages and theories, but they need not detain us here. The inkrested reader is referred to [2].

ST ST

d ST STo = G o t Ax0 1 ,

&

S P

porates the logic of observables. The language of the correspondence rules is over the logic of the theoretical level, but with perhaps a limitation on the set of extralogical symbols allowed.

The set C,, of correspondence rules provides the only empirical interpretation of ST, in the sense that the intended meaning of some theoretical symbols is fixed by these rules (by restricting the possible models of the theoret- ical symbols), which define some theoretical symbol in terms of corresponding observational terminology. The theoretical symbols whose meaning is not definitionally given by CST are not fixed by means of these rules, i.e., their interpretations in structures are not constrained by the correspondence rules. Their properties are given by relating them to the already interpreted theoretical symbols by means of the inferential mechanisms of the logic underlying L F 6 . Hence, there are “more” theoretical s mbols than observational ones. Therefore, L , outstrips Lo in expres- sive power (in two ways).

Hempel [ 121 has drawn a memorable picture of the struc- ture of a theory: A scientific theory might therefore be likened to a complex spatial network: Its terms are repre- sented by the knots, while the threads connecting the latter correspond, in part, to the definitions and, in part, to the fundamental and derivative hypotheses included in the theory. The whole systemgoats, as it were, above the plane of observation and is anchored to it by rules of interpreta- tion. These might be viewed as strings, which are not part of the network. but link certain parts of the latter with specijic places in the plane of observation. By virtue of those interpretive connections, the network can function as a scientific theory: From certain observational data, we may ascend, via an interpretive string, to some point in the theoretical network, thence proceed, via definitions and hypotheses, to other points, from which another interpretive string permits a descent to the plane of observation.

According to Carnap’s metaphilosophy, when we state some theory (or set of theories) to explain a set of Observa- tions stated in the observational language L F , therefore constructing an instance of the Statement View, we are putting in place aframework by making some ontological commitments about the range of the existential quantifiers of the theories of the framework, those of L being chosen directly whilst those of L p through the set CST , etc. The very choice of LF commits us to an ontological system. Once a framework is thus established, we automatically divide our questions into two disjoint subsets, the so-called intemal questions and the so-called external questions. The former are questions stated and answered within the frame- work: is it true that Ekmc2? Can we refute by using, for 6. What this logic p i s not important for our present discussion, so we will not dwell on it. Camap initially used First Order Logic and then Modal logic. It may be that a combined Temporal and Modal Action Logic might be more appropriate.

ST X

465

instance, diagonalisation that the set of the general recursive functions is exactly the set of the effectively computable ones? What is the mass of an electron? Is the Earth spher- ical? Internal questions have answers that are true or false,

. yes or no, because a truth is either logical or relies on certain ontological systems, and ontological systems are internal to frameworks. External questions are questions of pragmatic significance, devoid of any cognitive content, for instance: is this framework appropriate for explaining physical phenomena where v<<c? or, is the classical theory of general recursive functions appropriate to deal with every aspect of digital computers?

Notice that the often declared statement “Church’s thesis is a circularity, so why should it limit computability?” does not make sense in this meta-philosophical setting. Church’s thesis is a fundamental assertion about a particular frame- work. If Church’s thesis tums out to be inappropriate, then the framework must be replaced by replacing Church’s thesis by a different fundamental statement. Once we do this, then we must analyse the internal logical consistency of such a framework. So, the appropriateness of the classical computability framework is an external question, its consistency is an intemal one. Notice that the answers to extemal questions are not as easy as they appear at first glance; we can say, for instance: “biological computers will not satisfy Church’s thesis” in the sense that biological computers will compute functions not belonging to the set of the general recursive ones. OK, it is easy to say this - the difficulty is that external questions like this one are tightly related to intemal ones; once we state that biological computers do not satisfy Church’s thesis, we need to construct a new framework containing a new set of comput- able functions. Moreover, this framework must be inter- nally consistent. How easily can this be done?

As an illustration of the power of these ideas, as applied to Software Engineering, we can look at specification based testing and quickly see how this framework illuminates our discussions of testing. We will see that there is a direct route from Newton via Dijkstra to the programme put forward by Gaudel and her collaborators [7,8]. We will briefly examine why these ideas are misguided (based as they are on intui- tion about the nature of testing) and how they may be refor- mulated to take account of scientific principles.

When testing theoretical statements against evidence, we face two problems. The first of these problems is what rela- tions between observational statements (results of tests), on the one hand, and theoretical statements (specifications), on the other hand, permit statements of the former kind to refute (or not) statements of the latter kind. (we will refer to it as the confirmation problem.) The second problem has already been described above: notice that there are no constraints on the logic underlying the theoretical level, whilst the quantifiers underlying the observational level are

constrained to be of finite domain. So, in the case of the universal quantifier, we have simply generalised, finite conjunction. The problem of how to “lift” from the confir- mation of an hypothesis by a single experiment (or a finite set of them), its confirmation for all (possibly infinite) cases, is a. problem of induction [3, 15, 4, 31. Scientists normally rely on the regularity of natural phenomena for performing such inductive steps. In Gaudel’s proposed approach, this issue is addressed by the so-called uniformity hypotheses. We will not be concerned in this paper about the problem of induction. We focus on the problem of confir- mation.

During the development of Science and Philosophy of Science, at least four confirmation strategies have been proposed, namely elimination of theory, the hypothetico- deductive method, the bootstrap method and probabilistic strategies [9]. We will only look at the middle two to illus- trate our ideas.

The hypothetico-deductive (HD) method can be traced to Newton. Dijkstra’s famous dictum about testing is simply a latter day restatement of it. And as stated in the dictum, we are using confirmation in the sense of “the experiment did not refute this hypothesis made on the basis of that theory” and not in the sense of “the experiment entails that the hypothesis is true on the basis of that theory”. We start with a scientific (empirically interpreted) theory S T , , given by means of a presentation ST = (F, AP) (a fomial specifi- cation, for instance), a hypothesis H stated in the theoretical language LY, which we want to test wrt the background theory S T , , and evidence E* stated in the observation language L, .

The question is, in Clark Glymour’s words [9]: [.....I how can evidence stated in one language confrtn hypoth- eses stated in a language that outstrips the first? The hypotheses of the broader language cannot be confirmed by their instances, for the evidence, ifframed in the narrower tongue, provides none. Consistency with the evidence is insuficient, for an infinity of incompatible hypotheses may obviously be consistent with the evidence, and the same is true if it is required that the hypotheses logically entail the evidence.

In the HD strategy, first the hypothesis H in question and the background theory ST, are used to derive a prediction in terms of (expected) evidence E * , and then it must be determined whether a prediction holds or not The hypoth- esis H is stated partly in the theoretical language and partly in the observational one. The background theory ST, is an interpreted theory containing its theoretical part, its obser- vational part, and the correspondence rules (used to lift observational statements, such as the evidence, to the theo- retical level). Finally, the evidence must obviously be stated in the observational language?

An HD schema is a triple (ST,, H, E*) where S T , ,Hand

ST

466

E* are as in our scenario above and the following three conditions hold: 1) ST, and H are mutually consistent; 2) ST,, Hi- E* ; and 3 ) S T , F E * .

The reason for condition 1) is obvious: a hypothesis inconsistent with the theory cannot be confirmed or discon- firmed on this basis. Condition 2) states the heart of the strategy, namely that the theory ST, together with the hypothesis H must entail the evidence E * . This is the prediction! Condition 3) prohibits the confirmation (or disconfirmation) by means of E* of any irrelevant H on the basis of a theory S T , .

The outstanding problems of the HD strategy are that: 1) E* can never confirm any consequence of ST, ; 2) if H is confirmed by E* wrt S T , , then so is H A cp ,

where cp is any sentence whatsoever that is consistent with H A ST, ; and

3) if E* is true and not valid and cp is any consistent sen- tence such that E* 1L cp , then cp is confirmed by E* wrt a true theory (namely cp -+ E* ).

The first of these difficulties might be acceptable, but together with the other two they make the HD account untenable. Glymour [GlySOb] has demonstrated that any attempt to save the HD strategy by adding additional constraints only leads to other disasters.

Here, we will just very briefly outline Gaudel’s approach and its problems. The aim of the approach is to do verifica- tion testing of a program with respect to its (equational) specification. What does is to try to test if each of the axioms of the specification presentation holds in the program. So, she uses the HD method in a very rough way, i.e., she does not need to derive an observational conse- quence (some theorem of the theory), because she uses the axioms of its presentation directly. She determines if the axiom holds in the program simply by determining if the program correctly implements it. She uses a version of the Bidoit-Hennicker observation logic [25] to ‘‘look’’ into the program’s hidden parts. What Gaudel does not notice is that a program must behave as its specification commands, but it need not implement such a specification exactly. Furthet, by analysing the program in the way she does, she intro- duces a new infinite dimension in the testing. (This is due to nuances of the observation logic.) As we have shown [6] , Gaudel’s approach rejects correct programs, something that the initial declaration of aims of her approach specifically establishes should not be the case. The worst problem with Gaudel’s approach is that its problems cannot be fixed, since, as we said, she uses a rough version of the hypo- thetico-deductive method and Glymour has formally ruled 7. Popper’s related falsifinbility principle uses the HD method by proposing a negative account of discovery that eliminates induction. There is an “illumination” step and then an HD step for validating the illumina- tion. This is why the falsifiability principle resembles the HD strategy.

it out as hopeless [lo]. The alternative proposed by Glymour, bootstrap testing,

based on an idea of Carnap, can be shown to be sound with respect to the purposes of validation and verification testing in SE. We do not discuss the details here and refer the inter- ested reader to [ll, 9,5]. We will go on, instead, to discuss the use of this epistemological framework for SE.

3. Towards an Epistemological Basis for (Soft- ware) Engineering

As Carnap (and others) have pointed out, an ontological framework, i.e., a framework within which the range of our existential quantifiers is empirically interpreted and in which, therefore, explanations are issued, cannot be said to be correct or incorrect, it can only be of some utility, or not (see, for instance, [20]. Hence, in discussing a framework for SE, we are left with the task of convincing our colleagues that the proposed framework will be of some utility. We have already presented some evidence for this via the discussion of the testing problem above. We propose to provide further supporting evidence by outlining some details of the SE framework we propose in terms of Figure 1 and, demonstrating that we can give the diagram a seman- tics. That is, all the objects and relationships and processes denoted by the diagram could be given exact, mathematical/ scientific definitions. (We say “could” because some of the relationships are presently the subject of research!) Nor do we claim that this is the only framework of utility for SE. (We only induce the reader to think about it as being the last word in SE frameworks by means of the background omega letter!) There may be others, more or less detailed, that are of equal or greater utility.

Actually, to assert that something is of utility, we must have in mind some task for which it is to be of utility. In our case, we are interested in making SE a proper engineering discipline [18]. According to [24], the day to day activities of engineers consist of normal design, as comprising “the improvement of the accepted tradition or its application under ‘new or more stringent conditions”’8 He goes on to say: “The engineer engaged in such design knows at the outset how the device in question works, what are its customary features, and that, if properly designed along such lines, it has a good likelihood of accomplishing the desired task.” Jackson [17] sings the praises of this concept of “normal design”, although he does not use this phrase himself: “An engineering handbook is not a compendium of fundamental principles; but it does contain a corpus of rules and procedures by which it has been found that these prin- ciples can be most easily and effectively applied to the particular design tasks established in the field. The outline

8. We are familiar with this idea from school and know them as cookbook methods.

467

design is already given, determined by the established needs are 10 triangles. We will call a triangle logical if it contains and products.” And again: “The methods of value are only logical relations, and we will call it factual if it micro-methods, closely tailored to the tasks of developing contains at least one factual relation. In Figure 2, triangles particular well-understood parts of particular well-under- I, 11,111, VI, VII, and VIII are factual, whilst N, V, K, and stood products.” X are logical. This

means that in 6 trian- engineering design is gles out of 10, we that engineers require recourse to normally design experiments and devices as opposed to systematic observation systems. A device (in for sustaining our belief this sense) is an entity about the truth of our whose design princi- conclusions. This anal- ples are well defined, ysis demonstrates well structured and effectively why it is subject to normal worthwhile analysing design principles. A the software process system (in this sense) and SE in the context of is an entity that lacks ”” some epistemological some important char- setting and not simply acteristics making in the light of a purely normal design logical one. In Tables possible (and necessi- 2-5 we will look at two tating radical design). cases (one factual and Systems become one logical) in detail, to devices when their illustrate the explana- design attains the tory power of the ideas. status of being Each case is presented normal, i.e., the level by means of two tables: of creativity required one analyses the ways in their design in which the relation-

ships may be violated, Of Figure 1. Epistemological framework for software development whilst the other anal- becomes one

systematic choice, based on well defined analysis, in the context of standard yses each case in terms of the framework and the relation- definitions and criteria developed and agreed by the rele- ships involved. We proceed to give some basic SE vant engineers. Further, whatever the status of the State- definitions on the basis of the above diagram. ment View is with respect to science (and there are Correctness is a relation between two constructed arte- controversies!), we believe that we can apply related ideas facts asserting that the properties required by one are to a normative theory (and practice!) of (SW) engineering. preserved in the other. Preservation of properties may be Scientists may or may not follow the rules as rationalised by mediated by translation (between ontologies). Also, preser- epistemologists. Engineers, by their very nature, must vation does not exclude the inclusion of new (consistent) follow predefined methods and standards so as to earn and properties. retain the right to be called engineers! Validation is the activity of determining, by means of

We say that a relation is logical if it can be, in principle, experiments (i.e., testing), whether or not we are formally corroborated; we say that a relation is factual, if it constructing the analogy we consider appropriate. (We cannot be in principle formally corroborated, and therefore, realise that the word appropriate is inappropriate! We need its truth is inherently contingent. Despite its logical char- to define what this means and we do not have the space to acter, the truth of a logical relation is often checked by veri- do it in this paper.) fication testing, in which case the character of this truth Positive analogy is a relation between two entities (even becomes contingent. The truth of an factual relation cannot frameworks) consisting of a map between the two be definitively established. We will analyse now the trian- underlying ontologies (an interpretation between languages gles embedded in Figure 1 , formed by sets of (obviously [23]), which correlates positive (in the sense of essential and three) adjacent relations. As we can see in Figure 2, there not in the sense of non-negative) properties of the source of

An implied view of

468

the mapping with the positive properties of the target. We call the source an iconic model of the target.

Testing is the application of tests. A test is an experiment

to determine if some entity may have (can be assumed to have) some ground property (in the sense of logic).

Table 1 :The relationships in Fig. 1

HSP + CTXP HSP + CIXP-&-EA + CTXA

Figure 2. - Relations and abstract sub-processes in the Software Process Cdrrectness may be achieved in a number of ways.

Correctness by construction is often recommended because it is more efficient and easier from the point of view of the engineer than post facto verification. “Correct by construc- tion’’ is clearly related to normal design. It is a cookbook method for the construction of some entity, with the steps in the construction being highly systematised and pre-verified. Correctness by verification is a formal proof of correctness that is ad hoc, i.e., not an explanation. To understand why this is the case, we need to understand the concept of expla- nation. See [Hem481 for a full discussion.

An explanation is a formal demonstration (in the frame- work of the Statement View) with the form:

antecedent conditions erplanans statements of i ST, interpreted theories

E 3 erplananhm

The constituents must satisfy the following logical (the first 3) and empirical (the 4th) conditions of adequacy: the explanandum must be a logical consequence of the explanans; the explanans must contain general laws, and these must actually be required for the derivation of the explanandum; the explanans must have empirical content, i.e., it must be subject, at least in principle, to testing by experiment or observation; the sentences constituting the explanans must be true.

In relation to intuition, we have the following from [Hem48]: Many explanations which are customarily offered, especially in pre-scientific discourse, lack this predictive character, however. Thus, it may be explained that a car turned over on the road ”because” one of its tires blew out ... Clearly, on the basis ofjustthis information, the accident could not have been predicted, for the explanans 9. [Hem48]: “Let us note here that the same formal analysis, including the four necessary conditions, applies to scientific prediction as well as to explanation. The difference between the two is of a pragmatic character.”

469

Triangle I Character: factual

- Case H P S + C E Y P - R S P E A + C T X A - R S P HPS+CTXPdEA+CTXA ~

1.1 Yes Yes Y e s I .2 ves ves no

c& 1.1

1.2

1.3

1.4

1.5

1.6

Yes Y S Yes

1.7 no no Y e s 1.8 no no no

~ Analysis

This is our goal, both epistemologically and pragmatically. The pragmatic goal is simply HPS + C l x P 6 EA + C7XA; and in this case we have succeeded in achieving it by constructing an appropriate RSP, i.e., HPS + C7XP 0 RSP, and we have constructed from it a correct EA, which, together with its ct"t,explains RSP, i.e., EA + C7XA RSP. However, we should take into account the fact that 6 and 6 are factual relations and, therefore, their truth is contingent, ic., could be refuted by a negative experimental result. We may say the same about - if its truth is checked by verification testing and not by formal proof.

This is an odd case. At fust glance it is impossible, since we have an appropriate RSP, i.e., HPS+ C W Q RSP, and we have constructed fromitacorrectEA,i.e,EA +cTxA RSP. However,wehavenotachieved ourpragmaticgoal,i.e.,HPS+CTXP 6EA+cTxA. Neva- theless, before dismissing this case, we should take into account that HPS + C7XP Q RSP is an factual relation. Therefore, it is only confirmable in principle, since the only way of checking it is validation testing. Then we may have not yet refuted this relation ,even when there are cases (not yet analysed) that would refute it. Another possibility is that EA + CmA RSP has been corroborated by verification testing instead of by formal proof, when we have the same constraints as in establishing the truth of HPS + CTXP 0 RSP.

Again, this case seems to be impossible, but for the factual character of e a n d b , and for the way * has been verified.

Provided we accept the truth of HPS + CTXP 6 RSP (even when contingent), this is the common case in which EA is wrongly conshucted.

Once more, apart for the contingent character of the truth of the relations involved, this case is impossible.

This case appears very often ,over and above the contingent character of the truths involved. It is the typical case in which EA was correctly constructed from RSP, but, unfortunately the latter is not an appropriate requirements specification for HPS + CTXP.

Table 2: Analysing a factual triangle

I Not considering the contingent character of the truths involved, this is the amusing and often occuring case of deriving an appropriate EA I I from a requirements specification which is wrong!

I 1.8 I In this case everything is wrong. We would like to say that it is impossible, but ... I Table 3: Analysing a factual triangle

Table 4: Analysing a logical triangle provides no explicit general laws by means of which the prediction might be eflected, nor does it state adequately the antecedent conditions which would be needed for the prediction. C7XA{EA}, or simply {EA}.

{Si},,,and the theories {STi}I,,., must be combined in a particular way to produce an explanation, be it some form of valid reasoning, be it some kind of logico-mathematical structure: SO. we will write our scheme of exohation as

explanation. On the other hand, let us analyse the engineering artefact

and its context EA + CTXA. Let us denote this expression by

We would accept that the antecedent conditions The engineering artefact is usually a composite system C: CTXA{EA) = c&(EA:, ..., EA:) Here, Z denotes the struc- ture" of the composition, which from {EA,, ..., EA,} yields CTXA{EA}. In software engineering, g...) denotes 10. Here, we use the symbol X for denoting composition due to the Greek

z z

470

Case

11.1

11.2

I I13 I Impossible. I

Analysis

This is our goal, both logically and pragmatically.

Impossible.

I The refinement step from SP, to SP,, was‘incorrectly done, but, nevertheless, we constructed a correct software artifact, with r&&ct toboth I IIA I SP, and SP,,. (For instance, it could be the case that SP, LSP, , . )

11.5

11.6

Impossible.

This is the typical case in which either the first design specification is wrong, and, despite the refinement being correct, the software artifact is obviously incorrect with respect to the last design specification; or both design specifications are “correct”, and the softwaer artifact is incorrect.

I 11.7 I Impossible. I 11.8 In this case everything is wrong. We would like to say that it is impossible, but ...

An engineering artefact (in the context of a given feme- work produced by an instance of the Statement View, where ST is the set of the theories underlying our engineering and therefore, pertinent to our explanation) is an entity denoted by a symbol of the observational language which is the result of a constructive (engineering) activity. It must be connected with symbols in the theoretical language (obvi- ously via correspondence rules). These symbols in the theo- retical language are part of an extension of ST by means of symbols, which need a manufacturing process to have empirical interpretation.“

RSP can be seen as the predicted behaviour of an object (the engineering artefact to be) which will be constructed and for which there is a symbol in an extension of the (language of the) pertinent theories of the science under- lying our engineering together with an appropriate corre- spondence rule. Now, let us assume that an explanation for RSP has the form E.

Notice that the process we have in mind for devising a new engineering artefact is as follows. We have a require- ment for a new artefact RSP. Therefore, we construct an extension of our underlying theoretical language (belonging to our underlying science and to the already existing engi- neering discipline) with the necessary symbols, etc., to enable us to show that what RSP describes (at this point only an hypothetical posit HPS and its context) is scientifically possible and that (if the status of our current technology makes its construction viable) the resulting engineering artefact EA will be in a positive analogy with HPS, i.e., HPS 6 EA. Then, we construct EA, through a process of design and reification, which adds detail to the above extension. Thus, at the end we have an artefact EA, but we have also constructed an explanation E, because if we have constructed EA and C, then we have also extended the theo- retical language with symbols relating each one of the components of EA via a correspondence rule, and, more- l l . This is called design, construction and deployment!

over, we have also defined a new correspondence rule c(E,Z). Therefore, because we have correspondence rules and corresponding theoretical symbols for each one of the components, and we have for each composition.& a theoret- ical construction E, we can say that EA+CTXA=RSP, because 2, c and there exist a set of appropriate correspond- ence rules, including specifically c(RSP,EA). Thus, * is based on explanation, EA+CTXAIRSP means that the construction of the explanation of RSP was driven by the particular constructive process for EA, constructed from its parts and the explanations for its atoms (or the already accepted c s , for existing components with already existing corresponding theoretical symbols and correspondence rules). Thus, we will call a merotic Notice that often, we do not use explicitly the induced explanation E , and we just write EA+CTXA’RSP and say that EA explains RSP. Unfortunatelv. this use is misleading and leads to confusion amongst gullible amateurskraftsman who. forgetting that some process. such as the one outlined above. is underpinning engineering construction. talk about intuition. art. etc.

Traceability is often quoted as an important aspect of SE. Explanation is facilitated if we have traceability. Tracea- bility is an asymmetric and transitive binary relation between two artefacts in SW development pertaining to the ability to relate structural elements of one to those of the other so as to record how one design is derived from another.

Engineers like constructive approaches exactly because they are essential elements of normal design. But there is no proper trace from requirements to design because making the design is an initially completely creative activity, with unknown rules. Once a design history is ostensibly successful, i.e., it either supports an explanation or a quasi- explanation (see below), we can re-use it as a constructive method that is “forward looking” and provides elements of 12. From the Greek p&pog(meros) part, piece.

47 1

a trace. (Both explanation and quasi-explanation enable use of a constructive method in a normative design process.) So a normative design process results from exploratory activity providing elements of design which can be used together to form a largely constructive design process. However, because of the nature of requirements specifications, encap- sulating information about both the posited artefact and its context, there will never be complete traceability between requirements and high level design (and, therefore, any level of design). Hence, the explanatory chain from code to requirements is “broken” at this stage and a new element of explanation enters the picture here.

Science itself provides examples of the relationship illus- trated above between requirements and design. Pre-Newto- nian mechanics being explained by Newtonian mechanics is one such example: we might think of Kepler’s laws as the requirements and Newtonian mechanics being the design. The latter provides an explanation of the former. Another example of explanation in this sense is Boyle’s and Gay Lussac’s description of the properties of gases vs. the kinetic theory of gases.

There remains the relationship between the hypothetical posit and its context, on the one hand, and requirements, on the other. The former is not a formal entity, so the idea of traceability and explanation “go out the window”. However, we may be able to speak about quasi-traceability and quasi-explanation, to the extent that such a relationship can be said to be like a formal one. Note that the direction of traceability is from requirements to the hypothetical posit and its context. Hence, there is no traceability from the latter to code (or any element of design). Perhaps this is an explanation of why no amount of normative design can guarantee success! The very first step is the inverse of what might be the subject of normal design. Inverses are notori- ously non-constructive!

4. References

[I] Luis F. Andrade and Jose L Fiadeiro, Interconnecting Objects via Contracts. In R. France and B. Rumpe, eds, UML’99 - [2] Rudolf Camap, An Introduction to the Philosophy of Science (re-edited from Philosophical Foundations of Physics, Basic Books, 1966). Ed. Martin Gardner, Dover Publications, Inc. 1995. [3] Rudolf Camap, Continuum of Inductive Methods. Univ. of Chicago Press. 1952. [4] Rudolf Carnap, On Inductive Logic. Philosophy of Science,

[5] Maria V. Cengarle and Armando Haeberer, Towards an epis- temology-based methodology for verification and validation test- ing. See 1~ under M.V. Cengarle. 1999. [6] Cengarle, M V., Haeberer, A. M.. A formal approach to speci- fication-based black-box testing. Proceedings of the Workshop on Modelling Software System Structures in a fastly moving sce- nario. June 13-16, 2000. Santa Margherita Ligure, Italia.

Vol. 12.72-97.1945.

www .disi.unige.it/person/FerrandoE/MSSSworkshop. [7] Marie-Claude Gaudel, Testing can be formal, too. In P. D. Mosses, M. Nielsen, and M. I. Schartzbach, eds. Proc. of TAP- SOFT’95. LNCS 915. Springer-Verlag. 82-96,1995. [8] Marie-Claude Gaudel and P. R. James, Testing algebraic data types and processes: a unifying theory. Formal Aspects of Com- puting Science. 1999. To appear. [9] Clark Glymour, Theory and Evidence. Princeton Univ. Press. 1980. [ 101 Clark Glymour, Hypothetico-deductivism is Hopeless. Phi- losophy of Science. Vol. 47.322-325,1980. [ 111 Clark Glymour, On testing and evidence. In John Eannan ed. Testing Scienti$c Theories, Minnesota Studies in the Philosophy of Science, Vol. X. Univesity of Minnesota Press. 1983. [ 121 Carl G. Hempel, International Encyclopedia of Unified Sci- ence, Vol. 2 , No. 7: Fundamentals of Concept Formation in Empirical Science. University of Chicago Press. 23-38, 1952. [13] Armando M. Haeberer and Tom S . E. Maibaum, The very idea of software development environments: a conceptual archi- tecture for the arts environment. In B. Nuseibeh and D. Redmiles, eds. Proc. of 13th IEEE Int. Conf. on Automated Software Engi- neering (ASE-98), IEEE CS Press, 260-269.1998. [ 141 Mary Hesse. The Structure of Scientific Inference. University of Califomia Press. 1974. [ 151 Jako Hintikka, Towards a Theory of Inductive Generaliza- tion. In Y. Bar-Hillel, Proc. of the 1964 Congress for Logic, Meth- odology, and the Philosophy of Science. 274-288. Stanford University Press. 1962. [ 161 C A R Hoare, How did software get so reliable without proof? In M.-C.Gaude1 and J . Woodcock, eds. FME 96: Industrial Benefit and Advances in Formal Methods. Oxford University Computing Laboratory, 1-17.1996. Also given as an invited talk at ICSE’l8. [ 171 Michael Jackson, Formal Methods and Traditional Engineer- ing. Journal of Systems and Sofrware special issue on Formal Methods Technology Transfer. Vol. 40. 191-194. 1998. [18] Tom S.E. Maibaum, Mathematical Foundations of Software Engineering: a roadmap. In Eds. A. Finkelstein and J. Kramer, Future of Sofrware Engineering, ICSE 2000. IEEE C,.S. Press. 2000. [19] E. Nagel, The Structure of Science. Harcourt, Brace. 1961. [20] Bryan G. Norton, Linguistic Frameworks and Ontology: .4 Re-Examination of Camp’s Metaphilosophy. Mouton Publishers. 1977. [21] Karl R Popper, The Logic of Scientific Discovery. Hutchin- son, London 1968. [22] Wlad M. Turski, An Essay on Software Engineering at the Turn of Century. In Ed. Tom Maibaum, Proc.of Fundamental Approaches to Sofrware Engineering 2000, LNCS 1783, Springer. 2000. [23] Wlad M. Turski and Tom S.E. Maibaum, The Specification of Computer Programs. Addison-Wesley, 1987. [24] Walter G. Vincenti, What Engineers Know and How They Know It : Analytical Studies from Aeronautical History. Johns Hopkins U. Press. 1993. [25] Michel Bidoit and Rolf Hennicker, Observational logic. In A. M. Haeberer, ed., Proc. of AMAST‘98, LNCS 1548,263-277. Springer-Verlag, 1999.

472