1 / 22

CSE 503 – Software Engineering Lecture 2: Jackson Problem Frames Rob DeLine 31 Mar 2004

This lecture discusses Michael Jackson's Problem Frames approach, which provides a conceptual language for recognizing familiar and tractable problems in customer requirements. It covers the basic method of identifying domains, capturing relations in a context diagram, and creating problem diagrams to define requirements. Examples are provided to illustrate the application of problem frames in analyzing and solving software development problems.

williamz
Download Presentation

CSE 503 – Software Engineering Lecture 2: Jackson Problem Frames Rob DeLine 31 Mar 2004

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSE 503 – Software Engineering • Lecture 2: Jackson Problem Frames • Rob DeLine • 31 Mar 2004 • Thanks to Mary Shaw of CMU for several slides

  2. Getting from customer needs to design

  3. 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!

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

  5. Causal Domain Lexical Domain Biddable Domain Machine Domain C X B Domains In problem or context diagrams In problem frame diagrams • The system to be built • Behavior might be partial Machine Domain Given Domain • Behaves predictably • But might fail Given Domain • Behaves unpredictably • Often a human user Designed Domain • Data repository • Physical embodiment ignored

  6. Machine Domain 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 Given Domain 1 a c d Given Domain 2 b

  7. Machine Domain 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 Given Domain 1 a Requirement Given Domain 2 b

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

  9. Lights Controller 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 a b Light units Light cycle

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

  11. Controlled Domain Control Machine C Simple behavior • The machine CM controls the phenomena C1 and witnesses feedback C2 to achieve requirements C3. • Examples? C3 CM ! C1 Required Behavior CD ! C2

  12. Real World Responses Enquirer Response Machine C C B Simple information answers P2 RW ! P1 C3 RM ! C3 Information Relation E ! E4 E4

  13. Information Display Real World Display Machine C C Simple information display S2 DM ! C1 Display Rules RW ! C3 S4

  14. User Workpieces Editing Tool B X Simple workpieces E1 U ! E1 Operation Effects ET ! E2 S3 WP ! S3

  15. Controlled Domain Operator Control Machine C B Commanded behavior • (Variation on simple behavior, with user in the loop) CM ! C1 CD ! C2 C3 Commanded Behavior OP ! E4 E4

  16. Inputs Outputs Transform Machine X X Transformation • Machine transforms inputs Y1 to outputs Y2 IN ! Y1 Y3 IO Relation TM ! Y2 Y4

  17. Package router problem Package destination barcode scanned on entry to pipes Packages travel down conveyor Package slides down switchable pipes Sensor at top and bottom of each pipe segment

  18. Router Controller 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 & Packages Correct Routing RP ! read(p,id) RP ! hit(i) RP ! posn(i,L|R) RC ! flip(i,L|R) arrive(p,b) destination(p,d) bin(d,b)

  19. Dynamic Modeler Missing: Tracking packages at sensors • Which packages are at which sensors? Layout Model Router & Packages Queues R&P Correspondence Queues Model

  20. Static Modeler Missing: Knowing the router layout • Which switch settings lead to which bins? Layout Informant Router Layout Layout-Model Correspondence Layout Model

  21. Destination Editor Missing: Knowing the destination mapping • How does a destination string correspond to a bin? Destination Informant Destination Editing Destination Mapping

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

More Related