SPECIFYING COGNITIVE MODELS

Using Patterns and ConflictsA. Macklem, F. MiliOakland University

S. DungraniTARDEC

June, 2004

Overview

Motivation for specifying cognitive models Example: Tower of Hanoi Patterns and Conflicts specification language Features of the specification language

Multi-layered specifications Modularity Reuse

Motivation

Two categories of cognitive modelsModels developed to validate cognitive

architecturesModels developed for industrial applications

Motivation

Models in the first category: Developed by researchers and experts in cognitive

modeling Assumed correct Generally relatively small and self contained Tested extensively and compared with data collected

from human experiments Test results are used as feedback for the architecture

Motivation

Models in the second category Are developed by software engineers Potentially large, involving many models reused and

combined Require support methodologies and tools in:

Capturing requirements Identifying reusable models Composing models Modifying models Testing Validating

Motivation

Q. What is the prerequisite for providing this support?

A. A Specification language and methodology for cognitive models.

What do we need to specify?

Functional Requirements What is the goal of the task, the correct outcome

Cognitive Requirements Actions taken Rationale used for the decisions Types of errors made Learning Timing characteristics

Specification Levels A hierarchy of

specificationsFunctional Levels

Pre/Post conditions Reactive behaviors

Cognitive Levels

Level N

…

Level 2

Level 1

Level 0

Functional

Cognitive

Running Example: Tower of Hanoi

The rules of the game:1. Only one disk can be moved at a time

2. Only the topmost disk on a peg can be moved

3. A disk cannot be placed on top of a smaller disk.

Sample Start Configuration Sample Goal Configuration

Specification Levels: Tower of Hanoi

Functional Level(s): Capture the objective of the game and the rules of play

Cognitive Level(s): Capture how to play the game in a human-like manner the occurrence of trial and error the occurrence of learning by not repeating

the same mistakeemploying of strategy

Specification Language

Borrows from the idea of patterns and conflicts used by scheduling of concurrent processes in collaborative transactions [1]

Semantic concept: Patterns and Conflicts Syntactically expressed: LR(0) grammar or

finite state automata

Patterns and Conflicts

A model’s behavior is captured by is trace.

Time

Patterns: mandatory interleavings Conflicts: forbidden interleavings

Remove disk 1 from peg A Place disk 1

on Peg C

Remove disk 2 from peg A Place disk 2

on Peg B

Example Pattern and Conflict

Pattern P1: Places the large, medium, and small disks on their goal pegs

Conflict C1: Must not make any move once the goal configuration is reached.

Patterns and Conflicts

A pattern may occur any number of times including zero

A conflict must never occur

Finite State Automaton

Pattern P1

<, place on goal peg, large disk> <, place on goal peg, medium disk>

<, place on goal peg, small disk><,remove from goal peg,

large disk>

<,remove from goal peg, medium disk><, any move, any

disk >

<, any move, any disk >

Finite State Automaton

Conflict C1

<,any move, any disk>

<, place on goal peg, large disk> <, place on goal peg, medium disk>

<, place on goal peg, small disk><,remove from goal peg,

large disk>

<,remove from goal peg, medium disk><, any move, any

disk >

<, any move, any disk >

LR(0) Grammar

Pattern P1:S <., place on goal peg, large disk > AA <., any move, any disk> A | <., remove from goal peg, large disk> S |

<., place on goal peg, medium disk> BB <., any move, any disk> B | <., remove from goal peg, medium disk> A |

<., place on goal peg, small disk>

Conflict C1:S <., place on goal peg, large disk> AA <., any move, any disk> A | <., remove from goal peg, large disk> S |

<., place on goal peg, medium disk> BB <., any move, any disk> B | <., remove from goal peg, medium disk> A |

<., place on goal peg, small disk> CC <., any move, any disk>

Level 1 Specifications

Cognitive models focus on capturing decision making processes reflected on the sequence of actions taken.

C2 captures the fact that the moves comply with the rules of the game.

C2: Conflict C2 specifies that a larger disk cannot be placed on top of a smaller disk.

S <., place onto peg X, D1> A Where D2 > D1

A <., remove from peg X, D1> S | <., place onto peg X, D2>

<, place on peg X, D1> <, place on peg X, D2>

<,remove from peg X, D1>

Cognitive Requirements: Strategy

A strength of this specification language is that it allows specifications to be written on either a micro or macro scale. Level 1 specifications pertain to rules that

govern every move Strategy specifications (in this example, level

2 specifications) are concerned with an overall strategy for winning the game, only interested in a few crucial moves

Cognitive Requirements: Strategy

Pattern P2: expresses the strategy for moving the stacked disks from peg A to a stacked goal configuration on peg B.

1. First, all but the large disk should be moved from peg A to C.

2. Then the large disk moved to peg B. 3. Finally the remaining disks should be moved

to peg B.

Cognitive Requirements: Strategy

Pattern P2

<,move to peg B, small disk>

<, place on medium, disk, any

disk>

<,clear, large disk> <, place on peg B, large disk>

<, place on large disk, any

disk>

<,remove from peg B, large disk><, any move, any

disk >

<, any move, any

disk >

<, clear, medium

disk>

<,move to peg B, medium disk>

<, any move, any

disk >

<, any move, any

disk ><,remove from peg B, medium disk>

Cognitive Requirements: Errors

This specification deals with learning to not repeat errors, i.e. mistaken moves.

Conflict C3: Do not cycle on the same move more than twice without trying something different.

This conflict will only occur if a disk is placed on and then taken off the same peg more than twice, without any movement of another disk in between.

Cognitive Requirements: Errors

Conflict C3<,place on peg X, disk i> <, remove from peg X, disk i>

<,place on peg X, disk i> <, remove from peg X, disk i>

<, any move, any disk not i>

<, any move, any disk not i>

<, place on peg X, disk i><, any move, any disk not i>

<, any move, any disk not i>

Specification Language Features

Multi-layered: There are a number of advantages to separating the different layers of the specification.

Separation of concerns and facilitates the elicitation of specifications. Allows you to capture specifications in an incremental way By capturing the functional layer separately, the same functional specification can be used

for a model regardless of the architecture under which it is being implemented. Some aspects of the cognitive specification can be captured in a generic way and reused for

different tasks. Modularity

If some aspects of the cognitive layer are hard to formalize, we can at least capture the functional level and verify the model’s functional correctness. The other aspects can, then, be left for testing.

Reuse This specification language allows the creation of abstract operations for use within the

specifications. This allows a higher level operation to be defined once reused in any other level of specification.

Current and Future Work

Verification - Graph Based Tool support

Methodology For Generating Specifications Iterative approach

Patterns and conflicts constructedTraces are generated consistent with the

patterns and conflictsPatterns and conflicts refined or augmented

References

1. M. Nodine, S Ramaswamy, and S. Zdonik, “A Cooperative Transactions Model for design Databases,” in Database Transaction Models for Advanced Applications, Ed A. Elmagarmid, Morgan Kaufmann Publishers, CA, 1992

2. F. Mili, et al., “Patterns and Conflicts for the Specification of Cognitive Models”, under review for publication, 2004.