Methods of Software Development Problem Frames 3

1
Methods of Software Development Problem
Frames 3

• (This lecture is largely based on material
  graciously provided by Professor Mary Shaw)

2

• Are there any questions?

3
News article, 20 Oct 1992

• AMBULANCE CHIEF QUITS AFTER PATIENTS DIE IN
  COMPUTER CRASH By Ian MacKinnon and Stephen
  Goodwin
• The Chief executive of the London Ambulance
  Service resigned yesterday over allegations that
  up to 20 people may have died because of the
  collapse of a new computer system controlling
  emergency calls. Virginia Bottomley, Secretary of
  Sate for Health, was forced to announce an
  external inquiry into the 36 hours over Monday
  and Tuesday which led to delays of up to three
  hours in ambulances arriving.

4
London Ambulance Manual Dispatch

• Call Taking
• Control Assistant (CA) writes down the call
  details on a pre-printed form
• Incident location is identified from a map book
• Incident form is placed into a conveyor belt
  system
• The conveyor belt then transports the forms to a
  central collection point
• Resource Identification
• Staff member collects the forms from the central
  collection point
• Uses information on the form to decide which
  resource allocator should deal with it
• three London Divisions - North East, North West,
  and South
• Identifies potential duplicated calls
• Resource allocator then uses status and location
  information provided through the radio operator
  and noted on forms maintained in the "activation
  box" for each vehicle, decides which resource
  should be mobilised
• This resource is then also recorded on the form
  which is passed to a despatcher
• Resource Mobilisation
• The despatcher will telephone the relevant
  ambulance station (if that is where the resource
  is) or will pass mobilisation instructions to the
  radio operator if the ambulance is already in the
  field
• This whole process should take no more than 3
  minutes.

5
London Ambulance Manual System Problems

• identification of the precise location can be
  time consuming due to often incomplete or
  inaccurate details from the caller and the
  consequent need to explore a number of
  alternatives through the map books
• the physical movement of paper forms around the
  Control Room is inefficient
• maintaining up to date vehicle status and
  location information from allocators' intuition
  and reports from ambulances as relayed to and
  through the radio operators is a slow and
  laborious process
• communicating with ambulances via voice is time
  consuming and, at peak times, can lead to
  mobilization queues
• identifying duplicated calls relies on human
  judgment and memory. This is error prone
• dealing with call backs is a labor intensive
  process as it often involves CA's leaving their
  posts to talk to the allocators
• identification of special incidents needing a
  Rapid Response Unit or the helicopter (or a major
  incident team) relies totally on human judgment.

6
London Ambulance Automation Issues

• The London Ambulance Service decided to install a
  Computer-Aided Dispatch system.
• There were numerous problems. We focus here on
  the design of the system architecture.
• This does not diminish the role of management,
  political, procurement, scaling, training, and
  deployment problems.
• We are only provided with Report of the Inquiry.
  
• http//www.cs.ucl.ac.uk/staff/a.finkelstein/las.ht
  ml
• From this we can infer a requirement.
• This study used in the software architecture
  research community as an example for trying out
  new ideas.

7
Critical Requirements

• Ambulance dispatch functionality
• Calls report incidents and other needs for
  transport
• An ambulance arrives at the location of an
  incident promptly the ambulance may take
  patient(s) to hospital
• Other requirements
• Timely response without communication overload
• Resilience to faulty communication
• Resilience to independent field decisions by
  personnel
• Incremental information about incident
• Efficient use of resources, efficient response
• System considerations
• Incremental deployment
• Fit with existing system processes

8
First cut at context and problem
Commanded behavior
Ambulance arrives atincident promptly, maytake
patient to hospital
9
Problem Domains

• Calls telephone calls from the public and
  doctors
• Resources ambulances, personnel, special
  equipment
• But
• Calls do not correspond directly to incidents
• Detailed knowledge of geography is required to
  interpret calls and to know which ambulance to
  send
• So add domains
• Incidents discrete events that require ambulance
  response
• Geography Streets, addresses, hospital
  locations, etc

