abc Logic vs Magic or why wizards are

abc Logic vs. Magic or: why wizards are not enough Peter Amey Ada Europe 2001 1

abc Agenda • Introduction: a historical magic • The software process • What are “Critical Systems”? • The need to “reason” • Engineering revisited • Non-technical Issues • Advantages of logic — project experience • Summary Ada Europe 2001 www. sparkada. com 2

abc A Historical Magic • Go to statement considered harmful • Structured programming • “De-spag” tools Ada Europe 2001 3

A Specification abc Add up the first N (positive) values of the array traverse the array until N positive values have been found and sum them or traverse N elements of the array and sum any positive ones (ignoring any negative ones) ? Ada Europe 2001 4

function Sum(A : Atype; Count : Aindex) return Integer is Accumulator, Value : Integer; Index : Aindex; abc begin Accumulator : = 0; Index : = 1; <<Label 1>> Value : = A(Index); if Value <= 0 then goto Label 2; end if; Accumulator : = Accumulator + Value; <<Label 2>> if Index = Count then goto Label 3; end if; Index : = Index + 1; goto Label 1; <<Label 3>> return Accumulator; end Sum; Ada Europe 2001 5

abc function Sum(A : Atype; Count : Aindex) return Integer is IC : Counter; Accumulator, Value : Integer; Index : Aindex; begin IC : = 1; Accumulator : = 0; Index : = 1; while IC < 6 loop case IC is when 1 => Value : = A(Index); IC : = 2; when 2 => if Value <= 0 then IC : = 4; else IC : = 3; end if; when 3 => Accumulator : = Accumulator + Value; IC : = 4; when 4 => if Index = Count then IC : = 6; else IC : = 5; end if; when 5 => Index : = Index + 1; IC : = 1; when 6 => Null; end case; end loop; return Accumulator; end Sum; Ada Europe 2001 6

abc Engineering: The use of science and mathematics to solve practical problems Ada Europe 2001 7

abc the software process Ada Europe 2001 8

abc The software process • Progressive refinement: – a need – requirements – specification – design – source code – object code Ada Europe 2001 9

abc The software process • Progressive refinement: – a need – requirements – specification – design – source code – object code Ada Europe 2001 10

abc The software process • Progressive refinement: – a need – requirements – specification – design – source code – object code Ada Europe 2001 11

abc The software process • Progressive refinement: – a need – requirements – specification – design – source code – object code Ada Europe 2001 12

A Specification abc Add up the first N (positive) values of the array Ada Europe 2001 13

abc The software process • Progressive refinement: – a need – requirements – specification – design – source code – object code Ada Europe 2001 14

abc The software process • Progressive refinement: – a need – requirements – specification – design – source code – object code Ada Europe 2001 15

abc Language Insecurity a tiny example procedure Init 2(X, Y : out Integer) is begin X : = 1; Y : = 2; end Init 2; What is the meaning of: Init 2(A, A); Ada Europe 2001 16

abc The software process • Progressive refinement: – a need – requirements – specification – design – source code – object code Ada Europe 2001 17

abc Formality at last! 1010010000100010010001 10101000111101000010101001010100001010010010101001101010101 0000010101001010010 0101010101011110100101010100101010010 110100101010010100000 1111111010100111111001010101100001001010001010100101000001111 0111000000101001010101 111000001111010000101111 Ada Europe 2001 18

abc A typical development process Informal, opaque black box Precise object code Ada Europe 2001 19

abc what are “critical systems”? Ada Europe 2001 20

abc What are critical systems? • Some important objectives: – efficiency – cost – time to market – functionality Ada Europe 2001 21

abc What are critical systems? • Systems where reliability is more important than: – efficiency – cost – time to market – functionality Robert Dewar - Ada Core Technologies Ada Europe 2001 22

abc Producing Safety-Critical Software • Not just a question of “being more careful” • The need to be able to show, before there is any service experience, that a system will be safe enough requires a qualitatively different approach • We can only achieve this by logical reasoning. Ada Europe 2001 23

