Abstract not found

Software development remains mentally challenging despite the continual advancement of training, techniques, and tools. Because completely automating software development is currently impossible, it makes sense to seriously consider how tools can improve the mental activities of developers apart from automating them away. Such mental assistance can be called “cognitive support”. Understanding and developing cognitive support in software engineering tools is an important research issue but, unfortunately, at the moment our theoretical foundations for it are inadequately developed. Furthermore, much of the relevant research has occurred outside of the software engineering community, and is therefore not easily available to the researchers who typically develop software engineering tools. Tool evaluation, comparison, and development are consequently impaired. The present work introduces a theoretical framework intended to seed further systematic study of cognitive support in the field of software engineering tools. This theoretical framework, called RODS, imports ideas and methods from a field of cognitive science called “distributed cognition”. The crucial concept in RODS is that cognitive support can be understood and explained in terms of the computational advantages that are conferred when cognition is redistributed between software developer and their tools and environment. The name RODS, in fact, comes from the

Abstract not found

What is the role of a cognitive architecture in shaping a model built within it? Compared with a model written in a programming language, the cognitive architecture offers theoretical constraints. These constraints can be "soft", in that some ways of constructing a model are facilitated and others made more difficult, or they can be "hard", in that certain aspects of a model are enforced and others are ruled out. We illustrate various of these possibilities. In the case of Soar, its learning mechanism is sufficiently constraining that it imposes hard constraints on models constructed within it. We describe how one of these hard constraints deriving from Soar's learning mechanism ensures that models constructed within Soar must learn a display-based skill and, other things being equal, must find display-based devices easier to learn than keyboard-based devices. We discuss the relation between architecture and model in terms of the degree to which a model is "compliant" with the constraints set by the architecture. Although doubts are sometimes expressed as to whether cognitive architectures have any empirical consequences for user modelling, our analysis shows that they do. Architectures play their part by imposing theoretical constraints on the models constructed within them, and the extent to which the influence of the architecture shows through in the model's behaviour depends on the compliancy of the model. 1.