Problem Frames Introduction
Transcript of Problem Frames Introduction
-
8/6/2019 Problem Frames Introduction
1/64
Defining and structuring
software problemsthrough Problem Frames
Charles Wallace Xinli Wang Virginia Bluth
Michigan Technological [email protected]
mailto:[email protected]:[email protected] -
8/6/2019 Problem Frames Introduction
2/64
Software problems(Jackson, 1995)Problem context: interaction between software machine
and its environmentRequirements: stated purely in terms of environmental phenomena
Specification: restricted to machine-environment phenomena
phenomena visible outside machine
(requirement phenomena)
phenomena that affect machine state
machinephenomenaspecificationphenomenaenvironmentalphenomena
-
8/6/2019 Problem Frames Introduction
3/64
Locating and bounding the problem(Jackson, 1995, 2000)
Problem stated in terms of concrete, observable phenomena
avoids overgeneralization of context
(getting away from the realities of the customers world)
Problem stated in terms of machine-environment interaction
avoids overgeneralization of requirements(getting away from the realities of the customers problem)
-
8/6/2019 Problem Frames Introduction
4/64
What are phenomena?
events: indivisible, instantaneous occurrences arrival of elevator car at a floor
elevator user pressing floor button
states: entity properties, or relations between entities
notinstantaneous; have some duration
elevator door status: closed, closing, open, opening
floor at which elevator car is currently parked
weight of car contents
-
8/6/2019 Problem Frames Introduction
5/64
What is the machine?
The software product under development(which possibly interacts with other software machines)
Be careful about what you mean by machine
e.g. In workpieces problems (e.g. word processor,
spreadsheet), the workpieces are documents, residingin computer memory;
still, best to think of them as outside the machine
-
8/6/2019 Problem Frames Introduction
6/64
Example: Elevator controller problem
environmental phenomena outside machine domain:
physical position of elevator car current speed and direction of cable
illumination of floor buttons on panel
updating car_direction variable
decrementing time_to_door_close counter
adding floor request to pending_requests
machine phenomena invisible to environment:
shared phenomena:
open the door command (from controller)door is blockedsignal (to controller)
-
8/6/2019 Problem Frames Introduction
7/64
Problem structuring(Jackson, 1995, 2000)
Attack the complexity of a software problemby creating a set ofprojections of the problem
Projections (subproblems) may overlap (i.e. share phenomena)
Each projection belongs to a well-known class
of similar problems: a problem frame
Strong similarities to notion ofdesign patterns
As we deal with instances of each problem frame,
we learn heuristics (rules of thumb) for documenting and
learning about such problems
-
8/6/2019 Problem Frames Introduction
8/64
Problem frame document
components: single context diagram +
multiple problem diagrams
diagram elements:
domains (nodes)
requirements (nodes)
interfaces (shared phenomena) (edges)
requirement references (edges)
-
8/6/2019 Problem Frames Introduction
9/64
Domains
represent sets of individuals
(distinguishable things of interest in problem)
domain may possess certain attributes
may be related to other domains via shared phenomenaMachine domain: exactly one per problem frame
no attributes except those shared with environment
Realized (designed) domain: software developers may help in its design
typically, electronic representations of data
-
8/6/2019 Problem Frames Introduction
10/64
Connection domain
exists purely as intermediary between multiple domainse.g. communication channel
can always be ignored...
pro: higher abstraction level con: abstraction may leak
reasons to include connection domain:
communication failure communication delay
connection domain referred to in requirements
conversion of phenomena via connection domain
-
8/6/2019 Problem Frames Introduction
11/64
Shared phenomenon (Interface)
e.g. admission machine detects coin inserted by customer
(domain) (interface) (domain)
Note the abstraction here:mechanism for accepting and detecting coin ignored
OK if coin detection is a given;
not OK if we're designing the coin detector
admission
machineinsertcoin
customer
-
8/6/2019 Problem Frames Introduction
12/64
Beyond binary interfaces
e.g. supermarket purchase
customer clerk
purchase
product
-
8/6/2019 Problem Frames Introduction
13/64
Note: this can be broken into multiple binary interfaces...with a lowering of abstraction level
customer
product
clerkpay
takegive
Now, we have to stipulate that give precedes take;
if pay fails, then take shall also fail,
-
8/6/2019 Problem Frames Introduction
14/64
Requirement
Form: If (antecedent), then (consequent)
Antecedent and consequent refer to shared phenomena
References in the antecedent: descriptive (indicative) mood
References in the consequent: prescriptive (optative) mood
No indicative or optative references to machine domain:
requirements don't refer to machine
Antecedent may be empty, but consequent must not
-
8/6/2019 Problem Frames Introduction
15/64
Requirement example
If the customer inserts a coin,
the gate shall become unlocked.
admission
machinecustomer gate
insert
(event)
lock, unlock
(events)
admissioncriteria
insert
(event)lock-status
(state)
(Note: arrow foroptative reference)
This requirement refers to the (unshared) lock status of gate,rather than the (shared) machine-gate events lock and unlock
-
8/6/2019 Problem Frames Introduction
16/64
Patient monitoring & dosage problemAdapted from (Jackson, 2000)
A patient monitoring program is required for the ICU
in a hospital. Each patient is monitored by an analog
device which measures factors such as pulse, temperature,
and blood pressure. The program reads these factors
on a periodic basis (specified for each patient) and stores
them in a database. For each patient, safe ranges for eachfactor are also specified by medical staff. If a factor falls
outside a patient's safe range, or if an analog device fails,
the nurses station is notified.
-
8/6/2019 Problem Frames Introduction
17/64
Patient monitoring & dosage problem(Continued)
A patient may be connected to an intravenous pump
that supplies medication. There are three ways in whichmedication may be administered via the pump. First,
medical staff may stipulate that a patient is to receive regular
periodic dosages through the pump. Second, staff may
request a single dosage to be applied immediately. Finally,
if authorized earlier by medical staff, a patient may request
an immediate dosage by pressing a button on the pump.
In all cases, the total daily dosage must not exceed the limit
entered earlier by medical staff. If a pump fails, the nursesstation is notified.
-
8/6/2019 Problem Frames Introduction
18/64
Domains:
monitoring program (machine)patients
analog devicesmedical staff
nurses' stationintravenous pump
-
8/6/2019 Problem Frames Introduction
19/64
Factors (vital signs): make them domains?
pulse, temperature, etc. not really concrete things;
probably best to treat them as patient attributes
-
8/6/2019 Problem Frames Introduction
20/64
Periods, ranges & dosages (PR&D): make them domains?
con: they're data structures, internal to solution
pro: any sensible solution will have such data structures
awkward to talk about problem without reference
to these terms
-
8/6/2019 Problem Frames Introduction
21/64
Since the pump and the analog devices both connect patients
to the machine, should they be merged into a single domain?
The pump and the analog devices have little state
information or shared phenomena in common;
best to treat them as separate domains
-
8/6/2019 Problem Frames Introduction
22/64
How about removing medical staff and PR&D?
OK only if each patient gets the same (unchanging) treatment(unrealistic)
-
8/6/2019 Problem Frames Introduction
23/64
How about hiding medical staff behind nurses station?
If so, then nurses station becomes connection domain,channeling staff input to machine
-
8/6/2019 Problem Frames Introduction
24/64
How about removing medical staff and keeping PR&D?
periods & ranges domain allows for different patient
treatments; but treatments cannot change (unrealistic)
-
8/6/2019 Problem Frames Introduction
25/64
How about removing patients?
No way --- vital component of problem,even though theres no direct link to machine
What can we learn from patients? Some examples: range of expected vital sign values
range of expected analog device readings
frequency of patient movement in/out of the ICU
frequency of additions/deletions to PR&D database
patients need for pain medication
usability issues surrounding dosage requests
-
8/6/2019 Problem Frames Introduction
26/64
Factors database: designed domain?
if no database is an off the shelf component,not our right/responsibility to design it
if yes is it to be accessed by others?
if yes we need to add others as a domain
if no database is internal to solution
does it really belong in requirements?
-
8/6/2019 Problem Frames Introduction
27/64
Patient monitoring & dosage problem:
Context diagram
monitor
machine
periods,
ranges& dosages
(designed)
medical
staff
nurses'
station
analog
devices
ICU
patients
a c
d
b
e
a: periods, ranges,
dosages
b: factor report
c: alertd: pump control /
request dose
e: patient readings
f: enter period/range/dose
g: dose button /
administer dose
h: vital signs
IV
pump
factorsdatabase
f
h
g
-
8/6/2019 Problem Frames Introduction
28/64
Problem frames
Simple, generic archetypal subproblems Information display problem
Required behavior problem
Commanded behavior problem
Workpieces problem
Transformation problem
-
8/6/2019 Problem Frames Introduction
29/64
Information display problem frame(Jackson, 2000)
real
world (RW)information
system (IS)
display (D)
report-world
a
c
a
b
a: WorldState (RW) b: Reports (IS)
c: DisplayState (D)
When world state is so-and-so...
machinedetects state info and sendsreport...causing appropriate change indisplay state.
-
8/6/2019 Problem Frames Introduction
30/64
Device failure alert:
Information display problem
If an analog device or pump fails,the nurses' station shall be notified.
(This is really two information display problems in one:
Analog device failure and pump failure)
Real world: Analog devices, IV pump
Information requester: Nurses station
-
8/6/2019 Problem Frames Introduction
31/64
Patient alert:
Information display problem
If a patient's vital signs are outside safe ranges,the nurses' station shall be notified.
Real world: ICU patientsInformation requester: Nurses station
Connection domain: Analog devices
Periods, Ranges & Dosages database must be consulted
-
8/6/2019 Problem Frames Introduction
32/64
Information display
When world state is so-and-so
real world may be static or dynamic
if world is static and small, problem is trivial
if world is dynamic, how frequently does machine sample world?
e.g. Device and patient alert problems:
both involve dynamic real-world phenomena Device alert sampling frequency: fixed
Patient alert sampling frequency: determined by medical staff
Device alert sampling must be frequent enoughnot to hide patient alerts
-
8/6/2019 Problem Frames Introduction
33/64
Information display
machine detects state info...
often, there is a machine-real world connection domain
real world interpreted by sensor or data-entry person
information
system (IS)
sensor (S)a
real
world (RW)a: SensorData (S)
b: WorldData (RW) b
Usual concerns apply with regard to
connection domains: failure, translation, ...
-
8/6/2019 Problem Frames Introduction
34/64
Information display
Device alert problem:
What is the failure model of the devices?
Does device signal its impending failure? (unlikely) Fail-stop: device simply stops sending data
In this case, we may sense failure via device heartbeat
Byzantine: failed device continues to send (bogus) data This complicates failure detection
-
8/6/2019 Problem Frames Introduction
35/64
Information display
Machine must model the real world
e.g. patient modeled as a triple: (temp, blood pressure, pulse rate)
each factor is an electronic approximation of the real vital signs
gap between model and real world: how accurate must model be?
What is the frequency of model state checking? What is the granularity of data?
-
8/6/2019 Problem Frames Introduction
36/64
Information displayrequirement: If P(rw), then display P(rw).
solution: create model mIf Q(m(rw)), then display P(rw).
Do we really need to require that Q(m(rw)) P(rw) ?A weaker condition may be sufficient:
e.g. Q(m(rw)) P(rw) P(rw) Q(m(rw))
(no false positives) (no false negatives)
In device/patient alert problems, false negatives unacceptable
False positives may be tolerated:
risks of wasting medical staff time, annoying patients
-
8/6/2019 Problem Frames Introduction
37/64
Information display
machine sends report, causing appropriate change in
display state.
e.g. Device/patient alert problems
need to know precisely which device has failed also need to know which patient is connected to the device
how are patients identified?
Display design: important nonfunctional (usability) issues
e.g. Alert problems: clarity of presentation is essential
-
8/6/2019 Problem Frames Introduction
38/64
Variant: Commanded displayreal world (RW)
information
system (IS)
enquiry operator (EO)
report-world
a
c
a
b
display (D)c d
a: WorldState (RW) b: Queries (EO)c: Reports (IS) d: DisplayState (D)
When world state is so-and-so... machinedetects state info...
if operator then makes a query... machine sends areport...causing appropriate change indisplay state.
-
8/6/2019 Problem Frames Introduction
39/64
Information display issues
(summary)
world state:
entities, attributes to be displayedcausal relations between real-world entities (laws of nature)
static/dynamic world, rate of sampling
detection:
connection domain? Delays, distortions?model
level of accuracy: frequency of model updates, data granularity
false positives/negatives acceptable?
query (commanded display only)
language of legal queries: syntax (form), semantics (meaning)
report
what information is needed
display:
layout, presentation of information
-
8/6/2019 Problem Frames Introduction
40/64
Required behavior problem framebehavior
rulesacontroller
machine (CM)
bcontrolled
domain (CD)
a: Commands (CM), DomainState (CD) b: DomainState (CD)
Machine issuescommands...
(possibly after considering currentdomain state information)...that keepdomain in an acceptablestate.
-
8/6/2019 Problem Frames Introduction
41/64
Regular dosage:
Required behavior problem
If regular dosage is prescribed for a patient,the given dose will be applied regularly at the given interval,
unless the total daily dosage exceeds the limit.
Controlled domain: IV Pump
Periods, Ranges & Dosages must be consulted
for dosage amount, interval
-
8/6/2019 Problem Frames Introduction
42/64
Required behavior
Information display problem couldbe seen as required behavior,
with the display being the controlled domain, but
in information display problems, controlling the display istypically not difficult;
the real difficulty is in capturing the real world accurately.
-
8/6/2019 Problem Frames Introduction
43/64
Required behavior
Machine issues commands
What are the commands at the machines disposal?
e.g. for Regular Dosage problem, say the commands are
pump on, pump offThis implies that dosages will be determined by precise
timing on the part of the machine
Note the distinction between the commands (at the CM-CD interface)
and the domain state (mentioned in the requirement)
The requirement does not mention anything about machine commands
-
8/6/2019 Problem Frames Introduction
44/64
Required behavior possibly after considering current domain state information...
How much feedback is needed from controlled domain?
If effects of commands are totally predictable,andonly our machine affects domain, then machine needs no state info
Otherwise, need to know
range of variation of commands effects
how to detect failed commands
how to undo/redo failed commands
effects that other domains may have on the controlled domain
-
8/6/2019 Problem Frames Introduction
45/64
Required behavior that keep domain in an acceptable state.
What are the directeffects of the machine commands on the
controlled domain? What are the indirecteffects?
e.g. Can we assume that keeping pump on forx secondsresults in some amountf(x) of medication being administered?
Controlled domain may include uncontrollable states
(e.g. mobile unit that goes out of communication range)
Can controller take domain to a state thats no longer controllable?
If so, need to disable certain sequences of commands
R i d b h i i
-
8/6/2019 Problem Frames Introduction
46/64
Required behavior issues
(summary)
machine commands:
format, effects on controlled domain
range of variation of commands effects
detectability, undoability, redoability of failed commands
effects on the controlled domain from outside the controller
domain state:
what feedback is needed?what is controllable state space?
effects of machine commands on doman:
direct, indirect (via laws of nature)
-
8/6/2019 Problem Frames Introduction
47/64
-
8/6/2019 Problem Frames Introduction
48/64
St ff d i i t d d
-
8/6/2019 Problem Frames Introduction
49/64
Staff-administered dosage:
Commanded behavior problem
Staff may request a single dosage to be appliedto a patient immediately.
Operator: Medical staffControlled domain: IV pump
Periods, Ranges & Dosages database must be consulted
-
8/6/2019 Problem Frames Introduction
50/64
Commanded behaviorOperator issuescommands...
Operator commands and machine commands may be quite different
e.g. single command from patient/staff translated into
a pump on/ pump off sequence, with an appropriatetime interval in between
Design of operator commands is important
e.g. staff-administered dosage: specify dosage level?
need to balance flexibility/expressivity vs. ease/speed of use
Note: patient-administered dosage requests come via the pump;
design of the patient command interface is out of our hands
-
8/6/2019 Problem Frames Introduction
51/64
Commanded behavior
machine rejects non-sensible commands...
sensible commands: have some reasonable meaning given the
context of previous commands
non-sensible commands may be disabled
(e.g. grey out currently non-sensible menu items)
e.g. Staff dosage request for a patient is not sensible withoutan earlier establishment of a daily dosage limit
-
8/6/2019 Problem Frames Introduction
52/64
Commanded behavior
machine ignores commands unviable in current domain state...
viable commands: have some reasonable meaning given the
current state of the controlled domain
disabling unviable commands more difficult;
requires sampling of controlled domain
e.g. Patient dosage requests are always sensible,but not viable if self-dosage not authorized, or
dose would put the daily dosage over the limit
Commanded behavior issues
-
8/6/2019 Problem Frames Introduction
53/64
Commanded behavior issues
(summary)
Issues of required behavior, plus:
operator commands: syntax, mapping to machine commands
sensibility conditions on commandsviability conditions of CD for commands
W k i bl f
-
8/6/2019 Problem Frames Introduction
54/64
Workpieces problem frame(Jackson, 2000)
user (U)
workpieces (WP)
editor
tool (ET)
a
b
edit
workpieces
a
c
a: UserCommands (U) b: WorkpieceOperations (ET)
c: WorkpieceState (WP)
Period Range & Dosage data entry:
-
8/6/2019 Problem Frames Introduction
55/64
Period, Range & Dosage data entry:
Workpieces problem
Sampling periods, safe ranges, and dosages for eachpatient shall be entered by medical staff.
User: Medical staffWorkpieces: Periods, Ranges & Dosages
-
8/6/2019 Problem Frames Introduction
56/64
WorkpiecesSimilar to Commanded behavior frame ---
but controlled domain here is totally computer-internal
Workpieces: intangible software objects (e.g. documents, files)
usually easier to control than domains outside the computer very often a designed domain: our right/responsibility to co-design it
Challenges in workpieces problems:
identifying syntactically correct, sensible user commands
viability conditions
mapping between user and machine commands
Workpieces issues
-
8/6/2019 Problem Frames Introduction
57/64
Workpieces issues
(summary)
Issues of commanded behavior,but the following have less (or no) importance:
range of variation of machine command effects
issues regarding failed commands
controllable state space
Transformation problem frame
-
8/6/2019 Problem Frames Introduction
58/64
Transformation problem frame(Jackson, 2000)
source (S)
destination (D)
transformer
machine (TM)
a
b
mapping
c
d
a: InputStream (S) b: OutputStream (TM)c: InputData (S) d: OutputData(D)
From a collection ofinput data, Source produces input stream...
Machine responds by producing an output stream, creatingoutput data at destination that respects the input-output mapping.
Patient factor storage:
-
8/6/2019 Problem Frames Introduction
59/64
Patient factor storage:
Transformation problem
Patients' vital signs shall be stored in a database.
Source: Analog devices
Destination: Factors database
Note: Though it deals with electronic records,
this is not a workpieces problem, since there is no
autonomous user performing arbitrary operations.
Its a simple translation from one electronic format to another.
-
8/6/2019 Problem Frames Introduction
60/64
TransformationSource produces input stream...
Machine responds by producing an output stream
input rate:
is it truly streaming?
Regular or intermittent?
output rate:
Is there an upper limit?Can input rate ever exceed maximum output rate?
If so, can input data be dropped?
If not, what is the max expected amount of buffering needed?
-
8/6/2019 Problem Frames Introduction
61/64
Transformation
creating output data at destination that respects the input-
output mapping.
Range of possible input data valuesRange of possible output data values
Mapping: one-to-one, one-to-many, many-to-one?
e.g.
Does factors database store summary reports (many-to-one),
or does it store each individual reading (one-to-one)?
Transformation issues
-
8/6/2019 Problem Frames Introduction
62/64
Transformation issues
(summary)
Input/output streams
Input/output rates
Buffering vs. dropping
Input/output data rangesMapping input data to output data
one-to-one, many-to-one, one-to-many
-
8/6/2019 Problem Frames Introduction
63/64
References
M.A. Jackson. Software Requirementsand Specifications. Addison Wesley,1995.
M.A. Jackson. Problem Frames.Addison Wesley, 2000.
B.L. Kovitz. Practical SoftwareRequirements. Manning, 1999.
-
8/6/2019 Problem Frames Introduction
64/64