190 likes | 305 Vues
This document explores the integration of model domains within problem frames, focusing on techniques for simplifying complex problems through decomposition. It highlights how to distinguish requirements for model building and result display, enabling clearer specifications. The advantages of utilizing models include improved memory retention, precise question formulation, and the ability to perform incremental calculations. Additionally, it addresses potential model imperfections and presents examples such as payroll systems to illustrate these concepts effectively. Overall, models serve as powerful tools for enhancing information display and solving complex domains. ###
E N D
Adding a “model” domain • Technique for information display problems • A problem frame variant • A way of decomposing a problem into two subproblems • Makes the problem simpler • Describes the machine more accurately
Information Display:problem frame diagram Real world C3 RW!C1 C Information machine Display - Real world Display Y4 IM!E2 C
Information Display with model Real world C3 RW!C1 C Modeling machine Model - Real world Model Y6 MM!E5 X DM!E7 Model Y6 X Display - Model Display machine Display Y4 IM!E2 C
Decomposing • Invent the model • Split requirements into requirements for building the model, and requirements for displaying the results • Make two specifications
Composition • Two requirements should compose to form the original requirements • Except for extra model phenomena • Two specifications should compose to form the original specification • Compositions should be easy, because • One creates model, the other reads it
Why use a model? • Lets machine remember phenomena from the past • Model determines the questions that can be answered • Model indicates memory that is needed • Lets machine carry out some calculations incrementally
Why use a model? • Can model defined terms as if they correspond to separate phenomena • Can model processes of a conceptual domain as if they were physical entities • Can capture and embody inference rules • Can provide surrogates for private phenomena of the modelled domain
Model imperfections • Model makes assumptions • Continuously varying phenomena are modeled by discrete samples • Samples are gathered at different times • Time lag: sample is gathered after event happened
Model Imperfections • Incompleteness: missing samples or values • Value doesn’t exist • Value is unknown • Errors
Example: Experimental voltages • Measure voltages at 32 points in a circuit • Display voltages as columns side by side on the screen • Display average voltage over all the points
More experimental voltages • Display the average voltage of each point since the experiment began • Discrete • Finite number of samples • Time lag • Model: for each point, a count and a total
More experimental voltages • Average over last 5 minutes • Must keep set of samples for 5 minutes • Maximum voltage • Keep maximum for each point
Example: 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
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
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
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
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
Conclusion • Models are useful for information display • Models are probably useful for other problem frames • Models are an example of a problem variant, and an example of decomposing problems and composing specifications