The StructureofDevelopment Thought: The Structure of Development Thought MOCA Meeting U Twente 11 May 2005 Michael Jackson jacksonma@acm.org


An Informal Talk About ‘Modelling’: An Informal Talk About ‘Modelling’ Emphasise: What descriptions or ‘models’ must be made How they must fit together What’s difficult about it An approach to problem structure Some general ideas and principles Disregard: Specific notations Formal manipulations in detail Implementation, programming etc A small example problem Addressing some selected concerns


Irrigation Problem: Irrigation Problem Avge 25lpm fairly evenly over 24 hrs Here’s our customer—a farmer wanting irrigation for the crops he grows


Irrigation Problem: Irrigation Problem Here’s where he wants it: farm fields with irrigation channel and sluice gate


Irrigation Problem: Irrigation Problem Here’s the computer we must specialise to achieve irrigation (we will write suitable ‘irrigation software’)


Irrigation Problem: Irrigation Problem Here’s the computer’s (electrical) connection to the world


Irrigation Problem: Irrigation Problem The water channel and the sluice gate The farmer, what he wants and what he will refer to in judging the system The machine we must build The machine’s connection to the world


Diagrammatic Representation of Problem: Diagrammatic Representation of Problem


Irrigation Problem: Basic Conceptual Structure: Irrigation Problem: Basic Conceptual Structure a: shared phenomena (electrical interface to sluice gate) b: requirement phenomena (water flow in channel at time t) Necessary descriptions (‘models’?) R: the customer requirement in terms of phenomena b W: world properties constraining and relating a andamp; b S: the specification of machine behaviour at a (Note: All of S, R and W are about problem world phenomena) Satisfaction argument: S, W  R 'There is no world in which S and W hold but R does not'


Why It’s Hard: Why It’s Hard The problem world is non-formal (unbounded) Any formal description is an approximation Interpretations of formal terms are fuzzy Reasoning about the world can not be fully reliable The machine is formal (by design) a is formally restricted to ‘low bandwidth communication’ The fundamental consequences Perfect ‘models’ of the world are impossible, but ... ... the ‘models’ are fully determinative of the product (this is not true in established engineering branches) ‘Normal design practice’ is vital for dependable results


A Novel Product Design: A Novel Product Design The Tacoma Narrows bridge 1940 Theodore L Condron proposed wider (52 ft) roadway 'The span/width ratio is radical, not normal' Condron was persuaded by Moisseiff’s reputation and his 'deflection theory', and the bridge was built with a narrow (and shallow) roadway as designed C. Michael Holloway; From Bridges and Rockets, Lessons for Software Systems Proc 17th International System Safety Conference, 1999 Span(ft) Width(ft) Ratio 1,750 89 1:19.7 ... ... ... 4,200 90 1:46.7 2,800 39 1:72 Date Bridge 1926 Delaware River ... 1937 Golden Gate 1940 Tacoma Narrows


Decomposing the Problem World Into Domains: Decomposing the Problem World Into Domains c: gate position and associated water flow through the gate, depending on water level in channel etc Problem world properties Of the water channel domain: relating c and b Of the sluice gate domain: relating a and c Exploiting the water channel properties Avge 25lpm over 24 hrs at b  gate open 6.25min/hr at c Exploiting the sluice gate properties Gate open 6.25min/hr at c  some behaviour at a


A Reduced Problem: A Reduced Problem We have reduced the problem by taking account of the water channel properties, and now need to develop in terms of: RG: the customer requirement at c WG: sluice gate properties constraining and relating a andamp; c SG: the specification of machine behaviour at a Stronger than S for the original unreduced problem Satisfaction argument: SG, WG  RG Obviously SG = ‘raise and lower the gate appropriately’


A Problem World Domain: the Sluice Gate: A Problem World Domain: the Sluice Gate Motor(on,off); Dir(up,down): externally controlled MTemp: [-50..200]: internally controlled Top, Bot: boolean: internally controlled Interface a: Interface c: GatePos: [0..20]: internally controlled Open  GatePos = 190.5 Closed  GatePos = 0.50.5


Domain Properties: the Sluice Gate: Domain Properties: the Sluice Gate Gate travel is mechanically limited by stops Sensors detect ends of gate travel Top  Open; Bot  Closed Motor drives gate up and down Closed  Motor=on  Dir=up  [ rise_time] Open Open  Motor=on  Dir=down  [ fall_time] Closed Motor rated to operate at up to 120C Sharp rise 2C/sec at 150% load


