Interactive Systems Engineering

1. Interactive Systems Engineering Philippe Palanque palanque@irit.fr - http://liihs.irit.fr/palanque Logiciels Interactifs et Interaction Homme-Systèmes Université Paul Sabatier (Toulouse 3) Rio de Janeiro – 18-19 september 2007

2. Structure of the lecture • Introduction and definitions • Development process of Interactive Systems • A simple Formal Description Techniques for IS • Engineering IS • Design Methods for IS • Research agenda

3. Introduction to HCI

4. Interactive Systems Definition

5. Waterfall Development Process

6. Iguaçu Waterfall Dev. Process

7. Requirements Deployment Validation Specification Integration Unitary Tests Coding Preliminary design Detailed design V Development Process McDermid 84

8. Spiral Development Process Evaluate alternatives Identify and solve risks Define objectives alternatives and constraints Risk analysis Risk analysis Risk analysis Operational prototype AR P1 P2 Prototype 3 Planify analysis and life cycle Define mission Planify development detailled design Specification Design Planify integration and tests coding unitary testing Boehm 86 integ ration Develop and verify next product insta llation Plan next phases

9. Star Development Process

10. Design Method for IS • User interfaces is a pluri-disciplinary domain "Science" non exact ~ soft science • User interface design is more • hands on practice • higly related to designers expertise • Than a well structured widely agreed upon design method (with respect to other software entities)

11. Design Process in Practice Information flows are more complex Client Users Requirements specifications Bug reports, Assistance requests Advisors Admistrative Manager Technical Support & Documentation Advices Analyst – Project manager Specifications Doc & user manual Reports Prototypes Programmers Testers Product (Application)

12. Weak points of this process • Too many people involved Main actors to far away (programmers<-> users) => Try to reduce information circulation (téléphone arabe) • More qualified people have no decision power and too little influence on development

13. Iterative Approaches Spiral iteration towards final product Specification Development Testing Use-evaluation

14. "super-iteratives“ approaches Produce iterations at each phase Example: buy a bycicle with X hundread reals Specification Development Testing Use-evaluation

15. Throw-Away Prototyping

16. Incremental Prototyping

17. Low Fidelity Prototyping • Definition of requirements is the main issue • Very simple drawings only showing main problems • Then successive refinements showing more in details • The appearance • The functioning • No disturbing details about the interface • More abstract than a prototype • Continuous interaction with future users • Only involve other stakeholders later on (Graphic designers, domain experts, ergonomics, …) • Take lectures on drawing, painting, graphical design …

18. High-fidelity Prototyping • Convergence towards a final system is the main issue • Reduce the number of iterations • Use of RAD tools (Visual Basic, …) • Inconvenient • Slow iterations (you have to program the prototype) • Hard to find rapidly essential problems because of low level information provided on the prototype • Hard to design something not embedded in the RAD • Advantages • Easy to remember (for the designer) the behavior • Easy to remember (for the designer) the requests for modifications • Cannot test unfeasible things (Wizard of Oz techniques) • Makes it easier the convergence

19. Preliminary needs User's evaluation Prototype &verification Requirements no yes Requirements Maintenance adéquat ? Final System Specification Validation Implementation and test Architecture design Requirements Formal specifications Hi-fidelity prototype Detailed design Unitary tests Software Architecture Coding User Centered Design Process

20. A Theoretical Development Process Abstract Problem Requirements Specification Design Implementation Program Testing Concrete

21. Program A Real Development Process Problem Abstract Requirements Concrete

22. User Centered Design (ISO 13407 Standard) • How to involve the Users throughout the design process? • Embed users in the development team • Periodic involvement • Problems • Inconsistency • In-completeness (taxe acounting system)

23. User-centered systems design in practice

24. Exercise : A Car Interface Design the User Interface of a car simulating its behavior by a computer You’ll have to take into account two types of users: - Pilot (management of real time interactions) • display information (indicators, speed, …) • available actions to the pilot • provide feedback about actions - Navigator – we might need information such as (planning of journey at medium and long term) • Propose a route according to the duration of the journey • Propose a route according to the traffic • Propose a route according to the departure and arrival points • Inter communication vehicles • … • We follow the hypothesis that driving wheel manipulation, pedals, gears remains unchanged with respect to current vehicles Do this exercise by group of 2 people. Each one will endorse one role (either pilot or navigator)

25. Exercise : Airport • You are in an aircraft currently landing • You have a very short connection • You are hungry • Design a system for food selection and distribution making it possible for you to get food as quickly as possible

26. From Design to Construction

