Formal Methods for Interactive Systems Part 8 Cognitive - - PowerPoint PPT Presentation

▶
formal methods for interactive systems
SMART_READER_LITE
LIVE PREVIEW

Formal Methods for Interactive Systems Part 8 Cognitive - - PowerPoint PPT Presentation

Sep 16, 2023 48 likes •1.42k views

Formal Methods for Interactive Systems Part 8 Cognitive Architectures Antonio Cerone United Nations University International Institute for Software Technology Macau SAR China email: antonio@iist.unu.edu web: www.iist.unu.edu A. Cerone,

slide-1
SLIDE 1

Formal Methods for Interactive Systems

Part 8 — Cognitive Architectures Antonio Cerone United Nations University International Institute for Software Technology Macau SAR China email: antonio@iist.unu.edu web: www.iist.unu.edu

  • A. Cerone, UNU-IIST – p.1/46
slide-2
SLIDE 2

Cognitive Models

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • f the user
  • A. Cerone, UNU-IIST – p.2/46
slide-3
SLIDE 3

Cognitive Models

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • f the user
  • competence models represent expected

behaviour

  • A. Cerone, UNU-IIST – p.2/46
slide-4
SLIDE 4

Cognitive Models

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • f the user
  • competence models represent expected

behaviour

  • performance models represent and analyse

routine behaviour

  • A. Cerone, UNU-IIST – p.2/46
slide-5
SLIDE 5

Cognitive Models

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • f the user
  • competence models represent expected

behaviour

  • performance models represent and analyse

routine behaviour deal with three different levels:

  • goal and task hierarchies: GOMS, Cognitive

Complexity Theory (CCT)

  • A. Cerone, UNU-IIST – p.2/46
slide-6
SLIDE 6

Cognitive Models

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • f the user
  • competence models represent expected

behaviour

  • performance models represent and analyse

routine behaviour deal with three different levels:

  • goal and task hierarchies: GOMS, Cognitive

Complexity Theory (CCT)

  • human understanding: BNF, Task-action

Grammar (TAG)

  • A. Cerone, UNU-IIST – p.2/46
slide-7
SLIDE 7

Cognitive Models

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • f the user
  • competence models represent expected

behaviour

  • performance models represent and analyse

routine behaviour deal with three different levels:

  • goal and task hierarchies: GOMS, Cognitive

Complexity Theory (CCT)

  • human understanding: BNF, Task-action

Grammar (TAG)

  • physical/device: Keystroke-level Model (KLM)
  • A. Cerone, UNU-IIST – p.2/46
slide-8
SLIDE 8

Architectural Aspects

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Cognitive models incorporate implicit and explicit models of cognitive processing

  • A. Cerone, UNU-IIST – p.3/46
slide-9
SLIDE 9

Architectural Aspects

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Cognitive models incorporate implicit and explicit models of cognitive processing

  • GOMS: divide and conquer using subgoals
  • CCT: production rules in LTM matched agains

STM contents

  • KLM: motor and mental operators based on

Model Human processor

  • A. Cerone, UNU-IIST – p.3/46
slide-10
SLIDE 10

Architectural Aspects

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Cognitive models incorporate implicit and explicit models of cognitive processing

  • GOMS: divide and conquer using subgoals
  • CCT: production rules in LTM matched agains

STM contents

  • KLM: motor and mental operators based on

Model Human processor are Architectural Aspects = ⇒ aim to some performance analysis

  • A. Cerone, UNU-IIST – p.3/46
slide-11
SLIDE 11

Architectural Aspects

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Cognitive models incorporate implicit and explicit models of cognitive processing

  • GOMS: divide and conquer using subgoals
  • CCT: production rules in LTM matched agains

STM contents

  • KLM: motor and mental operators based on

Model Human processor are Architectural Aspects = ⇒ aim to some performance analysis but seldom deals with user observation and per- ception = ⇒ mainly competence models

  • A. Cerone, UNU-IIST – p.3/46
slide-12
SLIDE 12

Error Detection

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Weakness of cognitive models: errors must be explicitly defined in the model = ⇒ no error detection

  • A. Cerone, UNU-IIST – p.4/46
slide-13
SLIDE 13

Error Detection

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Weakness of cognitive models: errors must be explicitly defined in the model = ⇒ no error detection ATC Example: failure decomposition was given rather than detected

  • A. Cerone, UNU-IIST – p.4/46
slide-14
SLIDE 14

Error Detection

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Weakness of cognitive models: errors must be explicitly defined in the model = ⇒ no error detection ATC Example: failure decomposition was given rather than detected Users behave rationally = ⇒ make persistent errors

  • A. Cerone, UNU-IIST – p.4/46
slide-15
SLIDE 15

Rational Behaviour

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

based on Rational Behaviour behaviour that is intended to achieve a specific goal in AI: Knowledge-level System = Agent behaves in Environment

  • A. Cerone, UNU-IIST – p.5/46