abc Foundations of Reasoning • • • We reason about information But what about “information hiding”? We need to hide detail not information We do this through abstraction We can’t just magic complexity away Example: Program “State” Ada Europe 2001 24

abc Swap Algorithm Temp : T; procedure Swap(X, Y : in out T) is begin Temp : = X; X : = Y; Y : = Temp; end Swap; Ada Europe 2001 25

abc Swap Algorithm procedure Swap(X, Y : in out T) is Temp : T; begin Temp : = X; X : = Y; Y : = Temp; end Swap; Ada Europe 2001 26

abc A Store Object package Store is procedure Put(X : in T); function Get return T; end Store; Ada Europe 2001 27

abc Swap Algorithm procedure Swap(X, Y : in out T) is begin Store. Put(X); X : = Y; Y : = Store. Get; end Swap; Ada Europe 2001 28

abc Heap Ada Europe 2001 29

abc Ada Europe 2001 30

abc • The location of state is the single biggest influence on coupling and cohesion. • It is probably the most important design decision we must make yet • OOP regards it as an “implementation detail”; and • UML does not even have a notation to express it! Ada Europe 2001 31

abc OOP - The Biggest Magic of them All • We hide all state • We disguise the hierarchical relationships between objects • We hide the control flow by use of messages and dynamic dispatch • In extreme cases, we even deny there is a software design process at all (Shlaer Mellor) Of course all this hiding makes things easier - at least until all the hidden complexity emerges during integration testing! Ada Europe 2001 32

abc An OOP Array Sum Ada Europe 2001 33

abc “There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. ” Professor C. A. R. Hoare The 1980 Turing award lecture Ada Europe 2001 34

abc “simplicate and add lightness” Bill Stout - designer of the Ford Tri-motor Ada Europe 2001 35

abc Engineering - a brief diversion Ada Europe 2001 36

abc Aerodynamic theory • • Aristotle, Leonardo da Vinci, Newton Pressure/velocity relation: Bernoulli 1738 Frictionless low-speed flow: Euler 1752 Flow with friction: Navier/Stokes 1840 Scale effects: Reynolds 1883 Wright Brothers, Kittyhawk 1903 Lifting-line theory: Prandtl 1915 Ada Europe 2001 37

abc Lifting-line Theory and Aerofoils Ada Europe 2001 38

abc Ada Europe 2001 39

abc Ada Europe 2001 40

abc Engineering: The use of science and mathematics to solve practical problems Ada Europe 2001 41

abc Engineering: Characterised by the blend of practical experience and the use of theoretical results Ada Europe 2001 42

abc Ada Europe 2001 43

abc Ada Europe 2001 44

abc Ada Europe 2001 45

abc Non-technical issues Ada Europe 2001 46

abc Important Non-technical Drivers • • • Fashion Low expectations Poor contract writing The difficulty of saying “no” Gurus Belief that: – Software engineering is the same as knowing tool or product X – Knowing tool or product X is more important than domain or engineering knowledge Ada Europe 2001 47

abc Low Expectations • Software is always buggy • Even Microsoft “the best software company in the world” produces buggy software • Vendors never offer warranties • Since software is always cr*p we might as well buy the cheapest cr*p Ada Europe 2001 48

abc Ada Europe 2001 49

abc Ada Europe 2001 50

abc The benefits of logical reasoning Project Experience Ada Europe 2001 51

abc The Need to Reason • To bring error detection forward we must be able to reason about source code • We can’t reason about source code unless it has a precise meaning • Too often the meaning of code is defined by its test results! Ada Europe 2001 52

abc “… one could communicate with these machines in any language provided it was an exact language …” “… the system should resemble normal mathematical procedure closely, but at the same time should be as unambiguous as possible. ” Alan Turing, 1948 Ada Europe 2001 53

