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]


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


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)


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


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


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)


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/64

Problem frame document

components: single context diagram +

multiple problem diagrams

diagram elements:

domains (nodes)

requirements (nodes)

interfaces (shared phenomena) (edges)

requirement references (edges)


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


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


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


12/64

Beyond binary interfaces

e.g. supermarket purchase

customer clerk

purchase

product


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,


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


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


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.


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.


18/64

Domains:

monitoring program (machine)patients

analog devicesmedical staff

nurses' stationintravenous pump


19/64

Factors (vital signs): make them domains?

pulse, temperature, etc. not really concrete things;

probably best to treat them as patient attributes


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


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


22/64

How about removing medical staff and PR&D?

OK only if each patient gets the same (unchanging) treatment(unrealistic)


23/64

How about hiding medical staff behind nurses station?

If so, then nurses station becomes connection domain,channeling staff input to machine


24/64

How about removing medical staff and keeping PR&D?

periods & ranges domain allows for different patient

treatments; but treatments cannot change (unrealistic)


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


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?


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


28/64

Problem frames

Simple, generic archetypal subproblems Information display problem

Required behavior problem

Commanded behavior problem

Workpieces problem

Transformation problem


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.


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


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


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


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, ...


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


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?


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


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


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.


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


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.


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


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.


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


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


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


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)


47/64


48/64

St ff d i i t d d


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


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


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


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


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


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:


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


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


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


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:


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.


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?


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


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


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.


64/64

Problem Frames Introduction

Documents