slide-16
SLIDE 16

Rational Behaviour

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

based on Rational Behaviour behaviour that is intended to achieve a specific goal in AI: Knowledge-level System = Agent behaves in Environment in contrast with Computational Behaviour behaviour defined by an algorithm without an explicit goal

  • A. Cerone, UNU-IIST – p.5/46
slide-17
SLIDE 17

Computational Architectures

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • algorithm describes the problem solution
  • A. Cerone, UNU-IIST – p.6/46
slide-18
SLIDE 18

Computational Architectures

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • algorithm describes the problem solution
  • =

⇒ represented in a programming language

  • A. Cerone, UNU-IIST – p.6/46
slide-19
SLIDE 19

Computational Architectures

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • algorithm describes the problem solution
  • =

⇒ represented in a programming language

  • compilation =

⇒ problem space + actions to traverse represented in the machine architecture

  • A. Cerone, UNU-IIST – p.6/46
slide-20
SLIDE 20

Computational Architectures

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • algorithm describes the problem solution
  • =

⇒ represented in a programming language

  • compilation =

⇒ problem space + actions to traverse represented in the machine architecture

  • execution terminates once a desired state

reached

  • A. Cerone, UNU-IIST – p.6/46
slide-21
SLIDE 21

Computational Architectures

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • algorithm describes the problem solution
  • =

⇒ represented in a programming language

  • compilation =

⇒ problem space + actions to traverse represented in the machine architecture

  • execution terminates once a desired state

reached Machine does not formulate the problem space (the goal is not programmed)

  • A. Cerone, UNU-IIST – p.6/46
slide-22
SLIDE 22

Cognitive Architectures

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • goal to achieve
  • =

⇒ represented as a set of goal states

  • rational behaviour =

⇒ to select appropriate

  • perators to generate new states starting form

the initial state

  • goal achieved once a goal state is reached

based on problem space theory, developed by Newell and Simon [Newell et a. 91]

  • A. Cerone, UNU-IIST – p.7/46
slide-23
SLIDE 23

Cognitive Activities

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • goal formulation creates the initial state and

use perception sense changes in the external environment which are relevant to the goal of the agent

  • A. Cerone, UNU-IIST – p.8/46
slide-24
SLIDE 24

Cognitive Activities

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • goal formulation creates the initial state and

use perception sense changes in the external environment which are relevant to the goal of the agent

  • operation selection to transform a given state

to one closer to a goal state = ⇒ rational behaviour

  • A. Cerone, UNU-IIST – p.8/46
slide-25
SLIDE 25

Cognitive Activities

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • goal formulation creates the initial state and

use perception sense changes in the external environment which are relevant to the goal of the agent

  • operation selection to transform a given state

to one closer to a goal state = ⇒ rational behaviour

  • operation application changes the states of

the agent and the environment

  • A. Cerone, UNU-IIST – p.8/46
slide-26
SLIDE 26

Cognitive Activities

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • goal formulation creates the initial state and

use perception sense changes in the external environment which are relevant to the goal of the agent

  • operation selection to transform a given state

to one closer to a goal state = ⇒ rational behaviour

  • operation application changes the states of

the agent and the environment

  • goal completion when the new state is a goal

state the agent becomes inactive

  • A. Cerone, UNU-IIST – p.8/46
slide-27
SLIDE 27

Knowledge Role

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • goal formulation
  • operation selection
  • operation application
  • goal completion
  • A. Cerone, UNU-IIST – p.9/46
slide-28
SLIDE 28

Knowledge Role

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • goal formulation
  • operation selection
  • operation application
  • goal completion

Steps are triggered by knowledge availability

  • A. Cerone, UNU-IIST – p.9/46
slide-29
SLIDE 29

Knowledge Role

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • 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
slide-30
SLIDE 30

SOAR

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

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
slide-31
SLIDE 31

PUM

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

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
slide-32
SLIDE 32

PUM Philosophy

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

The interface designer

  • must program the PUM respecting the

constraints = ⇒ driven interface design = ⇒ explicit “user program”

  • A. Cerone, UNU-IIST – p.12/46
slide-33
SLIDE 33

PUM Philosophy

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

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

  • ptions
  • A. Cerone, UNU-IIST – p.12/46
slide-34
SLIDE 34

PUM Purposes

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Outcome:

predictive evaluation to tell the designer usability of a proposed design before it is actually built

  • A. Cerone, UNU-IIST – p.13/46
slide-35
SLIDE 35

PUM Purposes

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • 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
slide-36
SLIDE 36

PUMA: PUM Applications

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

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
slide-37
SLIDE 37

Detecting User Errors

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

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
slide-38
SLIDE 38

Detecting User Errors

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

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
slide-39
SLIDE 39

Detecting User Errors

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

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
slide-40
SLIDE 40

Detecting User Errors

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

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
slide-41
SLIDE 41

