Formalism and Intuition in Software Development

Formalism and Intuition in Software Development... intuition and deduction, on which alone we rely in the acquisition of knowledge. René Descartes Michael Jackson The Open University jacksonma@acm.org FME Meeting CWI Amsterdam March 8 2013 07/03/2013 FME2013CWI 1 of 30

What do I mean by formalism and intuition? 07/03/2013 FME2013CWI 2 of 30

Formalism is using calculi of symbols Reasoning over symbol structures according to the rules of a strict calculus, to deduce certain conclusions from axioms... decisive step of mathematical abstraction... forget what the symbols stand for... many operations to carry out without having to look at the things they stand for. Hermann Weyl, 1940 Intuition is comprehension of the world before us Comprehending worldly truths by direct observation and past experience, without appeal to conscious reasoning Intuition is the way we translate our experiences into judgments and decisions... using patterns to recognize what s going on in a situation. Gary Klein; Intuition at Work, Doubleday, 2003 07/03/2013 FME2013CWI 3 of 30

What do I mean by software development? Here s an example 07/03/2013 FME2013CWI 4 of 30

Lift-control system: a development problem A normal design task Mitsubishi, Thyssen, Otis, Schindler, Fuji, Kone,... System behaviour must satisfy all of the stakeholders requirements!??? Diamond Trac Elevator (Mitsubishi): >50 Computer-Controlled Features But I ll consider it as a radical design task 07/03/2013 FME2013CWI 5 of 30

What are the development activities inviting possible use of formalism and/or intuition? 07/03/2013 FME2013CWI 6 of 30

Lift-control system: development activities M Lift Controller Lobby Display Lift Equip t Floors Building Manager Buttons Users W System Behaviour R??? (Behaviour R must satisfy stakeholder requirements) In some order / interleaving... Identify stakeholders, discover and describe requirements Discover, describe and analyse problem world properties W Design a satisfying system behaviour R Ensure R satisfies requirements (and stakeholders agree) Invent and specify a feasible machine behaviour M Formally demonstrate that M,W = R Convince the regulator that system is safe... How do formalism and intuition apply to these activities? 07/03/2013 FME2013CWI 7 of 30

Formalism and intuition have a common pattern, but differ in their basic characteristics 07/03/2013 FME2013CWI 8 of 30

The common pattern of describing and reasoning description A names reasoning description B names interpretation phenomena interpretation phenomena Describe, reason, conclude, interpret Phenomena Reality Names Language Types Connectives Logic Inference Precise Vague 07/03/2013 FME2013CWI 9 of 30

Formalism emphasises correct reasoning It must be possible to replace in all geometric statements the words point, line, plane, by table, chair, mug. David Hilbert, quoted by Hermann Weyl, 1944 I look at a formal description of a reality: the symbolic text appears as a new reality in its own right description A interpretation names reasoning interpretation description B names 07/03/2013 FME2013CWI 10 of 30

Intuition emphasises the subject reality Uttering a word is like striking a note on the keyboard of the imagination. Ludwig Wittgenstein; Philosophical Investigations, I.6 I look at an informal description: the language does not present a second reality: I see the described reality description A interpretation names reasoning description B interpretation names 07/03/2013 FME2013CWI 11 of 30

How formalism and intuition differ description A interpretation reasoning names interpretation description A names reasoning interpretation description B names interpretation description B names Intuition allows Flexible language definition Phenomena of any types Flexible description syntax Extensible reasoning logic Partial inconsistent models Intuition presents understanding Reasoning is unreliable Conclusion is unreliable in reality! Formalism demands Exact language definition Phenomena language types Predefined description syntax Predefined reasoning logic One fully consistent model Formalism presents theorems Description A => description B Conclusion is unreliable in reality! 07/03/2013 FME2013CWI 12 of 30

Formalism is for proving theorems, intuition is for learning, exploring, approximating and inventing 07/03/2013 FME2013CWI 13 of 30

Formalism and intuition: what they are for Thus logic and intuition have each their necessary rôle. Each is indispensable. Logic, which alone can give certainty, is the instrument of demonstration; intuition is the instrument of invention. Henri Poincaré, 1908 A practical description combines some of both eg: non-formal main structure of a formal text eg: local use of FSM, FOPL,... in non-formal text So: how can we use formalism to best advantage? Where do its disadvantages hurt most? How can we benefit from its certainties? 07/03/2013 FME2013CWI 14 of 30

A paradox? Formalism can t handle the real difficulties of software complexity 07/03/2013 FME2013CWI 15 of 30

Complexity of requirements Train control system Never 2 trains in one segment Assembling a train? Crash rescue? Lift control system Door_Open => Car_At_Floor Firefighter mode? Maintenance mode? Car_Stopped => Car_At_Floor Free-fall prevention on broken cable? Access control system In_Room (p,r) => Authorised(p,r) Forbidden by fire regulations! 07/03/2013 FME2013CWI 16 of 30