27. Design of Interfaces • You have to design the three layers of Seeheim architecture • Presentation part – What the user sees of the interactive system • Dialogue • What the user can do • How the user acts on the presentation • The influence of an action on what he will be able to do later • Functional Core: • Functions implemented in the interactive system • Data manipulated by the system

28. Modèle de Seeheim 83 Functional Core Functional Core Interface Presentation Component Dialog Controler User

29. Abstract rendering Software Architecture Abstract Events Transducers rendering events Concrete rendering

30. Event-Based Functioning of Systems

31. Structure of a Classical Application The application is always waiting for a user input In all the other cases the application is performing calculations and the user is waiting Begin choice = '1'; While choice <> '9' do display-menu; readln(choice); case choice of 1 : add; 2 : modify; 3 : delete; 9 : Quit; End Case End While End Procedure Add; begin rep = 'o'; While rep <> 'n‘ do drawn-screen; read(name); read(firstname); ... writeln(‘do you wan to continue ?'); read(rep) End While End

32. Classical Functionning Read input Read input Process Input Process Input Exit? Exit? End

33. Structure of event driven applications • Main event loop receives user and application events • Event handlers are procedures related to a couple (object, event) and are called from the main event loop when an event is received • Every event handler has the same structure EH1; Precondition; Action; State change; Graphical Rendering End EH1;

34. Data flow Event-based Functioning Register Event Handlers EH Registration Event Queue At startup Call Window Manager Finished Application Get next event Event Handler 1 Dispatch event At runtime Ack received Event Handler 2 States Wait for next event Event Handler n Window Manager

35. State-based Behaviours • Event-handler depending on application’s state • Event-handler depending on system’s state

36. Event processing in MS Windows

37. State Versus Events • 1- Real world evolves in a continuous manner • 2- Variables represent step-based variations • 3- Events can have a periodic appearance (look at your watch for the coffee break every 30 Sec ) • 4- Event arrive and have an impact on state

38. Construction in Java • Event-based functioning (main loop + event handlers) • Event-based programming (event-handlers production) • 3 main elements • Swing components for the UI • Adapters (listeners) • Application

39. JBuilder 2005 Environment Project Code Structure

40. JBuilder 2005 Environment Interface Project Properties of the current component Tool palete Structure UI Builder

41. Runtime

43. Development JBuilder 2005 • Draw the UI using the UI builder • Overload event-handlers • Adapters are automatically created • Write the code • Instanciate the constructor • Run the application

44. A development method • A stepwise approach • An automata-based notation • A development process close to E/R • Going from abstract description to code

45. A development method • 1) List of events • 2) List of actions • 3) Behavioural automaton • 4) State/event Matrix • 5) Event-handlers

46. Advantages • Complete and unambiguous description • Properties analysis • Behavioural • Usability • Code “generation” • It is easier to prove than testing

47. Augmented Automata • An augmented automaton is an automaton which can have • Events triggering actions • Preconditions for triggering actions • Registers (numerical variables) • Perform actions on the registers (assignment) • All the elements appear on the models as shown

48. Augmented Automata (2) Example : a simple system • E = {E1, E2, E3, E4}, s0 = E1 • Ev = {Ev1, Ev2}, • A = {A1, A2, A3, A4}, • f : E x Ev -> A, f(E1,Ev1) = A1, f(E2,Ev1) = f(E3,Ev1) = A2, f(E4,Ev2) = f(E3,Ev2) = A3, f(E2,Ev2) = A4 • g : E x Ev -> E, g(E1,Ev1) = g(E3,Ev2) = E2, g(E2,Ev1) = g(E4,Ev2) = E3, g(E3,Ev1) = E4, g(E2,Ev2) = E1. Ev2 Ev2 Ev2 A4 A3 A3 E4 E1 E3 E2 Ev1 Ev1 Ev1 A1 A2 A2

49. Going from model to code • Build the State/Event Matrix • Extract Event-based behaviour • Produce the event-handlers • Don’t forget • Initialisation • Activation/desactivation of widgets

50. Event-handler code V = {v}, v0 = 1 and v : integer Handler Ev2 is begin Case v of 1 : ‘Forbidden 2 : A4; v:=1; ev1 active; ev2 inactive; 3 : A3; v:=2; ev1 & ev2 active 4 : A3; v:=3; ev1 & ev2 active Endcase EndHandler; Handler Ev1 is begin Case v of 1 : A1; v:=2; ev1 active ev2 active 2 : A2; v:=3; ev1 active ev2 active 3 : A2; v:=4; ev1 inactive ev2 active 4 : ‘Forbidden Endcase EndHandler;