Theorem-proving

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Well-Formed Formulae

  • A. Cerone, UNU-IIST – p.16/46
slide-42
SLIDE 42

Theorem-proving

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Well-Formed Formulae

❍ ❍ ❍ ❨

false

✟ ✟ ✟ ✙

true

  • A. Cerone, UNU-IIST – p.16/46
slide-43
SLIDE 43

Theorem-proving

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Well-Formed Formulae

❍ ❍ ❍ ❨

false

✟ ✟ ✟ ✙

true

✟ ✟ ✟ ✙ ❍ ❍ ❍ ❨

Class of Models

  • A. Cerone, UNU-IIST – p.16/46
slide-44
SLIDE 44

Theorem-proving

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Well-Formed Formulae

❍ ❍ ❍ ❨

false

✟ ✟ ✟ ✙

true

✟ ✟ ✟ ✙ ❍ ❍ ❍ ❨

Class of Models

∈

System Model

  • A. Cerone, UNU-IIST – p.16/46
slide-45
SLIDE 45

Theorem-proving

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Well-Formed Formulae

❍ ❍ ❍ ❨

false

✟ ✟ ✟ ✙

true

✟ ✟ ✟ ✙ ❍ ❍ ❍ ❨

Class of Models

∈

System Model

⊆

Properties

  • A. Cerone, UNU-IIST – p.16/46
slide-46
SLIDE 46

Theorem-proving

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Well-Formed Formulae

❍ ❍ ❍ ❨

false

✟ ✟ ✟ ✙

true

✟ ✟ ✟ ✙ ❍ ❍ ❍ ❨

Class of Models

∈

System Model

⊆

Properties

✂ ✂ ✂ ✂ ✂ ✂ ✂ ✛

Axioms

  • A. Cerone, UNU-IIST – p.16/46
slide-47
SLIDE 47

Theorem-proving

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Well-Formed Formulae

❍ ❍ ❍ ❨

false

✟ ✟ ✟ ✙

true

✟ ✟ ✟ ✙ ❍ ❍ ❍ ❨

Class of Models

∈

System Model

⊆

Properties

✂ ✂ ✂ ✂ ✂ ✂ ✂ ✛

Axioms

✲ Inference

Rules

  • A. Cerone, UNU-IIST – p.16/46
slide-48
SLIDE 48

Theorem-proving

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Well-Formed Formulae

❍ ❍ ❍ ❨

false

✟ ✟ ✟ ✙

true

✟ ✟ ✟ ✙ ❍ ❍ ❍ ❨

Class of Models

∈

System Model

⊆

Properties

✂ ✂ ✂ ✂ ✂ ✂ ✂ ✛

Axioms

✲ Inference

Rules

✻

Theorems

  • A. Cerone, UNU-IIST – p.16/46
slide-49
SLIDE 49

Theorem-proving

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Well-Formed Formulae

❍ ❍ ❍ ❨

false

✟ ✟ ✟ ✙

true

✟ ✟ ✟ ✙ ❍ ❍ ❍ ❨

Class of Models

∈

System Model

⊆

Properties

✂ ✂ ✂ ✂ ✂ ✂ ✂ ✛

Axioms

✲ Inference

Rules

✻

Theorems

❄

  • A. Cerone, UNU-IIST – p.16/46
slide-50
SLIDE 50

Theorem-proving

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Well-Formed Formulae

❍ ❍ ❍ ❨

false

✟ ✟ ✟ ✙

true

✟ ✟ ✟ ✙ ❍ ❍ ❍ ❨

Class of Models

∈

System Model

⊆

Properties

✂ ✂ ✂ ✂ ✂ ✂ ✂ ✛

Axioms

✲ Inference

Rules

✻

Theorems

❄

⊆

  • A. Cerone, UNU-IIST – p.16/46
slide-51
SLIDE 51

Theorem-proving: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Advantages
  • A. Cerone, UNU-IIST – p.17/46
slide-52
SLIDE 52

Theorem-proving: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Advantages
  • Maximum Modelling Expressivity
  • A. Cerone, UNU-IIST – p.17/46
slide-53
SLIDE 53

Theorem-proving: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Advantages
  • Maximum Modelling Expressivity
  • Infinite State Systems
  • A. Cerone, UNU-IIST – p.17/46
slide-54
SLIDE 54

Theorem-proving: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Advantages
  • Maximum Modelling Expressivity
  • Infinite State Systems
  • Complex data structure
  • A. Cerone, UNU-IIST – p.17/46
slide-55
SLIDE 55

Theorem-proving: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Advantages
  • Maximum Modelling Expressivity
  • Infinite State Systems
  • Complex data structure
  • Disadvantages
  • A. Cerone, UNU-IIST – p.17/46
slide-56
SLIDE 56

Theorem-proving: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Advantages
  • Maximum Modelling Expressivity
  • Infinite State Systems
  • Complex data structure
  • Disadvantages
  • Semidecidability
  • A. Cerone, UNU-IIST – p.17/46
