Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Formal 6 – A success story!

18 Aufrufe

Veröffentlicht am

Slides for the Formal Methods in HCI unit of my 2013 online course on HCI
https://hcibook.com/hcicourse/2013/unit/09-formal

a practical story of how formal methods improved productivity, agility and reliability

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Formal 6 – A success story!

  1. 1. formal methods in HCI a success story  
  2. 2. problem context – mid 80s – local authority DP dept transaction processing – vast numbers of users – order processing, pos systems etc. – COBOL! existing programs ... didn’t work
  3. 3. TP physical architecture central server user corporate database terminal other users N.B. web apps. just like this too
  4. 4. what happens user edits form message goes to TP engine passed to application module which processes the message and prepares new screen which is sent to the user .... web server PHP script Java servlet web page
  5. 5. structure of programs if .. if .. if .. if .. if .. if .. if ..
  6. 6. why? program is trying to work out what is happening! standard algorithm – program counter implicit TP, web, event-based GUI – need explicit dialogue state
  7. 7. mixed up state many users – one application module user A starts multi-screen search list application stores value ‘next_record’ user B starts multi-screen search list application overwrites value ‘next_record’ user A selects ‘next screen’ ... ... and gets next screen of B’s search!
  8. 8. state is hard why? in real life state is implicit in standard CS state is implicit too! in transaction processing (+web) state needs to be explicit
  9. 9. solution? flowchart! not of program ... but of dialogue a formal dialogue specification! Delete D1 Please enter employee no.: ____ Delete D3 Name: Alan Dix Dept: Computing delete? (Y/N): _ Please enter Y or N Delete D2 Name: Alan Dix Dept: Computing delete? (Y/N): _ answer? C2 Finish Finish read record C1 delete record C3 other NY
  10. 10. full screen flow chartDelete D1 Please enter employee no.: ____ Delete D3 Name: Alan Dix Dept: Computing delete? (Y/N): _ Please enter Y or N Delete D2 Name: Alan Dix Dept: Computing delete? (Y/N): _ answer? C2 Finish Finish read record C1 delete record C3 other NY
  11. 11. details ... miniature screen sketch Delete D1 Please enter employee no.: ____ Delete D3 Name: Alan Dix Dept: Computing delete? (Y/N): _ Please enter Y or N Delete D2 Name: Alan Dix Dept: Computing delete? (Y/N): _ answer? C2 Finish Finish read record C1 delete record C3 other NY Delete D2 Name: Alan Dix Dept: Computing delete? (Y/N): _
  12. 12. details ... minimal internal details Delete D1 Please enter employee no.: ____ Delete D3 Name: Alan Dix Dept: Computing delete? (Y/N): _ Please enter Y or N Delete D2 Name: Alan Dix Dept: Computing delete? (Y/N): _ answer? C2 Finish Finish read record C1 delete record C3 other NY answer? C2 delete record C3 other NY
  13. 13. and then ... hand transformation to boiler plate code store ‘where next’ for each terminal • in ‘session’ data code starts with big ‘case’ do processing set new ‘where next’ ... send screen
  14. 14. lessons useful – addressed a real problem! communication – mini-pictures and clear flow easy to talk through with client complementary – different paradigm than implementation fast pay back – quicker to produce application (at least 1000%) responsive – rapid turnaround of changes reliability – clear boiler plate code less error-prone quality – easy to establish test cycle maintenance – easy to relate bug/enhancement reports to specification and code
  15. 15.  and now ... lessons about state  
  16. 16. states in web applications (inter alia) persistent (deep) state – the things you are really interested in e.g. an order, images in an album, facebook profile temporary interaction state – part-created or part-edited objects e.g. new cracker setting decoration, joke, etc. placeholder in interaction – current state/mode/location in dialogue pretty clear in database or similar less clear and often confused
  17. 17. where state is stored (a) cookies (b) hidden form variables – <input type=“hidden” name=“sid” value=“A378F9E6B2” /> (c) encoded in URL – http://mysite.com/processapp.jsp?sid= A378F9E6B2 (d) session variables – session/transaction id stored using (a), (b), or (c) (e) database or persistent store – as (d) needs identifier or token
  18. 18. where state is stored (ctd) More client side (especially AJAX apps) ... (e) JavaScript variables – if ( active ) $(‘#main’).show(); (f) HTML5 local storage key–value or sqlite – localStorage.visitcount++; – t.executeSql('SELECT *FROM docs WHERE id=?', [id], function (t, data) {... } (g) hash at end of URL – http://mysite.com/map.html#long=6:53W&lat=56:29N
  19. 19. what goes where? interaction issues: – multiple windows on same app? – privacy and security – ‘back’ button? … and bookmarks danger of ‘resubmitting’ same data implementation issues – ‘garbage collecting’ session data – restarting server often ‘hacked’ not considered lesson – clearly specify the state … and only then map into implementation! why ‘stateless’ often regarded as good … but not necessarly best for interaction!
  20. 20. dialogue too … the way it often is … initial prototype linear A then B then … at most one path for each link/button syuh how gtw hsio i ert ag ty ghn ty we ghty chdi qw oatyf wet dfla ght a <?php $x= … ?> code to produce page A syuh how gtw hsio i ert ag ty ghn ty we ghty chdi qw oatyf wet dfla ght a <?php $y= … ?> code for page B user clicks link DB update and fetch data
  21. 21. … and the way it goes … initial prototype linear but … later add validation if validation fails page B code needs to produce something ‘like’ page A … and it just keeps getting worse syuh how gtw hsio i ert ag ty ghn ty we ghty chdi qw oatyf wet dfla ght a <?php $x= … ?> code to produce page A syuh how gtw hsio i ert ag ty ghn ty we ghty chdi qw oatyf wet dfla ght a <?php if ($y<1) … ?> code for page B DB syuh how gtw hsio i ert ag ty ghn ty we ghty chdi qw oatyf wet dfla ght a page Bpage A
  22. 22. separate dialogue and presentation model dialogue – take into account both user and system branches three kinds of code – gather data for page access database but no updates except logging – format page only code to produce HTML maybe use template engine – post-page process actions validation checks update persistent data choose next page to show syuh how gtw hsio i ert ag ty ghn ty we ghty chdi qw oatyf wet dfla ght a format page A fetch data for page A syuh how gtw hsio i ert ag ty ghn ty we ghty chdi qw oatyf wet dfla ght a format page B process actions from page A update data <?php if $y ?> <?php $x = ?> DB DB <?php $y = ?> decide what comes next view / presentation dialogue & semantics fetch data for page A

×