Moca 2005 1

1
The StructureofDevelopment Thought
Michael Jackson jacksonma_at_acm.org
MOCA Meeting

U Twente11 May 2005
2
An Informal Talk About Modelling

• Emphasise
• What descriptions or models must be made
• How they must fit together
• Whats 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

3
Irrigation Problem
Avge 25lpmfairly evenlyover 24 hrs
Heres our customera farmer wanting irrigation
for the crops he grows
4
Irrigation Problem

• Heres where he wants itfarm fields with
  irrigationchannel and sluice gate

5
Irrigation Problem
Heres the computerwe must specialiseto
achieve irrigation(we will write suitable
irrigation software)
6
Irrigation Problem
Heres the computers(electrical) connection
to the world
7
Irrigation Problem
The machinesconnection to the world

• The water channeland the sluice gate

The farmer, what he wants and what he will
refer to in judging the system
The machinewe must build
8
Diagrammatic Representation of Problem
9
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
  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

10
Why Its 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

11
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 Moisseiffs 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 SystemsProc 17th
  International System Safety Conference, 1999

• Date Bridge1926 Delaware River...
  1937 Golden Gate 1940 Tacoma Narrows

• Span(ft) Width(ft) Ratio 1,750 89
  119.7 ... ... ... 4,200 90
  146.7 2,800 39 172

12
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

13
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 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

14
A Problem World Domain the Sluice Gate

• Interface a

• Motor(on,off) Dir(up,down) externally
  controlled
• MTemp -50..200 internally controlled
• Top, Bot boolean internally controlled

• Interface c

• GatePos 0..20 internally controlled
• Open ? GatePos 19?0.5
• Closed ? GatePos 0.5?0.5

15
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 ? Motoron ? Dirup ? ? rise_time Open
• Open ? Motoron ? Dirdown ? ? fall_time Closed
• Motor rated to operate at up to 120?C
• Sharp rise 2?C/sec at 150 load

16
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

17
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

18
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

19
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

20
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

21
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

22
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

23
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

24
Therac-25 Data Entry
The command line ... is the cursors 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 TurnerAn
Investigation of the Therac-25 AccidentsComputer
July 1993 pages 18-41.
25
Composition Concerns (Deferred)

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

26
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 consistentor
  even commensurable

27
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 isor should bethe
  conceptual development structure that they
  necessitate.