10
Ambulance Context
Calls
Real World Geography
a
e
AmbulanceDispatchMachine
d
b
Resources
Incidents
a 911 call d create,update,close incidentb
dispatch message e geographic factsc requests
11
Ambulance Problem
Calls
Real World Geography
a
e
d
b
Resources
Incidents
Ambulance arrives atincident promptly, maytake
patient to hospital
b
c
a 911 call d create,update,close incidentb
dispatch message e geographic factsc requests
12
Call Taking
Calls
Workpiece
Real World Geography
a
Prioritizes calls Establishes location of
incident Combines multiple calls about each
incident
Incidents reflect info in calls
d
Resources
a 911 call d create,update,close incident
13
Geographic facts
Calls
Geography Machine
Real World Geography
Geography Model
Geog is OK
Resources
Incidents
Model domain (ch 7)
14
Call Taking
Calls
Geography Machine
Real World Geography
a
Incidents reflect info in callsand geography
Geography Model
e
Geog is OK
d
Resources
a 911 call d create,update,close incident
a 911 call d create,update,close incidentb
dispatch message e geographic factsc requests
15
Ambulance Dispatch
Calls
Real World Geography
Commanded behavior
Actually dispatches ambulances based on incidents
and status of resources
Resources
Incidents
Dispatch
d
b
Ambulance arrives atincident promptly, maytake
patient to hospital
16
Ambulance Dispatch
Calls
Geography Machine
Real World Geography
Geography Model
Geog is OK
e
Resources
Incidents
Dispatch
d
b
Ambulance arrives atincident promptly, maytake
patient to hospital
17
Combined Ambulance Dispatch
Calls
Geography Machine
Real World Geography
a
Incidents reflect info in calls
Geography Model
e
Geog is OK
e
d
Resources
Incidents
Dispatch
d
b
Ambulance arrives atincident promptly, maytake
patient to hospital
Note Incidents islexical in CallTaking,
biddable in Dispatch
18
Composition by Sharing Domains

• A domain is a view, or projection, of physical
  reality that emphasizes properties of interest
• Different subproblems deal with different
  properties
• Composition requires consistent views

Reality
19
Revisit Call Taking
Calls
Workpiece assumes Calls are biddable and
Incidents lexical That would work if call taking
were completely automatic. It isnt. Human
operators have to map calls to incidents. So
split into two subproblems one with operators
editing the Incident workpieces, another
transforming calls mechanically to a form the
operator can handle (prioritizing based on
origin, adding inferable geography, etc)
a
Incidents reflect info in calls
d
20
Processing Incoming Calls
Calls
Operator
Whats going on here?

• 1 A sequence of calls
• 2 A sequence of 999, Doctors urgent, and
  transport calls
• 3 A sequence of typed calls, identifiable by
  location
• location from call box location or query by
  operator
• 4 A sequence of typed calls, with ringing and
  waiting handled
• criteria for delay, policy for ordering (?)
• 5 A buffered, sorted sequence of ltcall, type,
  caller-idgt with other location information
• 6 A buffered, sorted sequence of ltcall, type,
  caller-idgt with other information that identifies
  the incident

21
Revisit Call Taking
Calls
Incidents reflect info in calls
Transformation
Operator
Workpieces
22
Revisit Dispatch
Commanded behavior assumes Incidents are biddable
and Resources are causal. This assumption is one
of the major causes of the original failure In
fact, Resources turned out to be a model of the
real resources, and the model was not accurate.
Causes were radio and location failure, equipment
malfunction, poor tracking of equipment, but most
severely, initiative on the part of the ambulance
crews (they were biddable-active, not
reactive-causal).
Resources
Dispatch
d
b
Ambulance arrives atincident promptly, maytake
patient to hospital
23
Heuristics used in finding subproblems

• Identify core problem, find ancillary problems
• Start from dispatch, recognize need for calls,
  geography
• Standard decomposition
• Geography is clearly a model, so we found
  model-using and model-building subproblems.
  Refer to the previous lecture (and Chapter 7) for
  details on model variants.
• Concerns and difficulties
• Treating resources as reactive-causal caused
  major trouble
• Modeling the user (whos actually the user here?)
• Failure to model ambulance crews caused major
  trouble

24
Things to think about on your ownHow would you
decompose Dispatch?
Resources
Dispatch
X
B
Ambulance arrives atincident promptly, maytake
patient to hospital
25
Things to think about on your ownMaking Problem
Frames work in practice.

• Based on what youve learned about Problem
  Frames,
• Name one thing that you plan to do in software
  development after you graduate.
• (Or put another way, name one thing that you have
  learned from Problem Frames that will help you in
  your career.)

26

• Are there any questions?