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

Slides:



Advertisements
Similar presentations
Jeremy S. Bradbury, James R. Cordy, Juergen Dingel, Michel Wermelinger
Advertisements

Personalized Presentation in Web-Based Information Systems Institute of Informatics and Software Engineering Faculty of Informatics and Information Technologies.
Extreme Programming Alexander Kanavin Lappeenranta University of Technology.
Lecture # 2 : Process Models
Multimedia Specification Design and Production 2013 / Semester 1 / week 7 Lecturer: Dr. Nikos Gazepidis
CS487 Software Engineering Omar Aldawud
The design process IACT 403 IACT 931 CSCI 324 Human Computer Interface Lecturer:Gene Awyzio Room:3.117 Phone:
HCI in the software process Chapter 6
Software Process Models
Chapter 2 Process Models
Presented by: Thabet Kacem Spring Outline Contributions Introduction Proposed Approach Related Work Reconception of ADLs XTEAM Tool Chain Discussion.
Background information Formal verification methods based on theorem proving techniques and model­checking –to prove the absence of errors (in the formal.
CLEANROOM SOFTWARE ENGINEERING
Patterns in Game Design Chapter 9: Game Design Patterns for Narrative Structures, Predictability, and Immersion Patterns CT60A7000 Critical Thinking and.
Chapter 6: Design of Expert Systems
Chapter 2- Software Process Lecture 4. Software Engineering We have specified the problem domain – industrial strength software – Besides delivering the.
Data Structures and Programming.  John Edgar2.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
The design process z Software engineering and the design process for interactive systems z Standards and guidelines as design rules z Usability engineering.
Chapter : Software Process
Formal Methods 1. Software Engineering and Formal Methods  Every software engineering methodology is based on a recommended development process  proceeding.
1 CMPT 275 Software Engineering Software life cycle.
Towers of Hanoi. Introduction This problem is discussed in many maths texts, And in computer science an AI as an illustration of recursion and problem.
Chapter 2 The process Process, Methods, and Tools
CLEANROOM SOFTWARE ENGINEERING.
Design Patterns OOD. Course topics Design Principles UML –Class Diagrams –Sequence Diagrams Design Patterns C#,.NET (all the course examples) Design Principles.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Teaching material for a course in Software Project Management & Software Engineering – part II.
What is “model transformation”? Distinction between source and target Source may be same as target May be multiple sources, or targets Reaching a fixed.
 CS 5380 Software Engineering Chapter 2 – Software Processes Chapter 2 Software Processes1.
Lecture 7 Declarative Knowledge English Study Program FKIP – UNSRI July
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
1 Introduction to Software Engineering Lecture 1.
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
Chapter 4 프로세스 모델 Process Models
Object-Oriented Software Engineering using Java, Patterns &UML. Presented by: E.S. Mbokane Department of System Development Faculty of ICT Tshwane University.
OOAD Unit – I OBJECT-ORIENTED ANALYSIS AND DESIGN With applications
Fall 2004EE 3563 Digital Systems Design EE 3563 VHSIC Hardware Description Language  Required Reading: –These Slides –VHDL Tutorial  Very High Speed.
Chapter 6.1: Recurrence Relations Discrete Mathematical Structures: Theory and Applications.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
Formal Methods.
1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2.
Design Reuse Earlier we have covered the re-usable Architectural Styles as design patterns for High-Level Design. At mid-level and low-level, design patterns.
Smart Home Technologies
Process Asad Ur Rehman Chief Technology Officer Feditec Enterprise.
CS223: Software Engineering Lecture 4: Software Development Models.
Formal Verification. Background Information Formal verification methods based on theorem proving techniques and model­checking –To prove the absence of.
PI2134 Software Engineering IT Telkom.  Layered technology  Software Process  Generic Process (by Pressman)  Fundamental activities (by Sommerville)
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
DESIGN PROCESS AND CONCEPTS. Design process s/w design is an iterative process through which requirements are translated into a “blueprint” for constructing.
Review of last class Software Engineering Modeling Problem Solving
Object-Oriented Software Engineering Using UML, Patterns, and Java,
IEEE Std 1074: Standard for Software Lifecycle
Chapter 6: Design of Expert Systems
Program comprehension during Software maintenance and evolution Armeliese von Mayrhauser , A. Marie Vans Colorado State University Summary By- Fardina.
HCI in the software process
The design process Software engineering and the design process for interactive systems Standards and guidelines as design rules Usability engineering.
The design process Software engineering and the design process for interactive systems Standards and guidelines as design rules Usability engineering.
Introduction Artificial Intelligent.
Chapter 2 Process Models
Need for the subject.
Chapter 2 Process Models
HCI in the software process
Chapter 2 Process Models.
UNIT 5 EMBEDDED SYSTEM DEVELOPMENT
UNIT 5 EMBEDDED SYSTEM DEVELOPMENT
Chapter 4 Process Models
HCI in the software process
Human Computer Interaction Lecture 14 HCI in Software Process
Chapter 2 Process Models
Presentation transcript:

SPECIFYING COGNITIVE MODELS Using Patterns and Conflicts A. Macklem, F. Mili Oakland University S. Dungrani TARDEC 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 models  Models developed to validate cognitive architectures  Models 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 specifications  Functional Levels Pre/Post conditions Reactive behaviors  Cognitive Levels 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 ConfigurationSample 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 mistake  employing 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

Finite State Automaton Conflict C1

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 

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 |

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

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

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 constructed  Traces are generated consistent with the patterns and conflicts  Patterns 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, F. Mili, et al., “Patterns and Conflicts for the Specification of Cognitive Models”, under review for publication, 2004.