1 / 35

Problem Frames: part 2

Problem Frames: part 2. Frame Concerns Model Domains Variant Domains Particular Concerns Frame Flavors. Concern. If I have this kind of problem frame, I should be concerned about … Commanded behavior Are the commands sensible and viable? Information display

viveka
Télécharger la présentation

Problem Frames: part 2

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. Problem Frames: part 2 Frame Concerns Model Domains Variant Domains Particular Concerns Frame Flavors Problem Frames: Part 2

  2. Concern • If I have this kind of problem frame, I should be concerned about … • Commanded behavior • Are the commands sensible and viable? • Information display • From what we know about the real world, can the machine ensure the display is correct given the limited information it receives? Problem Frames: Part 2

  3. Local Traffic Monitoring Vehicles sensors c a C Monitor Computer Printout - Vehicles Printout b d C a: VS!{SensorOn[i]} b: MC!{WtVehLine, WtTotLine} c: VS!{Bike, Car, Truck} d: SP!{InformationPrinted} Problem Frames: Part 2

  4. Concern • If I have this problem frame, I should be concerned about … • Simple workpieces • Are commands sensible and viable? • You probably get to design commands • Translation • As the machine traverses the inputs and outputs domains simultaneously, it correctly calculates the values to be written to the outputs domain from the values encountered in the inputs domain. Problem Frames: Part 2

  5. Information Display Problem Frame Real world C3 RW!C1 C Information machine Display - Real world Display IM!E2 Y4 C Problem Frames: Part 2

  6. Transformation Problem Frame Inputs Y3 IN!Y1 X Transform machine IO Relation Outputs TM!y2 Y4 X Problem Frames: Part 2

  7. Payroll System • Inputs: Time cards, New employee form, benefit choice, raise, W4 form • Outputs: Pay checks, W1 form, W2 form, check and forms to insurance company Problem Frames: Part 2

  8. Payroll problem diagram fitted to information display frame Payroll forms c a C Requirements for payroll Payroll System Output d b C a: Pf! {time cards, new employee form, benefit choice, raise, W4} C1 b: PS! {paychecks, W1, W2, checks and forms to insurance} E2 c: Pf! {time cards, new employee form, benefit choice, raise, W4} C3 d: O! {paychecks, W1, W2, checks and forms to insurance} Y4 Problem Frames: Part 2

  9. A model • Lets the machine remember phenomena • Lets the machine carry out some calculations incrementally • Can treat defined terms as if they corresponded to separate phenomena • Can treat processes of a conceptual domain as if they were physical entities Problem Frames: Part 2

  10. Real world C3 RW!C1 C Modeling machine Model - Real world Model MM!E5 Y6 X Model Y6 MD!Y7 X Display machine Display - Model Display DM!E2 Y4 C Problem Frames: Part 2

  11. Real world C3 RW!C1 C Payroll input DB - Real world Payroll DB PI!E5 Y6 X Payroll DB Y6 MD!Y7 X Reports machine Reports -DB Reports RM!E2 Y4 C Problem Frames: Part 2

  12. Payroll DB Y6 PD!Y7 X Checkwriting machine Paychecks - DB Paycheck CM!E2 Y4 C Payroll DB Y6 PD!Y7 X W2 machine W2 - DB W2 WM!E2 Y4 C Problem Frames: Part 2

  13. Decomposing Problem • Separate a complex information display problem into a separate model building problem and model display problem. • Model is part of the solution. • Model building problem and model display problem can be decomposed into parallel model building and model display problems. Problem Frames: Part 2

  14. Model Domains are common • Compilers (Transformation) • symbol table, abstract syntax tree • Robotics (controlled behavior) • map, where we are on the map • Commanded behavior, Workpieces • undo, selections Problem Frames: Part 2

  15. Costs of Model Domains • An extra domain • Can be similar to description of real world; which is which? • Many possible models; picking one makes the problem description less general Problem Frames: Part 2

  16. Advantages of Model Domain • Keep track of history • Leads to more efficient machines • Leads to simpler descriptions for requirements and machines • defined terms implemented in one place • conceptual entities defined in one place Problem Frames: Part 2

  17. Other variant frames • Description • Lexical domain that describes a part of the requirement, or part of some other domain. • Operator • Add an operator, like Commanded Behavior adds an operator to Controlled Behavior. • Connection • A domain between the machine and the central domain. Problem Frames: Part 2

  18. One-way lights with Description b a Lights units Conformity to regime Lights controller c d Encoded regime c:ER! (Char) d: ER!(Phase,Duration) a: LC! (RPulse[i], GPulse[i]) b: LU!(Stop[i],Go[i]) Problem Frames: Part 2

  19. Patient Monitoring with Connection Nurses station Periods & ranges c a Monitor machine Medical staff Analog devices ICU patient b e f c: Notify d: RegisterValue f: FactorEvidence a: Period, Range, PatientName, Factor c: EnterPeriod, EnterRange EnterPatentName, EnterFactor Patent monitoring: annotated context diagram Problem Frames: Part 2

  20. Particular Concerns Concerns about a particular problem, not about a particular problem frame. • Overrun • Initialization • Reliability • Identities • Completeness Problem Frames: Part 2

  21. Overrun • A domain’s ability or inability to respond to each externally controlled event before the next event occurs. • Occurs when there is a mismatch of speeds at a domain interface. • Machine too fast • Machine too slow Problem Frames: Part 2

  22. Strategies for slow machines • Simple inhibition - the machine inhibits the shared events whenever it is not ready • Ignoring - the machine ignores shared events whenever it is not ready • Buffering - the machine buffers shared events whenever it is not ready, and participates later Problem Frames: Part 2

  23. Initialization • Machine has initial state • Problem has initial state • only start machine when domain is in proper state • machine sets state of the domain • machine learns state of the domain • Model has initial state Problem Frames: Part 2

  24. Reliability • What happens when problem domain violates its description? • Importance depends on • Likelihood of failure • Cost of failure Problem Frames: Part 2

  25. Reliability Separate problem of normal operation from problem of reliability • Detection • Diagnosis • Repair Problem Frames: Part 2

  26. Identities • Identities concern is when the machine has an interface of shared phenomena with a set of individuals that • are not connected into any structure that identifies them and • do not identify themselves. Problem Frames: Part 2

  27. Identities • Add a structure that identifies individuals • Model • must be initialized • must be maintained Problem Frames: Part 2

  28. Completeness Does the machine do everything it is supposed to? • Does a finite-state machine define what happens for every possible event? • Does the description cover a large enough scope? Problem Frames: Part 2

  29. Increasing Description Scope • Widen participation • X can do Y • What else can it do? • Can anything else do Y? • Complementary events • For each event, can the opposite event happen? Problem Frames: Part 2

  30. Particular Concerns • Probably more • Knowledge of experts • Experience is important Problem Frames: Part 2

  31. Domain Flavors • Static • Physical domains, like maps for a flight simulator • Data structures like trees or graphs Problem Frames: Part 2

  32. Dynamic Flavors • Tolerance • Capacity of a causal domain to tolerate events that do not cause changes in the domain state • Example – “shut the door” to a closed door. • Robust, inhibiting, fragile • Inhibition • Safer to inhibit in a biddable domain than a causal domain Problem Frames: Part 2

  33. Dynamic flavors • Discrete vs. continuous • Active vs. passive state of domain • Passive – domain causes no shared events or shared state changes except in response to an externally caused event • Event-active domain can generate events • State-active domain can cause state changes Problem Frames: Part 2

  34. Formality • Lexical domains are formal • Causal domains are never formal • “Sometimes the informality of a problem domain can be treated quite lightly – the flavor of informality is barely detectable, and you can get away with ignoring it. But sometimes the flavour is quite strong, and you have to be very careful in making descriptions.” Problem Frames: Part 2

  35. Conclusion • Problem frames and problem analysis is important. • We need to be able to separate analysis of problem from analysis of solution. • Much more work to do. Problem Frames: Part 2

More Related