Model-based approaches for the design of safety critical interactive systems Philippe Palanque LIIHS-IRIT University Paul Sabatier Toulouse – France http: //liihs. irit. fr/palanque@irit. fr Rio de Janeiro – 18 -19 september 2007 1
Overview of the lectures l l l l Overview of LIIHS Research Group State of the art in MBA for HCI System modeling Task modeling Design rationale Research Themes and Productions A Roadmap on FM & HCI 2
1 - Overview of LIIHS A bit of History about LIIHS l l Started in 1988 at University Toulouse 1 (law and economics) gathering all the computer scientists at UT 1 In 1993 main research theme is HCI and name changed to LIHS (group size about 15 people) l l l From research on software engineering methodologies From research on notations for modeling activities ~ 20 Ph. Ds 3
1 - Overview of LIIHS Research at LIIHS l Mono-disciplinary research: Human Computer Interaction l l Special point of view: Software Engineering for Human. Computer Interaction l l Computer Scientists, Human Factors, Ergonomics, HCI specialists Usability (methods for design and evaluation of computer systems) Reliability (formal specification, human error assessment, …) Traceability (Design rationale) Special application domain: (safety) critical interactive systems – cost of development much lower than the cost of a failure 4
1 - Overview of LIIHS Safety Critical Interactive Systems l Safety Critical Systems l l l l Software Engineers System centered Reliability Safety requirements (certification) Formal specification Verification / Proof Waterfall model / structured Archaic interaction techniques l Interactive Systems l l l l Usability experts User centered Usability Human factors Task analysis & modeling Evaluation Iterative process / Prototyping Novel Interaction techniques 5
Modeling l Tasks models l l Scenarios l l l Concrete description of users' planned activities Temporal organization of actions (and related information) System models l l Abstract description of users' planned activities (goal) Both structure (object oriented approach) and behavioral description How user's actions change system state How system state (rendering) l Reduces authorized user's actions l Is presented to the user Designing options rationally 6
1 - Overview of LIIHS Research Projects l Current projects l l l Recently completed l l l Re. SIST EU Network of Excellence Project (Resilience for Information Society) (012006/12 -2008) COST NSF EU action MAUSE (Maturing Usability) (01 -2005/12 -2008) INTUITION Project (Multimodal Interfaces military aircrafts) (02 -2003/02 -2006) MISC Project (Multimodal Interfaces for Safety-critical Command Control) (012003/01 -2007) Research Training Network EU ADVISES (11 -2002/ 12 -2006) Capes/ Cofecub SPIDER WEB (07 -2002/07 -2005) Previous relevant projects l l l Do. D Drones Project (Unmanned Aerial Vehicles) (03 -2001/09 -2002) EUD-Net EU Network of Excellence (07 -2002/07 -2002) EVALWEB Project: Building ergonomic web sites by design (1999 -2002) Project CNET SERPICO : Specifications for CORBA Components Engineering (1998 -2001) Esprit Project LTR MEFISTO n° 24963 Modeling Evaluation and Formalizing Interactive Systems using Tasks and Objects (1997 -2001) ERGOVAL (1995) 7
1 - Overview of LIIHS Eval. Web l l 1998 -2002 Ergonomic application web by design Partners : Univ. Louvain la neuve (J. Vanderdonckt) & INRIA (D. Scapin) Funding : CNRS GIS Cogniscience (1999) 8
MEFISTO (overview) l l Modeling, Evaluating and Formalizing Interactive Systems using Tasks and interaction Objects ESPRIT Reactive LTR 24963 Project (EC) Air Traffic Control domain Multi disciplinary team l l Computer Scientists (F. Paterno CNUCE, LIIHS) Psychologists (P. Wright Univ. York, P. Marti Univ. Sienna) Industrial partners (DERA UK, CENA F, Alenia I) Users (ENAV I ATC association) 9
1 - Overview of LIIHS UAV Project (1/2) 10
1 - Overview of LIIHS UAV Project (2/2) l l Design, implementation and evaluation of user interfaces for drones command control Performance and user capabilities Authority sharing From several controllers per drone to one controller for several drones 11
1 - Overview of LIIHS MISC Project l l l Multimodal Interaction for Command Control of Safety critical Systems Starting: beginning 01/2003 Finances: DGA (French Department of Defense , CNES (National center for spatial studies), and LIIHS 12
1 - Overview of LIIHS Project SPIDER WEB l l l Specification and Prototyping for user Interface Design, Engineering and Re-engineering for the Web France- Brazil cooperation Partners LIIHS and Instituto de Informatica (Porto Alegre) Beginning Feb. 2002 In conjunction with a CNPq funding of Marco Winckler Ph. D about "model-based approaches for wed application evaluation" COFECUB 13
ADVISES: Analysis Design and Validation of Interactive Safety-critical and Error-tolerant Systems l l Type de projet: Research Training Network Sponsors: EU (Fifth Framework Improving Human Potential Programme) 8 sites : Delft University of Technology (NL), ISTI-CNR(I), Risø National Laboratory (DK), Université de Liège (B), Université Paul Sabatier Toulouse (F), University of Glasgow (UK), University of York (UK), Universität Paderborn (D) Objectifs l l Durée (4 ans): Étudier et développer des méthodes outils et techniques pour l'analyse, la conception et la validation de systèmes interactifs fiables et tolérants aux erreurs humaines Principes l Oct. 02 Oct. 06 Budget LIIHS: l 160 K€ HT l Approche pluridisciplinaire intégrant des spécialistes facteurs humains (ergonomie cognitive, psychologie du travail) des spécialistes informatiques (génie logiciel, méthodes formelles, approches à objets et distribuées) des spécialistes en interaction homme-machine (méthodes de conception centrée utilisateur) et des spécialistes en systèmes critiques (analyse d'incidents/accidents, systèmes embarqués civil et militaires, nucléaire) Formation à la recherche et par la recherche Formation des jeunes chercheurs dans ces domaine par la mobilité au sein du réseau 14
1 - Overview of LIIHS EUD-Net l l l The EUD-NET Network of Excellence is financed by European Community and started in July, 1 st 2002. Goal: help the European Commission to prepare a research agenda in the end-user development field Related to previous work on notations and tools for visual programming 15
Project INTUITION l l Financed by Do. D. THALES avionic in charge. LIIHS team 240 K€ HT. Start January 2003. 3 years Definition and construction of a platform for the design, specification and development of multimodal interactive systems Application domains: l l Rafale Cockpit Air Traffic Control multimodal Interfaces 16
Cockpit Rafale Visu tête haute Ecran tactile Joystick 17
MAUSE: Towards the MAturation of http: //www. cost 294. org/ l l Information Technology USability Evaluation Type de projet: action COST Sponsors: ESF (European Science Foundation) et COST (European Cooperation in the field of Scientific and Technical research) http: //www. esf. org/ l 19 pays UE: (AT, BE, CY, CZ, DK, FI, FR, DE, GR, IS, NL, NO, PL, RO, SI, ES, SE, CH and UK) l http: //cost. cordis. lu/ Durée (4 ans): Déc. 04 Nov. 08 Objectifs l l Activités l l l Budget: Défini en fonctions des missions et des activités des participants Étudier, développer, évaluer et comparer les Méthodes d’Evaluation de l’Utilisabilité (MEU)s l l l WG 1: Révision et Analyse de (MEU)s WG 2: Comparaison de (MEU)s: Stratégies et Implémentation WG 3: Validation de Schèmes de Classification de Problèmes d’utilisabilité WG 4: Révision des approches assistées par l’ordinateurs pour l’évaluation de l’utilisabilité (SIG): E-Learning Dissémination de résultats (Coordination): LIIHS-IRIT, P. Palanque, M. Winckler 18
1 - Overview of LIIHS Re. SIST l l http: //www. resist-noe. eu/ Resilience l l l Diversity Usability Evolvability Assessability Dependability+Safety+Security+Usability Duration 3 years 19
1 - Overview of LIIHS Members of LIIHS working in that field David NAVARRE Lecturer Marco WINCKLER Lecturer Christelle FARENC Lecturer Joseph Xiong Ph. D Student 4 th year Regina BERNHAUPT Visiting Professor Philippe PALANQUE Professor Florence Pontico Ph. D Student 4 th year Sandra BASNYAT Post Doc Jean-François LADRY Ph. D Student 1 st year Eric BARBONI Post Doc 20
Outline of the presentation l l Overview of LIIHS Research Group State of the art in MBA for HCI l l l l l Specificities of Interactive System What is modeling? What kind of modelling in HCI? What has still to be done? System modelling Task modelling Design rationale Research Themes and Productions A Roadmap on FM & HCI 21
2 – State of the art Interactive Systems 22
2 – State of the art "Classical" Design Process SS Informal requirements Specification Manual Spec 1. . . Spec n Design 1. . . Design n Coding Prog. 1. . . Prog. n User testing 23
2 – State of the art What is a "Model" ? l l Concepts relationships between concepts Example : Entity Relationship Model l Concepts : Entity types, Relationship Types, Attributes, Domain of Values, Identifiers, . . . Relationships between concepts : "A Relationship type is a sub set of the Cartesian product of two Entity Type" An entity e 1 cannot have more than one relationship with another entity e 2 through the same relationship type e 1 x e 2 x e 3 x x f 1 x f 2 x f 3 24
2 – State of the art What can we Expect from a Model ? l l l Completeness (we can express all the information we need to) Consistency (Contradictory elements cannot be expressed) Generality (Independent from a given application domain … always ? ) 25
2 – State of the art What is a "formalism" ? l A set of conventions for representing the concepts of a Model l Lexical elements (graphical or textual) Concrete Syntax (separators, terminators, . . . ) A formal definition of these conventions (otherwise just a notation) Flat 1, 1 Owns 0, n Person 26
2 – State of the art What can we expect from a "formalism" ? Flat 1, 1 Owns 0, n l l l Person Expressiveness 0, 1 0, n Rents Conciseness Closeness of the representation to the application domain Completeness wrt the Model (counter example : Graphical formalism of the Entity Relationship Model) L. Lamport "the only difficult problem the author solved was understanding his own notation" L. Lamport "Automaton is a formal description technique dedicated to the specification of stacks" 27
2 – State of the art Bug : With a "Formalism" we build "models" Modelling l l l model: ideal representation of a given situation form the real world restrained to the concepts covered by the Model Goal: analyze the model to draw conclusions about the actual state of the real world Meta-model: model representing the concepts of the Model using the formalism (done for E/R and UML using class diagrams) 28
2 – State of the art What and why modeling systems? l An abstract description of the system l l independent from the implementation that do not deal too early with details Describe what are the outputs of the system according to the inputs To allow discussions between the various actors (at a time, along the design process) l to store results of discussions 29
2 – State of the art What is a system model for Interactive Systems ? l l Represents the system data and actions Represents behaviour of the system l l what actions are offered by the system when an action is available (according to the state of the system) what is the effect of an action on the state of the system Represents both how the system is presented to the user and how the user interacts with it 30
2 – State of the art Design process for IS ? Manual Informal requirements Spec 1. . . Spec n Goal 1. . . Goal n User requirements Design 1. . . Design n Task 1. . . Task n Task Analysis Coding Prog. 1. . . Prog. n Specification User testing 31
2 – State of the art Why Modelling Interactive Systems Formally ? l l l To cope with the complexity To avoid a human observer (checking models) To avoid a human translator (writing code) To reason (verification, validation) To meet three basic requirements l l l Reliability: generic and specific properties Efficiency : performance of the system, the user (workload, …) and the couple (user, system) tasks Usability 32
2 – State of the art Design process using FM Automatic Informal requirements Specification Design Coding Progr. Gener. Spec 1. . . Spec n Design 1. . . Design n Prog. 1. . . Prog. n Manual Verification Validation Verification Generic properties Informal validation 33
2 – State of the art The design process of models 34
2 – State of the art Examples of models (requirements) l A need for a declarative formalism. Requirements l Every clearance sent by a controler to a plane p is received by this plane " p Planes, " req DLRequest, AG[send(req, p)]AF<receive(req, p)>true l A data-link clearance sent by a controler to a plane p will only be received by that plane " p, p' Planes, " req DLRequest, AG[send(req, p)]AG[not(receive(req, p')]true 35
2 – State of the art Temporal Logic CTL * (Computational Tree Logic Star) l A state has one or mode successors l The set of possible states is infinite l Operators: l A (all the possible future); E (one possible future) + {F eventually, G always, X next, U until} l Logical connectors : l (and); (or); (not); (implies) 36
2 – State of the art Temporal Logic CTL * si si |= AGp si |= AFp si si |= EGp si |= EFp p formula is true if the system is in red state false otherwise 37
2 – State of the art Temporal Logic CTL * si si si |= AXp si si |= EXp si si |= A(p U q) si |= E(p U q) 38
2 – State of the art Relating tasks and system Maintain task and system models consistency Preliminary system model Formal system modelling i th Formal task modelling i iteration th Preliminary task model iteration Quantitative analysis Proposals for improving the system model Not Ok Check Objectives Ok Towards Usability Testing 39
2 – State of the art Proving compatibility of models l l All the objects in the tasks model are part of the data model of the system model All the actions in the tasks model are offered by the system model All the actions in the system model exist in the tasks models All the sequences of actions in the tasks model are "legal" in the system model 40
2 – State of the art Fundamental elements formal methods for IS l l l Describe both state and events Describe both data structure and control structure Provide structuring mechanisms (80% of the code is dedicated to UI Myers 90) Take into account concurrency (multimodal systems) Deals with temporal aspects (temporal windows) Do it formally (it is easier to prove than to test) 41
2 – State of the art State versus Events (Dix 91) l l Reactive systems Event driven Slicing of code into event handlers require explicit state representations Approaches l l l Approaches coming from Reactive Systems Reactive or synchronous languages (esterel, Lotos) Methodological use of Petri nets 42
2 – State of the art Data Structure / Control Structure l l Software crisis has shown limitations of separation (maintainability, modifiability, reusability, . . . ) Approaches l l Mix two dedicated approaches (CSP-Z, Object. Z, …) Integrate two approaches (Full LOTOS, Petri nets with objects) 43
2 – State of the art Structuring Mechanisms l l l Handling of complex components Understandability of models Reusability Modifiability Approaches l l l composition (aggregation, association, …) communication (client-server, actors) macros and plugs 44
2 – State of the art Concurrence l l Concurrency between input and output devices (+ multimodality) Groupware Multi threaded dialogues Approaches l l l Textual formalisms (CSP, CCS, LOTOS, Temporal Logic) Graphical formalisms (Petri nets, Statecharts) Only Petri nets feature full concurrency semantics 45
2 – State of the art Temporal Aspects l Multimodal systems Animation (time based evolution) Alarms Calendar events l Approaches l l l Procedural (Petri nets, Lotos, . . . ) Declarative (Temporal Logics, . . . ) 46
2 – State of the art Formal Aspects l l l Easier to prove than to test Critical Systems Completeness, concision et non-ambiguity Executability Approaches l l l Mathematical validation Test case generation Automatic code generation 47
A Small Example/Exercise l l Model of a Mouse behaviour (one button, no wheel) Model of the interaction technique l l l Click Double click Extensions l l l Several buttons Behaviour of the wheel Several mice 48
2 – State of the art A Small Example l Requirement: l Whatever state the system is in, Move is always available 49
2 – State of the art A Small Example 50
2 – State of the art A Small Example Adding Time 51
2 – State of the art A Small Example Taking Movements into account 52
2 – State of the art State of the Art in FM for HCI l Understanding interactive systems l l What is an IS ? What are the generic properties of IS ? Specific properties of IS ? Engineering interactive systems l l l What are the components of IS ? How to model components and their relationships ? Relationships with design process ? 53
2 – State of the art Understanding IS l Generic architectures for IS l l l Generic properties for IS l l l PIE and red-PIE models (Dix 91) Seeheim (Green 85) and Arch/Slinky (Bass 92) (Sufrin & He 90), (Dix 91) External and internal prop. (Gram & Cockton 96) Between understanding and engineering l l CNUCE interactors (Paternò & Faconti 92) York interactors (Duke & Harrison 93) 54
2 – State of the art Engineering IS l Dialogue modelling WIMP l l l Model-Based UIMS (WIMP) (CADUI'96) l l l (Bastide & Palanque 90) (Beck et al. 95) UIDE (Foley et al. 93) Tadeus (Elwert & Schlungbaum 95) Pet. Shop (Bastide & Palanque 95) TRIDENT (Vanderdonckt 95) Design Patterns: PAC (Coutaz 87) & MVC Model-Driven Interactive Systems Engineering (Vanderdonckt 2002, Paterno 2004) targeting at multiplatform UI (One model many interfaces) Paterno 98 55
2 – State of the art Generic properties l Generic properties for Software Systems l l Liveness Safety Ability to wear Generic properties for Interactive Systems l l l Predictability Observability Reachability Insistence Honesty, … 56
2 – State of the art Verification of properties l Observability : l l Insistence: l l the system makes all relevant information potentially available to the user the dialogue structure ensures that necessary information is perceived Predictibility: l users can predict future states and system response time from current and prior observable states 57
2 – State of the art References (books) l l l Formal Methods in HCI, Harrison & Thimbleby 90, Cambridge University Press Formal Methods for Interactive Systems, Dix 91, Cambridge University Press Formal Methods in HCI, Palanque & Paterno 97, Springer Verlag 58
2 – State of the art References (conferences) l l l l l Eurographics workshops DSV-IS (Design, Specification and Verification of Interactive Systems) since 94 published by Springer Verlag (LNCS) CHI 96 workshop on Formal Methods and HCI CHI 98 workshop on designing user interfaces for safety critical systems CHI 05 SIG on Safety Critical Interaction CHI 07 SIG Beyond Usability for Safety Critical System HCI Aero 2000 SUCA (Safety and Usability concerns in Aeronautics) Mini-track of World Congress on FM 99 FMIS workshop series (Formal Methods for Interactive Systems) MDAUI workshop series at MODELS conference (formerly UML conference) 59
2 – State of the art References (journals) l No dedicated journal l Software engineering journals HCI journals Some "special issues" l l l Interacting with Computers vol 9, n° 3, 1997 Journal of Visual Language and Computing (vol 10, n° 3, 1999) ACM Transactions on Computer Human Interaction (2001) 60
Research Work carried out at LIIHS 61
Outline of the presentation l l l Overview of LIIHS Research Group State of the art in FM for HCI Research Themes and Productions l l l Formalisms and tools Demos A Roadmap on FM & HCI 62
3 – Research results Main Results Relevant to FM in HCI l l Vilage (work with S. Chatty at CENA) l A notation: Whizz l A case tool: Whizz'ed Spider. Web (work with Marco Winckler) l A notation: State. Web. Charts l A tool: SWC Environment Pet. Shop l A formal notation: ICOs l A case tool: Pet. Shop User-centered design methods l Linking tasks, scenarios, system and user models l Design rationale (lecture on that topic on Wednesday morning) 63
3 – Research results VILAGE (1) l l l Initially developed for Air Traffic Controllers Interactive prototyping of highly interactive applications (post-WIMP) Build and test prototypes in a modeless way 64
3 – Research results VILAGE (2) l l A data flow model A set of basic building bricks Strongly typed connection Event listeners POINT Tempo Trajectoire Segment 65
3 – Research results VILAGE (3) Tool Palete Dialogue Zone Editing Zone Simulation Zone 66
3 – Research results Overview of the Interactive Cooperative Objects (1) l Petri nets with objects l l l Specific aspects for Interactive Systems l l l Petri nets inside objects Objects inside Petri nets for dynamic aspects Objects for structuring Activation Rendering Tool support l Editing, Execution, Analysis, Prototyping 67
3 – Research results Overview of the Interactive Cooperative Objects (2) l l Set of cooperating classes For each class l l Behaviour (places and transitions) in the Petri net Software Services (availability) States (distribution AND value of tokens) Presentation l Rendering function l Activation function l User services 68
3 – Research results Verification l What ? l l l Safety “nothing bad will ever happen” Liveness “something good will eventually happen” "Smooth functioning" "good cooperation between Models" Efficiency (both local and global) How ? l l l Based on Petri nets theory (the basic brick of our system modelling technique) Cross execution of models Performance evaluation techniques 69
3 – Research results Pet. Shop Fundamental Principles l Highly interactive tool support for the ICO notation l l “Shortening the Path from Specification to Prototype” l l Formal methods can be usable (and useful beyond n! calculation) … to practically nothing Model-Based l l The specification model is embedded and interpreted at run -time WYMIWYR (what you model is what you run) to reduce gaps in interpretation (Norman's model) No “Modes” : no “automation surprises” l The model is editable and interpretable at any time l Allows for interactive prototyping of new interaction scenarios 70
3 – Research results Pet. Shop Architecture 71
Widget Event Service Place Type Planes Plane Labe. Click user. Assumed. Pl anes Plane Button. Click user. Open. Menu 1)Presentation 2)Behaviour Ob. CS Element Feature Rendering method Place Planes token <p> entered p. show() 3)Activation 4)Rendering 72
3 – Research results Requirements A voice request sent to a plane p is received by all the planes in the sector " p Planes, " req VRequest, send (p, req) " p' Planes, receive (p', req) l It is not possible to build several orders at a time " p Planes, " req, req' DLRequest, AF[start_send(req, p)]A[True{not(start_send(req', p)}U(end _send(req, p)}true] l 73
A demonstration ? 74
3 – Research results ATM in France l Systems currently used l l A radar screen A board of paper strips Limited interaction with the radar screen (zoom) Few systems - a lot of prototypes
3 – Research results ATM 76
3 – Research results An Air Traffic Management Case Study: Current System l VHF communication l l all the pilots listen to all the communications limited bandwidth low quality Manual stripping l l the controller has to write down by hand all the information given to pilots only a note pad an aide memoire
Envisioned ATM System
A demonstration ! 79
User Centered Design Methods Preliminary needs Prototype User's evaluation & verification no yes adéquat ? Requirements Maintenance Final System Specification Requirements Formal specifications Hi-fidelity prototype Software Architecture Validation Implementation and test Architecture design Detailed design Unitary tests Coding 80
3 – Research results User Centered Design Methods Pet. Shop CTTE High-fidelity prototyping Task model Ma ppi ng A demonstration ? Formal Scenario Input Description of the System 81
3 – Research results Routine Scenario l l l Several aircrafts in my sector I assume two of them I have to transfer both of them 2 slips then first aircraft transferred Second plane directly transferred 82
3 – Research results A small case study : a timer controlled light switch l The system l l User’s goal l use of a timer controlled switch (30 sec period) very simple hardware based (but same as screen saver) maintain the light on 3 minuts don’t press the button more than necessary Two iterations on the life cycle 83
3 – Research results Task model l What ? l l l both activity and planned tasks based on the notion of goal several task models for a given goal sequence of user’s actions on the system How ? l l temporal relationships in Petri nets invocation of actions offered by the system 84
3 – Research results User Model l l Only basic user Models (human processor) Possibility to describe user learning Cooperation and/or merging with tasks and system models Currently working on higher level user models (ICS) 85
3 – Research results Initial System the light bulb l the timer Press. Switch l not possible to reach the goal l Light. Off Auto. Switch. Off Light. On [30] Press. Switch 86
3 – Research results First Improvement Add a stop-watch l Require hand eyes l Watch. Off Press Watch. On Current. Time <t> 87
3 – Research results The Task model Goal reachable l Really complex for the user t > 25 T 1 Ready. To Stop. Watch P 1 l Watch. Press Count. Down P 2 P 3 <t> Ready. To Start. Watch. Press T 3 Light. Press. Switch Light Started Current. Time P 5 Ready. To Start. Light P 6 Start. Counting <t> T 7 t : = Watch. Current. Time <t> T 4 P 7 t <= 25 T 5 P 4 Watch Started <t> T 2 T 6 <0> Ready. To Read. Time P 8 88
3 – Research results Second Improvement l l Add a bell Remove stop watch Light. Off Press. Switch Auto. Switch. Off [5] Auto. Beep Light. On, Beeping [25] Light. On Press. Switch 89
3 – Research results The Task model l l Less complex Less pooling Start/ Elapsed Count. Down Light. Press. Switch Hear beep Waitting 90
3 – Research results User model l The perceptual system l l l The motor system l l l boundary with the environment eye : between 50 and 200 ms (average 100 ms) physical mouvement hand : between 30 and 100 ms (average 70 ms) The cognitive sytem l l interface between motor and perceptual brain : between 25 and 125 ms (average 70 ms) 91
3 – Research results Performance Evaluation of the first System (0, n, 1, 1, 0, 0) T 3 / n>=1 n=n-1 T 4 (0, n, 0, 1, 0, 0) l l l based on marking graph of the Petri net based on the previous user model Initial state n=7 (0, n, 1, 0, 0, 0, 1, 0) T 3 / n>=1 n=n-1 T 4 (0, n, 0, 0, 0, 1, 1, 0) T 6 (0, n, 0, 0, 0, 1) T 7 T 5 (0, n, 0, 0, 1, 0, 0, 0) T 1 (1, n, 1, 0, 0, 0) T 3 / n>=1 n=n-1 T 2 (0, n, 1, 1, 0, 0) T 3 / n>=1 n=n-1 T 4 (0, n, 1, 0, 0, 0, 1, 0) (1, n, 0, 0, 0, 1, 0, 0) T 3 / n>=1 n=n-1 (0, n, 0, 1, 0, 0) T 2 T 4 92
3 – Research results Performance Evaluation of the first System (2) T 1 Cognitive Comparison of values T 2 Motor Press button (Stop Watch) T 3 Motor Press button (Light) T 4 Motor Press button (Stop Watch) T 5 Cognitive Comparison of values T 6 - Nothing T 7 Perceptual Look at the Stop Watch 93
3 – Research results Performance Evaluation of the second System(1) T 1 Motor Press button (Stop Watch) T 2 Perceptual Hear the beep 94
3 – Research results Results l First upgrade l l Min Time (Goal) = 7*165 + 60 = 1205 ms Mean Time(Goal) = 7*380 + 140= 2800 ms Max Time(Goal) = 7*625 + 200 = 4575 ms Second upgrade l l l Min Time (Goal) = (8*30) +(7*50) = 590 ms Mean Time(Goal) = (8*70) + (7*100) = 1260 ms Max Time(Goal) = (8*200) + (7*100) = 2300 ms 95
Roadmap on Formal Methods in HCI All Applications The Invisible UI 2020 No more programming ? No more bugs ? 2010 Command Control Systems Web Applications Business Applications UML, E/R, … B (Atelier B), Z, … Notations and tools WIMP No Interaction Technique 2007 Y DA Target Applications, Domains Tangible User • Full concurrency Interface • Dynamic instantiation • Hardware/Software Augmented Reality • Infinite number of states Multimodal • Tool support Interaction • Advanced Analysis Direct techniques Manipulation TO Automated autonomous Real. Time Systems (VAL, TCAS) Embodied UI User Interface Interaction Technique 96
Скачать презентацию Model-based approaches for the design of safety critical
712d1f8261f0ef2d310944e7f8b1b5ce.ppt