Complexity of the problem world Fuzzy phenomena Lamp_Lit Dim bulb? Bulb failed? Dirty glass? Lift_At_Floor[f] Within 1cm of floor f home position? Lift car stationary at floor f? What if sensor actuator is broken? Dubious physical properties Switch-On => Lamp_Lit Switch failure? No power? Circuit interrupted? Motor_On => Lift_Rising Motor burnout? Relay failure? Gearbox failure? Hoist cable broken? 07/03/2013 FME2013CWI 17 of 30

Formalism is used most effectively when the context of application is restricted 07/03/2013 FME2013CWI 18 of 30

Context: source and solution of complexity M Lift Controller Lobby Display Lift Equip t Floors Building Manager Buttons Users W System Behaviour R??? (Behaviour R must satisfy stakeholder requirements) Many operational contexts Service demand patterns: daily, weekly, occasional,... Equipment maintenance, licensing inspection,... Fire in building, earthquake, flood,... Many possible equipment faults of varying severity Failure of one floor sensor, doors won t open / close, failure of hoist motor, hoist cable broken,... In each ensemble of concurrent contexts... Certain problem world assumptions hold well enough Certain associated requirements are to be satisfied 07/03/2013 FME2013CWI 19 of 30

We must identify, structure, and understand the many contexts informally 07/03/2013 FME2013CWI 20 of 30

Some candidate contexts Fault-free normal lift service Firefighter lift service Test mode behaviour Maintenance mode Failure-reduced service Maintain lobby display Door open and close Lift Svce Controller a b c Lift Equip t Floors d e f Emergency Brake Buttons g Users Fault-free Normal Lift Service Overloaded travel prevention (?) Fault detection and diagnosis Free fall prevention Editing priority scheme Managing priority schemes Safe lift parking Tycoon floor security (?)...?? FreeFall Machine a c Lift Car d e Floors g h Prevent High Falling Speed 07/03/2013 FME2013CWI 21 of 30

Behaviours in contexts are inventions (contrivances) Here s an example 07/03/2013 FME2013CWI 22 of 30

An example context: free fall prevention An identified context is invented A requirement to be satisfied a Emergency Brake d Properties holding well enough Invention begins with an idea FreeFall Machine c Lift Car e g Brake on High Falling Speed Unforeseen details come later Floors Invention can t be done by formalism! The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise. Edsger Dijkstra, Turing Award Lecture, 1972 Invention in the material world depends on imprecision Unforeseen details compel adjustment to any abstraction 07/03/2013 FME2013CWI 23 of 30

The role of formalism: to check the product of intuition FreeFall Machine a Emergency Brake d Lift Car g No Free Fall a: FFM! Apply_Brake c: Flrs! Sensor_On[f] d: EBr! Lock_Car_In_Shaft e: LCar! Arrive_Floor[f] g: Lift_Car_Falling_Speed c e Floors Operational principle explains how it works Traversal: g e c a g Not physics or mathematics, but logic of contrivance... parts combining to an overall operation which achieves the purpose of the machine (Polanyi) Formal mathematical and physical analysis Follows and evaluates causal links in traversal 07/03/2013 FME2013CWI 24 of 30

Two thoughts about software development method 07/03/2013 FME2013CWI 25 of 30

Development method 1 Method consists entirely in properly ordering and arranging the things to which we should pay attention. Rene Descartes; Works Volume X, p379: Rules for the Direction of the Mind, Rule V. Development must rest on rich understanding...... obtained by informal exploring, discovering, learning...... unconstrained by premature abstractions Any one formalism inherently compels many abstractions eg abstracting from agency and control eg abstracting from machine vs problem world distinction eg abstracting from given vs required distinction eg abstracting from non-truth-functional phenomena eg abstracting from the logic of contrivance (Polanyi) So: formalise late, formalise locally, formalise variously! 07/03/2013 FME2013CWI 26 of 30

Development method 2 Formalism s neglected roles Formalism too often aims at a unified consistent model Eventually the system must be (in some sense) unified...... but only once the local contexts are understood Tasks for formalism Formalising and verifying in each local context Analysing mutual consistency of local contexts Exploiting logic of contrivance for safety cases Reconciling heterogeneous local contexts Transforming reconciled contexts to software view... 07/03/2013 FME2013CWI 27 of 30

Envoi: one last word 07/03/2013 FME2013CWI 28 of 30

Envoi A formal method of system development has the same virtues and limitations as an arithmetic method of designing a house Anonymous 07/03/2013 FME2013CWI 29 of 30

Thank you! 07/03/2013 FME2013CWI 30 of 30