Presentation is loading. Please wait.

Presentation is loading. Please wait.

SPECIFYING COGNITIVE MODELS Using Patterns and Conflicts A. Macklem, F. Mili Oakland University S. Dungrani TARDEC June, 2004.

Similar presentations


Presentation on theme: "SPECIFYING COGNITIVE MODELS Using Patterns and Conflicts A. Macklem, F. Mili Oakland University S. Dungrani TARDEC June, 2004."— Presentation transcript:

1 SPECIFYING COGNITIVE MODELS Using Patterns and Conflicts A. Macklem, F. Mili Oakland University S. Dungrani TARDEC June, 2004

2 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

3 Motivation Two categories of cognitive models  Models developed to validate cognitive architectures  Models developed for industrial applications

4 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

5 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

6 Motivation Q. What is the prerequisite for providing this support? A. A Specification language and methodology for cognitive models.

7 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

8 Specification Levels A hierarchy of specifications  Functional Levels Pre/Post conditions Reactive behaviors  Cognitive Levels Functional Cognitive

9 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 ConfigurationSample Goal Configuration

10 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 mistake  employing of strategy

11 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

12 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

13 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.

14 Patterns and Conflicts A pattern may occur any number of times including zero A conflict must never occur

15 Finite State Automaton Pattern P1

16 Finite State Automaton Conflict C1

17 LR(0) Grammar Pattern P1: S  A A  A | S | B B  B | A | Conflict C1: S  A A  A | S | B B  B | A | C C 

18 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  A Where D 2 > D 1 A  S |

19 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

20 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.

21 Cognitive Requirements: Strategy Pattern P2

22 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.

23 Cognitive Requirements: Errors Conflict C3

24 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.

25 Current and Future Work Verification - Graph Based Tool support

26 Methodology For Generating Specifications Iterative approach  Patterns and conflicts constructed  Traces are generated consistent with the patterns and conflicts  Patterns and conflicts refined or augmented

27 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.


Download ppt "SPECIFYING COGNITIVE MODELS Using Patterns and Conflicts A. Macklem, F. Mili Oakland University S. Dungrani TARDEC June, 2004."

Similar presentations


Ads by Google