abc What is SPARK? • A sub-language of Ada with particular properties that make it ideally suited to the most critical of applications: – Completely unambiguous – All rule violations are detectable – Formally defined – Tool supported • SPARK facilitates Correctness by Construction Ada Europe 2001 54

abc A disclaimer • SPARK is not the world’s only logic • SPARK is not a superior magic Ada Europe 2001 55

abc A Store Object package Store is procedure Put(X : in T); function Get return T; end Store; Ada Europe 2001 56

abc A Store Object package Store --# own State; is procedure Put(X : in T); --# global out State; function Get return T; --# global State; end Store; Ada Europe 2001 57

abc procedure Swap(X, Y : in out T) --# global out Store. State; is begin Store. Put(X); X : = Y; Y : = Store. Get; end Swap; Ada Europe 2001 58

Lockheed C 130 J Ada Europe 2001 abc 59

Lockheed on SPARK abc • Some errors immediately uncovered by formal analysis, such as conditional initialization errors may only emerge after very extensive testing. • The technology for generating and discharging the proof obligations, based on the SPARK components of Ada, was crucial, in binding the code to the initial requirements. • • SPARK provides an extremely robust and efficient basis formal verification. • • • Experience has shown that SPARK coding occurs at near typical Ada rates. • Correctness by construction is no longer a theoretical abstraction; it is now a practical way to develop software that exceeds its technical goals while delivering sterling business performance. The process has proven effective with typical software developers and did not necessitate and inordinate amount of additional training. Code written in SPARK is deterministic and inherently statically analysable. Very few errors have been found in the software during even the most rigorous levels of FAA testing, which is being successfully conducted for less than a fifth of the normal cost in industry. Ada Europe 2001 60

Lockheed on SPARK abc • Some errors immediately uncovered by formal analysis, such as conditional initialization errors may only emerge after very extensive testing. • The technology for generating and discharging the proof obligations, based on the SPARK components of Ada, was crucial, in binding the code to the initial requirements. • • SPARK provides an extremely robust and efficient basis formal verification. The process has proven effective with typical software developers and did not necessitate and inordinate amount of additional training. • Experience has shown that SPARK coding occurs at near typical Ada rates. • Very Codefew writtenerrors in SPARKhave is deterministic inherentlyin statically analysable. beenandfound the software • Very few errors have been found in the software during even the most rigorous levels of FAA testing, which is being successfully conducted for less than a fifth of the normal cost in industry. which is being successfully conducted for less than • a fifth Correctness by construction no longer theoretical abstraction; it is now a practical of the normalis cost ina industry. way to develop software that exceeds its technical goals while delivering sterling business performance. Ada Europe 2001 61

abc Aerosystems’ IV&V Conclusions • Significant, safety-critical errors were found by static analysis in code developed to DO-178 B Level A • Proof of SPARK code was shown to be cheaper than other forms of semantic analysis performed • SPARK code was found to have only 10% of the residual errors of full Ada and Ada was found to have only 10% of the residual errors of C • No statistically significant difference in residual error rate could be found between DO-178 B Level A and Level B code Ada Europe 2001 62

abc Summary Ada Europe 2001 63

abc “Any sufficiently advanced technology is indistinguishable from magic. " Arthur C. Clarke, 1962 But this doesn’t mean that all magical illusions are underpinned by advanced technology! Ada Europe 2001 64

abc Logic vs Magic • Magic is attractive because life would be so much easier if it worked! • Magic is transient, fashion driven and ultimately futile • Software engineering is hard because we are trying to solve hard problems • The engineering response to solving hard problems is to use clever people and good mathematics • Being the best screwdriver user in the world might make you a mechanic but not an engineer! Ada Europe 2001 65

abc Why I use Ada “The superior pilot uses his superior judgement to avoid those situations that would otherwise require his superior skill” Ada Europe 2001 66

abc and finally “Real life problems are those that remain after you have systematically failed to apply all the known solutions” Edsger Dijkstra, 1973 Ada Europe 2001 67