UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine1 CSE 503 – Software Engineering Lecture 2: Jackson Problem Frames Rob DeLine 31 Mar 2004 Thanks to Mary Shaw of CMU for several slides

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine2 Getting from customer needs to design

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine3 Michael Jackson’s Problem Frames What happens if you just start building right away?  You could build the wrong system  Your decomposition might not simplify the problem  You could discover a critical issue late in development Problem Frames provide a conceptual language for recognizing familiar, tractable problems in the client’s requirements Status as research idea  A proposal with a decade of thought behind it  No tools, no experience reports  Jackson, Problem frames: Analyzing and structuring software development problems, ACM Press, 2001 Not the singer!

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine4 Basic method Identify the involved parts of the world (domains)  Given domains – relevant parts of the world  Designed domains – physical representation of information  Machine domain – where you will build the solution Identify the interfaces – shared phenomena Capture relations in a context diagram  Show all domains, including machine  Draw one line among domains for each set of shared phenomena  Despite the boxes and lines, this is not the system architecture! Record what the problem is  Requirement is a condition on one or more domains that the machine must bring about  Add to context diagram to get problem diagram

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine5 Domains Machine Domain Causal Domain C Lexical Domain X Biddable Domain 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 Given Domain Designed Domain Given Domain In problem frame diagrams In problem or context diagrams

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine6 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 Given Domain 1 Given Domain 2 a b c d

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine7 Problem diagrams add requirements Requirements are relations that machine must achieve Dashed lines refer to domains involved in requirements Arrow head shows domain is constrained by requirement Machine Domain Given Domain 1 Given Domain 2 a b Requirement

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine8 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.

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine9 One-way traffic problem diagram a: { RPulse 1, GPulse 1, RPulse 2, GPulse 2 } b: { Stop 1, Go 1, Stop 2, Go 2 } Exclamation point shows which domain controls events  a: LC ! { RPulse 1, GPulse 1, RPulse 2, GPulse 2 }  b: LU ! { Stop 1, Go 1, Stop 2, Go 2 } Notice that we carefully distinguish pulses from lights Lights Controller Light units ab Light cycle

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine10 Elementary problem frame A tightly constrained class of idealized problem Examples  Simple behavior / simple control / required behavior  Simple enquiry / simple information answers  Simple information display  Simple workpieces  Commanded behavior (not in papers)  Transformation (not in paper)  others A real problem is projected into frames, not partitioned  Domains appear in multiple frames

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine11 Simple behavior The machine CM controls the phenomena C1 and witnesses feedback C2 to achieve requirements C3. Examples? Control Machine CM ! C1 C3 Required Behavior Controlled Domain C CD ! C2

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine12 Simple information answers Response Machine RM ! C3 C3 Information Relation Real World C RW ! P1 Responses C Enquirer B E4 E ! E4 P2

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine13 Simple information display Display Machine RW ! C3 S4 Display Rules Information Display C DM ! C1 Real World C S2

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine14 Simple workpieces Editing Tool ET ! E2 S3 Operation Effects User B U ! E1 Workpieces X E1 WP ! S3

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine15 Commanded behavior (Variation on simple behavior, with user in the loop) Control Machine OP ! E4 E4 Commanded Behavior Controlled Domain C CM ! C1 CD ! C2 Operator B C3

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine16 Transformation Machine transforms inputs Y1 to outputs Y2 Transform Machine TM ! Y2 Y4 IO Relation Inputs X IN ! Y1 Outputs X Y3

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine17 Package router problem Packages travel down conveyor Package destination barcode scanned on entry to pipes Package slides down switchable pipes Sensor at top and bottom of each pipe segment

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine18 First cut at a problem diagram : simple behavior Does this show the entire problem? Hint: Can we argue that RC satisfies Correct Routing given only the phenomena it sees? Router Controller arrive(p,b) destination(p,d) bin(d,b) Correct Routing Router & Packages RP ! read(p,id) RP ! hit(i) RP ! posn(i,L|R) RC ! flip(i,L|R)

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine19 Missing: Tracking packages at sensors Which packages are at which sensors? Dynamic Modeler Queues R&P Correspondence Layout Model Queues Model Router & Packages

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine20 Missing: Knowing the router layout Which switch settings lead to which bins? Static Modeler Layout-Model Correspondence Layout Informant Layout Model Router Layout

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine21 Missing: Knowing the destination mapping How does a destination string correspond to a bin? Destination Editor Destination Editing Destination Informant Destination Mapping

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine22 Patient monitoring Let’s try a problem together: 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, blood pressure, and skin resistance. The program reads these factors on a periodic basis (specified for each patient) and stores the factors in a database. For each patient, safe ranges for each factor 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.