Choices in Modelling and Solution: Choices in Modelling and Solution SG = ‘Raise and lower the gate appropriately’? What phenomena should be monitored? Rely on rise_time and fall_time? Rely on Top and Bot sensors? Rely on Motor temperature increase at stops? How to allow for stopping distances? Pause periodically to avoid overheating motor? Choices of WG and SG are related WG: one chosen formal abstraction of a rich reality SG: ‘relies on’ WG; ‘guarantees’ RG [Jones, Stølen]


About Problem Concerns: About Problem Concerns The basic concern: find SG s.t. SG, WG  RG Normal design practice implicitly identifies other concerns Three (of several other potential) concerns are: Breakage (a concern for Control Machine SG) No reverse while running; no overrunning stops; ... Initialisation (? a concern for Control Machine SG) Coordinating initial states of machine and problem world Domain reliability (not a concern for Control Machine SG) What if something goes wrong with the sluice gate? Must protect motor from burnout by overload


Two Subproblems: Two Subproblems Two requirements: 1. Gate Open (approximately) 6.25m/hr 2. If something is wrong, ensure motor is not burnt out (eg switch motor off if log is jammed in gate) The two requirements are potentially in conflict The two requirements demand different ‘models’ of SG


The Safety Subproblem: The Safety Subproblem If something is wrong, switch off motor to avoid burn out What is ‘something is wrong’ (Failure)? Log caught in gate Sensor failure (stuck on or stuck off) Motor overheated Mechanism rusted or jammed ... How to detect Failure? Using evidence from Top, Bot, Motor, Dir, MTemp


Decomposing the Safety Subproblem: Decomposing the Safety Subproblem Model domain is a designed local variable of Safety Machine [Apology: the ‘Use Model’ subproblem is entirely trivial here and some issues about d2/e2/g are ignored]


Models and ‘Models’: Models and ‘Models’ Phenomena e1 = {sensor_fail, log_jam, ...} d1 = SGCM! {Top, Bot, Motor, Dir, MTemp} g = {Model_fail} f = SM1! {Model_op1, Model_op2, ...} Requirement Model_fail  sensor_fail  log_jam  ... SGate and Model of SGate are distinct domains Each domain demands a properties description W


‘Models’ of the Sluice Gate Equipment: ‘Models’ of the Sluice Gate Equipment Control Machine relies on M1 for achieving irrigation Safety Machine 1 relies on M2 for detecting equipment failure Safety Machine 1 builds a model domain satisfying M3 Safety Machine 2 uses M4 as surrogate for equipment failure Safety Machine 2 relies on M5 for turning motor off No two ‘models’ are the same; M1, M2, M5 are approximate


Problem Decomposition Generally: Problem Decomposition Generally Each subproblem Has its own problem world and requirement Is a member of a recognised class (normal design) Is considered in isolation (deferring composition concerns) Subproblem concerns more reliably identified and addressed Therac-25 data entry example: ‘end-of-data-entry’ was incorrectly specified, designed or implemented


Therac-25 Data Entry: Therac-25 Data Entry 'The command line ... is the cursor’s normal position when the operator has completed all necessary changes to the prescription. Prescription editing is signified by cursor movement off the command line. .. Under the right circumstances the data-entry phase can be exited before all edit changes are made on the screen.' Nancy G Leveson and Clark S Turner; An Investigation of the Therac-25 Accidents; Computer July 1993 pages 18-41.


Composition Concerns (Deferred): Composition Concerns (Deferred) Composition concerns arise from common phenomena Interference (mutual exclusion, granularity) Interleaving ((static,dynamic) vs (dynamic,static)) Conflict (motor=on, motor=off) Switching (subproblems as operation modes) Sharing (eg screen space) Redundancy (eg overlapping models) Identifying and addressing composition concerns Conceptually a distinct, explicit development task


Summary: Structure and ‘Modelling’: Summary: Structure and ‘Modelling’ ‘Models’ are descriptions, sentences, predicates, ... They appear in reasoning: eg 'S, W  R' They are ‘modal’: eg ' we hope domain D satisfies M' ‘Modelling’ can be exact only for a formal domain Most problem domains are non-formal Known effective ‘models’ embodied in normal design However, a structure of ‘models’ can approximate reality eg 'M1;  M1  M2; ...' Formal ‘models’ are exact for model domains Structured local variables of machines Different subproblems need different ‘models’ The different ‘models’ may not be consistent or even commensurable


Panel Statement: Panel Statement Question: Do ‘models’ discipline the thoughts of the designer? My view: 1. It is (of course) a necessary discipline to describe relevant topics other than the program code itself. 2. Unfortunately, description of other relevant topics is easily confused with description of the program code. 3. ‘Models’ are not just assertions or specifications: they are descriptions, predicates, sentences in explicit reasonings. 4. Often one domain demands several different ‘models’. 5. Good approximations usually come from normal design. 6. One benefit of ‘models’ is—or should be—the conceptual development structure that they necessitate.