Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Knowledge Role • goal formulation • operation selection • operation application • goal completion A. Cerone, UNU-IIST – p.9/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Knowledge Role • goal formulation • operation selection • operation application • goal completion Steps are triggered by knowledge availability A. Cerone, UNU-IIST – p.9/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Knowledge Role • goal formulation • operation selection • operation application • goal completion Steps are triggered by knowledge availability knowledge availability = ⇒ recursion: new space problem invoked with goal = find needed knowledge A. Cerone, UNU-IIST – p.9/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs SOAR Executable Cognitive Architecture developped by Allen Newell, John Laird and Paul Rosembloom in 1983 [Newell et a. 87] Used by the University of Michigan http://sitemaker.umich.edu/soar/ A. Cerone, UNU-IIST – p.10/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs PUM Programmable User Models Psychologically Constrained Architecture which an interface designer is invited to program to simulate a user performing a range of tasks with a proposed interface [Young et a. 89] A. Cerone, UNU-IIST – p.11/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs PUM Philosophy The interface designer • must program the PUM respecting the constraints = ⇒ driven interface design = ⇒ explicit “user program” A. Cerone, UNU-IIST – p.12/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs PUM Philosophy The interface designer • must program the PUM respecting the constraints = ⇒ driven interface design = ⇒ explicit “user program” • run the model ( = ⇒ “user program” is executable) to make predictions = ⇒ show source of predictions and strategy options A. Cerone, UNU-IIST – p.12/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs PUM Purposes • Outcome: predictive evaluation to tell the designer usability of a proposed design before it is actually built A. Cerone, UNU-IIST – p.13/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs PUM Purposes • Outcome: predictive evaluation to tell the designer usability of a proposed design before it is actually built • Benefits for the designer: • to draw the designer attention to issues of usability • to provide a way of reasoning about usability A. Cerone, UNU-IIST – p.13/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs PUMA: PUM Applications Research Project aim to • Bring the PUM metodology into industrial design • Using formal methods to effectively implement PUM PUMA Research Group Website: http://www.cs.mdx.ac.uk/puma/ A. Cerone, UNU-IIST – p.14/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Detecting User Errors Work by Curzon and Blandford [Curzon et al. 01]: • PUM defined in the HOL Theorem Prover = ⇒ Generic User Model described by sets of non-deterministic rules A. Cerone, UNU-IIST – p.15/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Detecting User Errors Work by Curzon and Blandford [Curzon et al. 01]: • PUM defined in the HOL Theorem Prover = ⇒ Generic User Model described by sets of non-deterministic rules • Programming performed using SML = ⇒ target the Generic User Model to a particular design A. Cerone, UNU-IIST – p.15/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Detecting User Errors Work by Curzon and Blandford [Curzon et al. 01]: • PUM defined in the HOL Theorem Prover = ⇒ Generic User Model described by sets of non-deterministic rules • Programming performed using SML = ⇒ target the Generic User Model to a particular design • Automated Correctness Proof A. Cerone, UNU-IIST – p.15/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Detecting User Errors Work by Curzon and Blandford [Curzon et al. 01]: • PUM defined in the HOL Theorem Prover = ⇒ Generic User Model described by sets of non-deterministic rules • Programming performed using SML = ⇒ target the Generic User Model to a particular design • Automated Correctness Proof • Informal reasoning to detect errors A. Cerone, UNU-IIST – p.15/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving Well-Formed Formulae A. Cerone, UNU-IIST – p.16/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving false ❍ ❨ ❍ ❍ Well-Formed Formulae ✟ ✟ ✟ ✙ true A. Cerone, UNU-IIST – p.16/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving false ✟ ❍ ❨ ✟ ❍ ✙ ✟ ❍ Class of Models Well-Formed Formulae ❍ ❨ ✟ ❍ ✟ ❍ ✙ ✟ true A. Cerone, UNU-IIST – p.16/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving false ✟ ❍ ❨ ✟ ❍ ✙ ✟ ❍ Class of Models Well-Formed Formulae ❍ ❨ ✟ ❍ ✟ ❍ ✙ ✟ true ∈ System Model A. Cerone, UNU-IIST – p.16/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving false ✟ ❨ ❍ ✟ ❍ ✙ ✟ ❍ Class of Models Well-Formed Formulae ❍ ❨ ✟ ❍ ✟ ❍ ✟ ✙ true ⊆ ∈ System Model Properties A. Cerone, UNU-IIST – p.16/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving false ✟ ❍ ❨ ✟ ❍ ✙ ✟ ❍ Class of Models Well-Formed Formulae ❨ ❍ ✟ ❍ ✟ ❍ ✙ ✟ true ⊆ ∈ ✂ ✂ System Model Properties ✂ ✂ ✂ ✛ ✂ ✂ Axioms A. Cerone, UNU-IIST – p.16/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving false ✟ ❍ ❨ ✟ ❍ ✙ ✟ ❍ Class of Models Well-Formed Formulae ❨ ❍ ✟ ❍ ✟ ❍ ✟ ✙ true ⊆ ∈ ✂ ✂ System Model Properties ✂ ✂ ✂ ✛ ✂ ✂ Axioms ✲ Inference Rules A. Cerone, UNU-IIST – p.16/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving false ✟ ❍ ❨ ✟ ❍ ✙ ✟ ❍ Class of Models Well-Formed Formulae ❍ ❨ ✟ ❍ ✟ ❍ ✟ ✙ true ⊆ ∈ ✂ ✂ System Model Properties ✂ ✂ ✂ ✛ ✂ ✂ Axioms Theorems ✻ ✲ Inference Rules A. Cerone, UNU-IIST – p.16/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving false ✟ ❍ ❨ ✟ ❍ ✙ ✟ ❍ Class of Models Well-Formed Formulae ❍ ❨ ✟ ❍ ✟ ❍ ✙ ✟ true ⊆ ∈ ✂ ✂ System Model Properties ✂ ✂ ✂ ✛ ✂ ✂ Axioms Theorems ✻ ❄ ✲ Inference Rules A. Cerone, UNU-IIST – p.16/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving false ✟ ❍ ❨ ✟ ❍ ✙ ✟ ❍ Class of Models Well-Formed Formulae ❨ ❍ ✟ ❍ ✟ ❍ ✟ ✙ true ⊆ ∈ ✂ ✂ System Model Properties ✂ ✂ ⊆ ✂ ✛ ✂ ✂ Axioms Theorems ✻ ❄ ✲ Inference Rules A. Cerone, UNU-IIST – p.16/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving: Pros & Cons • Advantages A. Cerone, UNU-IIST – p.17/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving: Pros & Cons • Advantages • Maximum Modelling Expressivity A. Cerone, UNU-IIST – p.17/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving: Pros & Cons • Advantages • Maximum Modelling Expressivity • Infinite State Systems A. Cerone, UNU-IIST – p.17/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving: Pros & Cons • Advantages • Maximum Modelling Expressivity • Infinite State Systems • Complex data structure A. Cerone, UNU-IIST – p.17/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving: Pros & Cons • Advantages • Maximum Modelling Expressivity • Infinite State Systems • Complex data structure • Disadvantages A. Cerone, UNU-IIST – p.17/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving: Pros & Cons • Advantages • Maximum Modelling Expressivity • Infinite State Systems • Complex data structure • Disadvantages • Semidecidability A. Cerone, UNU-IIST – p.17/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving: Pros & Cons • Advantages • Maximum Modelling Expressivity • Infinite State Systems • Complex data structure • Disadvantages • Semidecidability • Verification procedure not fully automated A. Cerone, UNU-IIST – p.17/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving: Pros & Cons • Advantages • Maximum Modelling Expressivity • Infinite State Systems • Complex data structure • Disadvantages • Semidecidability • Verification procedure not fully automated • Tools difficult to use A. Cerone, UNU-IIST – p.17/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving: Pros & Cons • Advantages • Maximum Modelling Expressivity • Infinite State Systems • Complex data structure • Disadvantages • Semidecidability • Verification procedure not fully automated • Tools difficult to use • No scalability A. Cerone, UNU-IIST – p.17/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Theorem-proving: Pros & Cons • Advantages • Maximum Modelling Expressivity • Infinite State Systems • Complex data structure • Disadvantages • Semidecidability • Verification procedure not fully automated • Tools difficult to use • No scalability • Does not allow debugging A. Cerone, UNU-IIST – p.17/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Model-Checking: Pros & Cons • Advantages A. Cerone, UNU-IIST – p.18/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Model-Checking: Pros & Cons • Advantages • Decidability A. Cerone, UNU-IIST – p.18/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Model-Checking: Pros & Cons • Advantages • Decidability • May be fully automated A. Cerone, UNU-IIST – p.18/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Model-Checking: Pros & Cons • Advantages • Decidability • May be fully automated • Better usability tools A. Cerone, UNU-IIST – p.18/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Model-Checking: Pros & Cons • Advantages • Decidability • May be fully automated • Better usability tools • Good scalability A. Cerone, UNU-IIST – p.18/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Model-Checking: Pros & Cons • Advantages • Decidability • May be fully automated • Better usability tools • Good scalability • Allows debugging A. Cerone, UNU-IIST – p.18/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Model-Checking: Pros & Cons • Advantages • Decidability • May be fully automated • Better usability tools • Good scalability • Allows debugging • Disadvantages A. Cerone, UNU-IIST – p.18/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Model-Checking: Pros & Cons • Advantages • Decidability • May be fully automated • Better usability tools • Good scalability • Allows debugging • Disadvantages • Limited Expressivity A. Cerone, UNU-IIST – p.18/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Model-Checking: Pros & Cons • Advantages • Decidability • May be fully automated • Better usability tools • Good scalability • Allows debugging • Disadvantages • Limited Expressivity • Finite State Systems A. Cerone, UNU-IIST – p.18/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Model-Checking: Pros & Cons • Advantages • Decidability • May be fully automated • Better usability tools • Good scalability • Allows debugging • Disadvantages • Limited Expressivity • Finite State Systems • Limited data structure A. Cerone, UNU-IIST – p.18/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Sets of Rules to describe • reactive behaviour: user reacts to a stimulus that clearly indicates that a particular action should be taken (independently of the goal) A. Cerone, UNU-IIST – p.19/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Sets of Rules to describe • reactive behaviour: user reacts to a stimulus that clearly indicates that a particular action should be taken (independently of the goal) • communication goals: user knows a task-dependent mental list of information that must be communicated to the device A. Cerone, UNU-IIST – p.19/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Sets of Rules to describe • reactive behaviour: user reacts to a stimulus that clearly indicates that a particular action should be taken (independently of the goal) • communication goals: user knows a task-dependent mental list of information that must be communicated to the device • completion: subsidiary tasks generated in achieving the goal A. Cerone, UNU-IIST – p.19/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Sets of Rules to describe • reactive behaviour: user reacts to a stimulus that clearly indicates that a particular action should be taken (independently of the goal) • communication goals: user knows a task-dependent mental list of information that must be communicated to the device • completion: subsidiary tasks generated in achieving the goal • abort: no rational action is available A. Cerone, UNU-IIST – p.19/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Sets of Rules to describe • reactive behaviour: user reacts to a stimulus that clearly indicates that a particular action should be taken (independently of the goal) • communication goals: user knows a task-dependent mental list of information that must be communicated to the device • completion: subsidiary tasks generated in achieving the goal • abort: no rational action is available nondeterministic rules = ⇒ rule disjunction A. Cerone, UNU-IIST – p.19/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Reactive Behaviour ( stimulus t ) ∧ NEXT reaction t A. Cerone, UNU-IIST – p.20/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Reactive Behaviour ( stimulus t ) ∧ NEXT reaction t NEXT does not require that the action is taken on the next cycle, but rather that it is taken before any other user action A. Cerone, UNU-IIST – p.20/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Reactive Behaviour ( stimulus t ) ∧ NEXT reaction t To target the generic user model to a particular device, it is applied to a concrete list in SML [( stimulus 1 , reaction 1 ) ; ... ; ( stimulus n , reaction n )] A. Cerone, UNU-IIST – p.20/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Reactive Behaviour ( stimulus t ) ∧ NEXT reaction t [( stimulus 1 , reaction 1 ) ; ... ; ( stimulus n , reaction n )] Example: [( light , push button ) ; ( wait msg , pause ) ; ( card msg , take card ) ; ( cash msg , take cash )] A. Cerone, UNU-IIST – p.20/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Reactive Behaviour ( stimulus t ) ∧ NEXT reaction t ✓✏ ✓✏ stimulus ✲ ✲ ✒✑ ✒✑ ✻ ✚ ✙ action [( stimulus 1 , reaction 1 ) ; ... ; ( stimulus n , reaction n )] Example: [( light , push button ) ; ( wait msg , pause ) ; ( card msg , take card ) ; ( cash msg , take cash )] A. Cerone, UNU-IIST – p.20/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Reactive Behaviour ( stimulus t ) ∧ NEXT reaction t ✓✏ ✓✏ stimulus ✲ ✲ R ✒✑ ✒✑ ✻ ✚ ✙ action R 1 = R / f 1 where f 1 ( stimulus ) = light f 1 ( reactions ) = push button [( stimulus 1 , reaction 1 ) ; ... ; ( stimulus n , reaction n )] Example: [( light , push button ) ; ( wait msg , pause ) ; ( card msg , take card ) ; ( cash msg , take cash )] A. Cerone, UNU-IIST – p.20/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Communication Goals ∼ ( goalachieved t ) ∧ ( guard t ) ∧ NEXT action t A. Cerone, UNU-IIST – p.21/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Communication Goals ∼ ( goalachieved t ) ∧ ( guard t ) ∧ NEXT action t Example: [( has card , insert card ) ; ( TRUE , insert pin )] A. Cerone, UNU-IIST – p.21/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Communication Goals ∼ ( goalachieved t ) ∧ ( guard t ) ∧ NEXT action t Example: [( has card , insert card ) ; ( TRUE , insert pin )] Goal: HasGotCash A. Cerone, UNU-IIST – p.21/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Communication Goals ∼ ( goalachieved t ) ∧ ( guard t ) ∧ NEXT action t Example: [( has card , insert card ) ; ( TRUE , insert pin )] Goal: HasGotCash ✓✏ ✓✏ ✓✏ ✓✏ notach cond action ✲ ✲ ✲ ✲ C ✒✑ ✒✑ ✒✑ ✒✑ A. Cerone, UNU-IIST – p.21/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Communication Goals ∼ ( goalachieved t ) ∧ ( guard t ) ∧ NEXT action t Example: [( has card , insert card ) ; ( TRUE , insert pin )] Goal: HasGotCash ✓✏ ✓✏ ✓✏ ✓✏ notach cond action ✲ ✲ ✲ ✲ C ✒✑ ✒✑ ✒✑ ✒✑ ✞ ☎ notach ✓✏ ✓✏ ❄ goal ✲ ✲ G ✒✑ ✒✑ A. Cerone, UNU-IIST – p.21/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Completion if ((( invariant t ) ∧ ( goalachieved t )) ∨ (( finished ( t − 1 )) then action finished t else — disjunction of nondeterministic rules — Invariant: VALUE possession t ≥ VALUE possession 1 ✓✏ ✓✏ ✓✏ ✓✏ notach cond action ✲ ✲ ✲ ✲ C ✒✑ ✒✑ ✒✑ ✒✑ ✞ ☎ notach ✓✏ ✓✏ ❄ goal ✲ ✲ G ✒✑ ✒✑ A. Cerone, UNU-IIST – p.22/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Completion if ((( invariant t ) ∧ ( goalachieved t )) ∨ (( finished ( t − 1 )) then action finished t else — disjunction of nondeterministic rules — Invariant: VALUE possession t ≥ VALUE possession 1 ✓✏ ✓✏ ✓✏ ✓✏ notach cond action ✲ ✲ ✲ ✲ C ✒✑ ✒✑ ✒✑ ✒✑ ✞ ☎ notach ✓✏ ✓✏ ❄ goal ✲ ✲ G ✒✑ ✒✑ finished ✓✏ ❄ ✒✑ A. Cerone, UNU-IIST – p.22/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Completion if ((( invariant t ) ∧ ( goalachieved t )) ∨ (( finished ( t − 1 )) then action finished t else — disjunction of nondeterministic rules — Invariant: VALUE possession t ≥ VALUE possession 1 ✓✏ ✓✏ ✓✏ ✓✏ notach cond action ✲ ✲ ✲ ✲ C ✒✑ ✒✑ ✒✑ ✒✑ ✞ ☎ ✞ ☎ notach invariant ✓✏ ✓✏ ✓✏ ✓✏ ❄ ❄ pert goal ✲ ✲ ✲ ✲ G I ✒✑ ✒✑ ✒✑ ✒✑ ✻ finished finished ✚ ✙ ✓✏ ✓✏ ❄ ❄ restore ✒✑ ✒✑ A. Cerone, UNU-IIST – p.22/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Completion if ((( invariant t ) ∧ ( goalachieved t )) ∨ (( finished ( t − 1 )) then action finished t else — disjunction of nondeterministic rules — Invariant: VALUE possession t ≥ VALUE possession 1 ✓✏ ✓✏ ✓✏ ✓✏ notach cond action ✲ ✲ ✲ ✲ C ✒✑ ✒✑ ✒✑ ✒✑ ✞ ☎ ✞ ☎ notach invariant ✓✏ ✓✏ ✓✏ ✓✏ ❄ ❄ pert goal ✲ ✲ ✲ ✲ G I ✒✑ ✒✑ ✒✑ ✒✑ ✻ finished finished ✚ ✙ ✓✏ ✓✏ ❄ ✞ ✞ ❄ finished finished ✲ ✲ restore ✝ ✝ ✒✑ ✒✑ A. Cerone, UNU-IIST – p.22/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs CSP Architecture ✓✏ ✓✏ ✓✏ ☎ stimulus ✲ ✲ ✲ ✆ finished R ✛ finished ✒✑ ✒✑ ✒✑ ✻ ✚ ✙ action ✞ ☎ finished ✓✏ ✓✏ ✓✏ ✓✏ ✓✏ ❄ notach cond action finished ✲ ✲ ✲ ✲ ✲ C ✒✑ ✒✑ ✒✑ ✒✑ ✒✑ ✞ ☎ ✞ ☎ notach invariant ✓✏ ✓✏ ✓✏ ✓✏ ❄ ❄ pert goal ✲ ✲ ✲ ✲ G I ✒✑ ✒✑ ✒✑ ✒✑ ✻ finished finished ✚ ✙ ✓✏ ✓✏ ❄ ✞ ✞ ❄ finished finished ✲ ✲ restore ✝ ✝ ✒✑ ✒✑ A. Cerone, UNU-IIST – p.23/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs User Model HOL A. Cerone, UNU-IIST – p.24/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs User Model HOL Rule disjunction A. Cerone, UNU-IIST – p.24/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs User Model HOL Rule disjunction CSP A. Cerone, UNU-IIST – p.24/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs User Model HOL Rule disjunction CSP U = R 1 � ... � R m � (( C 1 � G ) | [ { goal , finished } ] | ... ... | [ { goal , finished } ] | ( C n � G )) � I 1 � ... � I s A. Cerone, UNU-IIST – p.24/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs User Model HOL Rule disjunction CSP U = R 1 � ... � R m � (( C 1 � G ) | [ { goal , finished } ] | ... ... | [ { goal , finished } ] | ( C n � G )) � I 1 � ... � I s What’s missing? A. Cerone, UNU-IIST – p.24/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs EXERCISE How to guarantee that all reactive behaviours and communication goals are performed atomically within the user model? A. Cerone, UNU-IIST – p.25/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Formal Verification HOL — Correctness Theorem A. Cerone, UNU-IIST – p.26/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Formal Verification HOL — Correctness Theorem ⊢ ∀ state traces . initial state ∧ device specification ∧ user model ⊃ ∃ t . ( invariant t ) ∧ ( goalachieved t ) A. Cerone, UNU-IIST – p.26/46
Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs Formal Verification HOL — Correctness Theorem ⊢ ∀ state traces . initial state ∧ device specification ∧ user model ⊃ ∃ t . ( invariant t ) ∧ ( goalachieved t ) CSP A. Cerone, UNU-IIST – p.26/46
Recommend
More recommend