slide-57
SLIDE 57

Theorem-proving: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Advantages
  • Maximum Modelling Expressivity
  • Infinite State Systems
  • Complex data structure
  • Disadvantages
  • Semidecidability
  • Verification procedure not fully automated
  • A. Cerone, UNU-IIST – p.17/46
slide-58
SLIDE 58

Theorem-proving: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • 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
slide-59
SLIDE 59

Theorem-proving: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • 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
slide-60
SLIDE 60

Theorem-proving: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • 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
slide-61
SLIDE 61

Model-Checking: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Advantages
  • A. Cerone, UNU-IIST – p.18/46
slide-62
SLIDE 62

Model-Checking: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Advantages
  • Decidability
  • A. Cerone, UNU-IIST – p.18/46
slide-63
SLIDE 63

Model-Checking: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Advantages
  • Decidability
  • May be fully automated
  • A. Cerone, UNU-IIST – p.18/46
slide-64
SLIDE 64

Model-Checking: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Advantages
  • Decidability
  • May be fully automated
  • Better usability tools
  • A. Cerone, UNU-IIST – p.18/46
slide-65
SLIDE 65

Model-Checking: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Advantages
  • Decidability
  • May be fully automated
  • Better usability tools
  • Good scalability
  • A. Cerone, UNU-IIST – p.18/46
slide-66
SLIDE 66

Model-Checking: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Advantages
  • Decidability
  • May be fully automated
  • Better usability tools
  • Good scalability
  • Allows debugging
  • A. Cerone, UNU-IIST – p.18/46
slide-67
SLIDE 67

Model-Checking: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Advantages
  • Decidability
  • May be fully automated
  • Better usability tools
  • Good scalability
  • Allows debugging
  • Disadvantages
  • A. Cerone, UNU-IIST – p.18/46
slide-68
SLIDE 68

Model-Checking: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Advantages
  • Decidability
  • May be fully automated
  • Better usability tools
  • Good scalability
  • Allows debugging
  • Disadvantages
  • Limited Expressivity
  • A. Cerone, UNU-IIST – p.18/46
slide-69
SLIDE 69

Model-Checking: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • 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
slide-70
SLIDE 70

Model-Checking: Pros & Cons

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • 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
slide-71
SLIDE 71

Sets of Rules

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

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
slide-72
SLIDE 72

Sets of Rules

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

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
slide-73
SLIDE 73

Sets of Rules

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

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
slide-74
SLIDE 74

Sets of Rules

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

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
slide-75
SLIDE 75

Sets of Rules

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

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
slide-76
SLIDE 76

Reactive Behaviour

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

(stimulus t) ∧ NEXT reaction t

  • A. Cerone, UNU-IIST – p.20/46
slide-77
SLIDE 77

Reactive Behaviour

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

(stimulus t) ∧ NEXT reaction t NEXT does not require that the action is taken

  • n the next cycle, but rather that it is taken

before any other user action

  • A. Cerone, UNU-IIST – p.20/46
slide-78
SLIDE 78

Reactive Behaviour

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

(stimulus t) ∧ NEXT reaction t [(stimulus1,reaction1); ...; (stimulusn,reactionn)] To target the generic user model to a particular device, it is applied to a concrete list in SML

  • A. Cerone, UNU-IIST – p.20/46
slide-79
SLIDE 79

Reactive Behaviour

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

(stimulus t) ∧ NEXT reaction t [(stimulus1,reaction1); ...; (stimulusn,reactionn)] Example: [(light,push button); (wait msg,pause); (card msg,take card); (cash msg,take cash)]

  • A. Cerone, UNU-IIST – p.20/46
slide-80
SLIDE 80

Reactive Behaviour

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

(stimulus t) ∧ NEXT reaction t [(stimulus1,reaction1); ...; (stimulusn,reactionn)] Example: [(light,push button); (wait msg,pause); (card msg,take card); (cash msg,take cash)]

✲ ✒✑ ✓✏ ✲

stimulus

✒✑ ✓✏ ✚ ✙ ✻

action

  • A. Cerone, UNU-IIST – p.20/46
slide-81
SLIDE 81

Reactive Behaviour

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

(stimulus t) ∧ NEXT reaction t [(stimulus1,reaction1); ...; (stimulusn,reactionn)] Example: [(light,push button); (wait msg,pause); (card msg,take card); (cash msg,take cash)]

✲ ✒✑ ✓✏ ✲

stimulus

✒✑ ✓✏ ✚ ✙ ✻

action R

R1 = R/f1 where f1(stimulus) = light f1(reactions) = push button

  • A. Cerone, UNU-IIST – p.20/46
slide-82
SLIDE 82

Communication Goals

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

∼ (goalachieved t) ∧ (guard t) ∧ NEXT action t

  • A. Cerone, UNU-IIST – p.21/46
slide-83
SLIDE 83

Communication Goals

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

