PROBLEM FRAMES

Joseph k Raj

M. Tech 1st Sem

HISTORY OF PROBLEM FRAMES

• Problem frames is an approach to Software Requirements Analysis. It was developed by British software consultant Michael A. Jackson in the 1995.

• It has received its fullest description in his Problem Frames: Analysing and Structuring Software Development Problems (2001).

PROBLEM FRAME• It is a description of a recognizable class of problems, where the

class of problems has a known solution

• It provide a conceptual language for recognizing familiar problems in the client’s requirements.

• A recognized class of problems is called a problem frame.

• What happens if you just start building right away?• You could build the wrong system

• You could discover a critical issue late in development.

DOMAINS

Machine Domain

CausalDomain

C

LexicalDomain

X

BiddableDomain

B

• The system to be built

• Behavior might be partial

Behaves predictably But might fail

Behaves unpredictably Often a human user

Data repository Physical embodiment

ignored

Machine Domain

GivenDomain

DesignedDomain

GivenDomain

In problem frame diagrams

In problem or context diagrams

CONTEXT DIAGRAMS

• Show the relevant domains in the problem

• Lines show shared phenomena (events, states)• a – states shared only by machine and domain 1• b – states shared only by machine and domain 2• c – states shared only by domains 1 and 2• d – states shared by all three domains

Machine Domain

GivenDomain 1

GivenDomain 2

a

b

cd

RECOGNIZED PROBLEM FRAMES

•Required Behaviour

•Commanded Behaviour

• Information Display

• Simple Workpieces

• Transformation

REQUIRED BEHAVIOUR• There is some part of the physical world whose behavior is to be controlled

so that it satisfies certain conditions. The problem is to build a machine that will impose that control.

Control Machine

b Controlled Domain

Required Behaviour

a

COMMANDED BEHAVIOUR• There is some part of the physical world whose behaviour is to be controlled

in accordance with commands issued by an operator. The problem is to build a machine that will accept the operator's commands and impose the control accordingly.

b

c

a

d

Control Machine

Operator

Controlled Domain

CommandedBehaviour

INFORMATION DISPLAY • There is some part of the physical world about whose states and behaviour

certain information is continually needed. The problem is to build a machine that will obtain this information from the world and present it at the required place in the required form.

b

c

a

d

InformationMachine

Real World

Display

Display-Real World

SIMPLE WORKPIECES• A tool is needed to allow a user to create and edit a certain class of

computer processing text or graphic objects, or similar structures, so that they can be subsequently copied, printed, analysed or used in other ways. The problem is to build a machine that can act as this tool.

b

c

a

d

Ending Tool

User

Work Pieces

CommandEffects

TRANSFORMATION• There are some given computer-readable input files whose data must be

transformed to give certain required output files. The output data must be in a particular format, and it must be derived from the input data according to certain rules.

b

c

a

d

TransformMachine

Inputs

Outputs

IO Relation

EXAMPLE: ONE-WAY TRAFFIC LIGHTS • The repairers put one unit at each end of the one-

way section and connect it to a small computer that controls the sequence of lights. Each unit has a Stop light and a Go light. The computer controls the lights by emitting RPulses and GPulses, to which the units respond by turning the lights on and off. The regime for the lights repeats a fixed cycle of four phases. First, for 50 seconds, both units show Stop; then, for 120 seconds, one unit shows Stop and the other Go; then for 50 seconds, both show Stop again; then for 120 seconds the unit that previously showed Go shows Stop, and the other shows Go. Then the cycle is repeated.

ONE-WAY TRAFFIC PROBLEM DIAGRAM

• a: { RPulse1, GPulse1, RPulse2, GPulse2 }

• b: { Stop1, Go1, Stop2, Go2 }

• Exclamation point shows which domain controls events

• a: LC ! { RPulse1, GPulse1, RPulse2, GPulse2 }

• b: LU ! { Stop1, Go1, Stop2, Go2 }

• Notice that we carefully distinguish pulses from lights

Lights Controller Light units

a b

Light cycle