∼ (goalachieved t) ∧ (guard t) ∧ NEXT action t Example: [(has card,insert card); (TRUE,insert pin)]

  • A. Cerone, UNU-IIST – p.21/46
slide-84
SLIDE 84

Communication Goals

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

∼ (goalachieved t) ∧ (guard t) ∧ NEXT action t Example: [(has card,insert card); (TRUE,insert pin)] Goal: HasGotCash

  • A. Cerone, UNU-IIST – p.21/46
slide-85
SLIDE 85

Communication Goals

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

∼ (goalachieved t) ∧ (guard t) ∧ NEXT action t Example: [(has card,insert card); (TRUE,insert pin)] Goal: HasGotCash

✲ ✒✑ ✓✏

C

✲

notach

✒✑ ✓✏ ✲

cond

✒✑ ✓✏ ✲

action

✒✑ ✓✏

  • A. Cerone, UNU-IIST – p.21/46
slide-86
SLIDE 86

Communication Goals

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

∼ (goalachieved t) ∧ (guard t) ∧ NEXT action t Example: [(has card,insert card); (TRUE,insert pin)] Goal: HasGotCash

✲ ✒✑ ✓✏

C

✲

notach

✒✑ ✓✏ ✲

cond

✒✑ ✓✏ ✲

action

✒✑ ✓✏ ✲ ✒✑ ✓✏

G

✲

goal

✒✑ ✓✏

notach

✞ ☎ ❄

  • A. Cerone, UNU-IIST – p.21/46
slide-87
SLIDE 87

Completion

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

if (((invariant t) ∧ (goalachieved t)) ∨ ((finished (t −1)) then action finished t else —disjunction of nondeterministic rules— Invariant: VALUE possession t ≥ VALUE possession 1

✲ ✒✑ ✓✏

C

✲

notach

✒✑ ✓✏ ✲

cond

✒✑ ✓✏ ✲

action

✒✑ ✓✏ ✲ ✒✑ ✓✏

G

✲

goal

✒✑ ✓✏

notach

✞ ☎ ❄

  • A. Cerone, UNU-IIST – p.22/46
slide-88
SLIDE 88

Completion

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

if (((invariant t) ∧ (goalachieved t)) ∨ ((finished (t −1)) then action finished t else —disjunction of nondeterministic rules— Invariant: VALUE possession t ≥ VALUE possession 1

✲ ✒✑ ✓✏

C

✲

notach

✒✑ ✓✏ ✲

cond

✒✑ ✓✏ ✲

action

✒✑ ✓✏ ✲ ✒✑ ✓✏

G

✲

goal

✒✑ ✓✏

notach

✞ ☎ ❄ ❄

finished

✒✑ ✓✏

  • A. Cerone, UNU-IIST – p.22/46
slide-89
SLIDE 89

Completion

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

if (((invariant t) ∧ (goalachieved t)) ∨ ((finished (t −1)) then action finished t else —disjunction of nondeterministic rules— Invariant: VALUE possession t ≥ VALUE possession 1

✲ ✒✑ ✓✏

C

✲

notach

✒✑ ✓✏ ✲

cond

✒✑ ✓✏ ✲

action

✒✑ ✓✏ ✲ ✒✑ ✓✏

G

✲

goal

✒✑ ✓✏

notach

✞ ☎ ❄ ❄

finished

✒✑ ✓✏ ✲ ✒✑ ✓✏

I

✲

pert

✒✑ ✓✏

invariant

✞ ☎ ❄ ❄

finished

✒✑ ✓✏ ✚ ✙ ✻

restore

  • A. Cerone, UNU-IIST – p.22/46
slide-90
SLIDE 90

Completion

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

if (((invariant t) ∧ (goalachieved t)) ∨ ((finished (t −1)) then action finished t else —disjunction of nondeterministic rules— Invariant: VALUE possession t ≥ VALUE possession 1

✲ ✒✑ ✓✏

C

✲

notach

✒✑ ✓✏ ✲

cond

✒✑ ✓✏ ✲

action

✒✑ ✓✏ ✲ ✒✑ ✓✏

G

✲

goal

✒✑ ✓✏

notach

✞ ☎ ❄ ❄

finished

✒✑ ✓✏ ✲ ✒✑ ✓✏

I

✲

pert

✒✑ ✓✏

invariant

✞ ☎ ❄ ❄

finished

✒✑ ✓✏ ✚ ✙ ✻

restore

✞ ✝

finished

✲ ✞ ✝

finished

✲

  • A. Cerone, UNU-IIST – p.22/46
slide-91
SLIDE 91

CSP Architecture

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

✲ ✒✑ ✓✏

C

✲

notach

✒✑ ✓✏ ✲

cond

✒✑ ✓✏ ✲

action

✒✑ ✓✏ ✲ ✒✑ ✓✏

G

✲

goal

✒✑ ✓✏

notach

✞ ☎ ❄ ❄

finished

✒✑ ✓✏ ✲ ✒✑ ✓✏

I

✲

pert

✒✑ ✓✏

invariant

✞ ☎ ❄ ❄

finished

✒✑ ✓✏ ✚ ✙ ✻

restore

✞ ✝

finished

✲ ✞ ✝

finished

✲ ✲

finished

✒✑ ✓✏

finished

✞ ☎ ❄

R

✲ ✒✑ ✓✏ ✲

stimulus

✒✑ ✓✏ ✚ ✙ ✻

action

✲

finished

✒✑ ✓✏

finished

☎ ✆ ✛

  • A. Cerone, UNU-IIST – p.23/46
slide-92
SLIDE 92

User Model

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

HOL

  • A. Cerone, UNU-IIST – p.24/46
slide-93
SLIDE 93

User Model

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

HOL Rule disjunction

  • A. Cerone, UNU-IIST – p.24/46
slide-94
SLIDE 94

User Model

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

HOL Rule disjunction CSP

  • A. Cerone, UNU-IIST – p.24/46
slide-95
SLIDE 95

User Model

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

HOL Rule disjunction CSP

U = R1 ... Rm ((C1 G) |[{goal,finished}]| ... ... |[{goal,finished}]| (Cn G)) I1 ... Is

  • A. Cerone, UNU-IIST – p.24/46
slide-96
SLIDE 96

User Model

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

HOL Rule disjunction CSP

U = R1 ... Rm ((C1 G) |[{goal,finished}]| ... ... |[{goal,finished}]| (Cn G)) I1 ... Is

What’s missing?

  • A. Cerone, UNU-IIST – p.24/46
slide-97
SLIDE 97

EXERCISE

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

How to guarantee that all reactive behaviours and communication goals are performed atomically within the user model?

  • A. Cerone, UNU-IIST – p.25/46
slide-98
SLIDE 98

Formal Verification

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

HOL — Correctness Theorem

  • A. Cerone, UNU-IIST – p.26/46
slide-99
SLIDE 99

Formal Verification

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

HOL — Correctness Theorem ⊢ ∀ state traces. initial state ∧ device specification ∧ user model ⊃ ∃ t . (invariant t) ∧ (goalachieved t)

  • A. Cerone, UNU-IIST – p.26/46
slide-100
SLIDE 100

Formal Verification

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

HOL — Correctness Theorem ⊢ ∀ state traces. initial state ∧ device specification ∧ user model ⊃ ∃ t . (invariant t) ∧ (goalachieved t) CSP

  • A. Cerone, UNU-IIST – p.26/46
slide-101
SLIDE 101

Formal Verification

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

HOL — Correctness Theorem ⊢ ∀ state traces. initial state ∧ device specification ∧ user model ⊃ ∃ t . (invariant t) ∧ (goalachieved t) CSP − Overall system

OverallSystem = U Device

  • A. Cerone, UNU-IIST – p.26/46
slide-102
SLIDE 102

Formal Verification

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

HOL — Correctness Theorem ⊢ ∀ state traces. initial state ∧ device specification ∧ user model ⊃ ∃ t . (invariant t) ∧ (goalachieved t) CSP − Overall system

OverallSystem = U Device

− Temporal Logic Formula

✷✸finished checked on OverallSystem

  • A. Cerone, UNU-IIST – p.26/46
slide-103
SLIDE 103

Classes of User Errors

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Errors detected by attempts to prove the task completion error

  • A. Cerone, UNU-IIST – p.27/46
slide-104
SLIDE 104

Classes of User Errors

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Errors detected by attempts to prove the task completion error Classes of errors defined in terms of their cognitive causes rather than their effects:

  • post-completion errors
  • communication-goal errors
  • device delay errors
  • A. Cerone, UNU-IIST – p.27/46
slide-105
SLIDE 105

Post-completion Errors

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

User terminates an interation with outstanding tasks remaining

  • A. Cerone, UNU-IIST – p.28/46
slide-106
SLIDE 106

Post-completion Errors

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

User terminates an interation with outstanding tasks remaining It emerges because of a rule allowing the user to stop once the goal is achieved

  • A. Cerone, UNU-IIST – p.28/46
slide-107
SLIDE 107

Post-completion Errors

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

User terminates an interation with outstanding tasks remaining It emerges because of a rule allowing the user to stop once the goal is achieved Design Principle: goal cannot be achieved until after the interaction invariant is restored

  • A. Cerone, UNU-IIST – p.28/46
slide-108
SLIDE 108

Post-completion Errors

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

User terminates an interation with outstanding tasks remaining It emerges because of a rule allowing the user to stop once the goal is achieved Design Principle: goal cannot be achieved until after the interaction invariant is restored Error still present if a warning after goal achieved remind the user to do the completions tasks

  • A. Cerone, UNU-IIST – p.28/46
slide-109
SLIDE 109

Communication Errors

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

User discharges communication goals in an

  • rder different from the one required by the

device

  • A. Cerone, UNU-IIST – p.29/46
slide-110
SLIDE 110

Communication Errors

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

User discharges communication goals in an

  • rder different from the one required by the

device It emerges because of communication rule removed too early = ⇒ activate abort rule

  • A. Cerone, UNU-IIST – p.29/46
slide-111
SLIDE 111

Communication Errors

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

User discharges communication goals in an

  • rder different from the one required by the

device It emerges because of communication rule removed too early = ⇒ activate abort rule Design Principle: the device must not require a specific order for the communication goal actions

  • A. Cerone, UNU-IIST – p.29/46
slide-112
SLIDE 112

Communication Errors

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

User discharges communication goals in an

  • rder different from the one required by the

device It emerges because of communication rule removed too early = ⇒ activate abort rule Design Principle: the device must not require a specific order for the communication goal actions Error still present if a message tell the user the right order

  • A. Cerone, UNU-IIST – p.29/46
slide-113
SLIDE 113

Device Delay Errors

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

User discharges outstanding communication goals during device delay

  • A. Cerone, UNU-IIST – p.30/46
slide-114
SLIDE 114

Device Delay Errors

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

User discharges outstanding communication goals during device delay It emerges because of communication rule removed too early = ⇒ activate abort rule

  • A. Cerone, UNU-IIST – p.30/46
slide-115
SLIDE 115

Device Delay Errors

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

User discharges outstanding communication goals during device delay It emerges because of communication rule removed too early = ⇒ activate abort rule Design Principle: the device delay can only occur when there is no outstanding communicatin goal in the presence of a “wait” warning causing a “pause” reaction

  • A. Cerone, UNU-IIST – p.30/46
slide-116
SLIDE 116

TP vs. MC

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Theorem Proving
  • A. Cerone, UNU-IIST – p.31/46
slide-117
SLIDE 117

TP vs. MC

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Theorem Proving
  • automated correctness proof
  • A. Cerone, UNU-IIST – p.31/46
slide-118
SLIDE 118

TP vs. MC

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Theorem Proving
  • automated correctness proof
  • informal reasoning to detect errors
  • A. Cerone, UNU-IIST – p.31/46
slide-119
SLIDE 119

TP vs. MC

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Theorem Proving
  • automated correctness proof
  • informal reasoning to detect errors
  • Model Checking more promising
  • A. Cerone, UNU-IIST – p.31/46
slide-120
SLIDE 120

TP vs. MC

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Theorem Proving
  • automated correctness proof
  • informal reasoning to detect errors
  • Model Checking more promising
  • general correctness: ✷✸finished
  • A. Cerone, UNU-IIST – p.31/46
slide-121
SLIDE 121

TP vs. MC

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Theorem Proving
  • automated correctness proof
  • informal reasoning to detect errors
  • Model Checking more promising
  • general correctness: ✷✸finished
  • post-completion correctness: ✷✸invariant
  • A. Cerone, UNU-IIST – p.31/46
slide-122
SLIDE 122

TP vs. MC

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • Theorem Proving
  • automated correctness proof
  • informal reasoning to detect errors
  • Model Checking more promising
  • general correctness: ✷✸finished
  • post-completion correctness: ✷✸invariant
  • automatically generated counterexample

allows error detection and correction

  • A. Cerone, UNU-IIST – p.31/46
slide-123
SLIDE 123

Examination — Architectures

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

SOAR and PUMA

  • Seminars
  • Theorem proving and informal reasoning for

usability studies

  • The SOAR cognitive architecture
  • Reports
  • CSP model of the PUMA cognitive

architecture

  • A. Cerone, UNU-IIST – p.32/46
slide-124
SLIDE 124

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Examinations

  • A. Cerone, UNU-IIST – p.33/46
slide-125
SLIDE 125

Seminar 1 — Full OCM for ATC

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Topic: Operator Choice Model for ATC Full OCM model for the ATC

  • D. Leadbetter, P

. Lindsay, A. Hussey, A. Neal and M. Humphreys Towards Towards Model Based Prediction of Human Error Rates in Interactive Systems, 2000

  • A. Hussey, D. Leadbetter, P

. Lindsay, A. Neal and M. Humphreys Modelling and Hazard Identification in an Air-Traffic Control User-Interface, 2000

  • S. Connelly, P

. Lindsay, A. Neal and M. Humphreys A formal model of cognitive processes for an Air Traffic Control Task, 2001

  • A. Cerone, UNU-IIST – p.34/46
slide-126
SLIDE 126

Seminar 2 — Mode Confusion

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Topic: Mode Confusion Formal analysis of mode confusion

  • S. P

. Miller and J. N. Potts Detecting Mode confusion Through formal Modelling and Analysis, 1999

  • N. Leveson, L. D. Pinnel, S. D. Sandys, S. Koga and J. D. Reese

Analysing Software Specification for Mode Confusion Potential, 1998

  • R. W. Butler, S. P

. Miller, J. N. Potts and V. A. Carreno A Formal Methods Approach to the Analysis of Mode Confusion, 1998

  • A. Cerone, UNU-IIST – p.35/46
slide-127
SLIDE 127

Seminar 3 — PUMA

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Topic: PUMA Work Theorem proving and informal reasoning for usability studies

  • P

. Curzon and A. Blandford Detecting Multiple Classes of User Errors, 2001

  • P

. Curzon and A. Blandford From a Formal User Model to Design Rules, 2002

  • P

. Curzon and A. Blandford Formally Justifying User-Centred Design Rules: a Case Study on Post-completion Error, 2004

  • A. Cerone, UNU-IIST – p.36/46
slide-128
SLIDE 128

Seminar 4 — SOAR

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Topic: SOAR The SOAR cognitive architecture (for one or more PhD

students)

  • SOAR Home Page

http://sitemaker.umich.edu/soar/

  • The SOAR Tutorial

http://sitemaker.umich.edu/soar/documentation and links Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6

  • A. Cerone, UNU-IIST – p.37/46
slide-129
SLIDE 129

Report 1 — FM of Full ATC

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Topic: Operator Choice Model Formal model of the full OCM for ATC

using CSP or other formalism, possibly running simulation using a tool

  • D. Leadbetter, P

. Lindsay, A. Hussey, A. Neal and M. Humphreys Towards Model Based Prediction of Human Error Rates in Interactive Systems, 2000

  • S. Connelly, P

. Lindsay, A. Neal and M. Humphreys A formal model of cognitive processes for an Air Traffic Control Task, 2001

  • Antonio Cerone, Simon Connelly and Peter Lindsay.

Formal Analysis of Operator Behavioural Patterns in Interactive Systems, submitted

  • A. Cerone, UNU-IIST – p.38/46
slide-130
SLIDE 130

Report 2 — Cooperative TM

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Topic: Task Models Formal Analysis of Cooperative Task Models

Discussion of the papers’ differences and limitations and propose possible extensions

  • F

. Paternò, C. Santoro and S. Thamassebi Formal models for Cooperative Tasks: Concepts and an Application for En-route Air Traffic Control

  • V. M. R. Penichlet, F

. Paternò, J. A. Gallud and M. D. Lozano Collaborative Social Structures and Task Modelling Integration

  • D. Pinelle and C. Gutwin

Task Analysis for Groupware Usability Evaluation: Modeling Shared Workplace Tasks with Mechanics of cCllaboration

  • A. Cerone, UNU-IIST – p.39/46
slide-131
SLIDE 131

Report 3 — PUMA

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Topic: PUMA Work CSP model of the PUMA cognitive architecture

Build a case study and formally analyse it with a tool (e.g. CWNC)

  • P

. Curzon and A. Blandford Using a Verification System to Reason about Post-Completion Errors, 2000

  • P

. Curzon and A. Blandford Reasoning about Order Errors in Interaction, 2000

  • P

. Curzon and A. Blandford Detecting Multiple Classes of User Errors, 2001

  • A. Cerone, UNU-IIST – p.40/46
slide-132
SLIDE 132

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

References

  • A. Cerone, UNU-IIST – p.41/46
slide-133
SLIDE 133

Cognitive Architecturess

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

  • []:
  • A. Cerone, UNU-IIST – p.42/46
slide-134
SLIDE 134

[Newel et al. 91]

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Allen Newell, Gregg Yost, John Laird, Paul Rosembloom, Ekkehard Altmann. Formaulating the problem-space computational model. In R. F . Rashid (ed) CMU Computer Science: a 25th Anniversary Commemorative, Chapter 11, ACM Press, 1991.

  • Problem Space
  • Cognitive Architectures
  • A. Cerone, UNU-IIST – p.43/46
slide-135
SLIDE 135

[Newel et al. 87]

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Allen Newell, John Laird, Paul Rosembloom. SOAR: an architecture for general intelligence. Artificial Intelligence 33, 1987, pages 1–64.

  • SOAR
  • A. Cerone, UNU-IIST – p.44/46
slide-136
SLIDE 136

[Young et al. 89]

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Richard Young, T. R. G. Green, Tony Simon. Programmable user models for predictive evaluation of interface design. In K. Bice and G. Lewis (eds) Proceedings of CHI’89: Human Factors in Computing Systems, ACM Press, 1989, pages 15–19.

  • PUM
  • A. Cerone, UNU-IIST – p.45/46
slide-137
SLIDE 137

[Curzon et al. 01]

Models | Architectures | SOAR | PUM | PUMA | Theorem Proving | Model Checking | Rules | Exams | Refs

Paul Curzon, Ann Blandford. Detecting multiple classes of user errors. In Proceedings of EHCI’01, LNCS 2254, Springer, 2001, pages 57–71.

  • Detecting Errors
  • A. Cerone, UNU-IIST – p.46/46