David C. Littman

Bio: David C. Littman is an academic researcher from Yale University. The author has contributed to research in topics: TUTOR & Programmer. The author has an hindex of 7, co-authored 14 publications receiving 747 citations. Previous affiliations of David C. Littman include George Mason University.

Mental models and software maintenance

Abstract: Understanding how a program is constructed and how it functions are significant components of the task of maintaining or enhancing a computer program. We have analyzed vidoetaped protocols of experienced programmers as they enhanced a personnel data base program. Our analysis suggests that there are two strategies for program understanding, the systematic strategy and the as-needed strategy. The programmer using the systematic strategy traces data flow through the program in order to understand global program behavior. The programmer using the as-needed strategy focuses on local program behavior in order to localize study of the program. Our empirical data show that there is a strong relationship between using a systematic approach to acquire knowledge about the program and modifying the program successfully. Programmers who used the systematic approach to study the program constructed successful modifications; programmers who used the as-needed approach failed to construct successful modifications. Programmers who used the systematic strategy gathered knowledge about the causal interactions of the program's functional components . Programmers who used the as-needed strategy did not gather such causal knowledge and therefore failed to detect interactions among components of the program.

Designing documentation to compensate for delocalized plans

Abstract: Conceptual representation methods play a significant role in facilitating the software process. Recent studies explore and clarify the use of these representations and their impact on progress.

Modelling human expertise in knowledge engineering: some preliminary observations

Abstract: This paper reports the results of an empirical analysis of the knowledge engineering behavior of six persons with extensive experience in artificial intelligence (AI). The six persons were given the task of designing an AI program and were videotaped while they did so; during their 2–3 h design sessions, they were asked to talk aloud about what they were doing and why they were doing it. The paper identifies several recurrent behaviors common to all the AI designers. For example, several components of the designers' goal structures are identified, as is the importance of focussing on a “touchstone”, or key issue, around which much of the designer's behavior revolves. Several potential implications of the research for the design of knowledge engineering tools are explored.

The Knowledge Required for Tutorial Planning: An Empirical Analysis.

Abstract: A significant portion of tutorial interactions revolve around the bugs a student makes. When a tutor performs an intervention to help a student fix a programming bug, the problem of deciding how to help the student appears to require extensive planning. In this article, we identify five considerations tutors appear to take into account when they plan tutorial interventions for students’ bugs. Using data collected from human tutors working in the domain of introductory computer programming, we (1) identify the knowledge tutors use when they reason about the five planning considerations, and (2) show that tutors are consistent in the ways that they use the kinds of knowledge to reason about students’ bugs.

An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information during Software Maintenance Tasks

Abstract: Much of software developers' time is spent understanding unfamiliar code. To better understand how developers gain this understanding and how software development environments might be involved, a study was performed in which developers were given an unfamiliar program and asked to work on two debugging tasks and three enhancement tasks for 70 minutes. The study found that developers interleaved three activities. They began by searching for relevant code both manually and using search tools; however, they based their searches on limited and misrepresentative cues in the code, environment, and executing program, often leading to failed searches. When developers found relevant code, they followed its incoming and outgoing dependencies, often returning to it and navigating its other dependencies; while doing so, however, Eclipse's navigational tools caused significant overhead. Developers collected code and other information that they believed would be necessary to edit, duplicate, or otherwise refer to later by encoding it in the interactive state of Eclipse's package explorer, file tabs, and scroll bars. However, developers lost track of relevant code as these interfaces were used for other tasks, and developers were forced to find it again. These issues caused developers to spend, on average, 35 percent of their time performing the mechanics of navigation within and between source files. These observations suggest a new model of program understanding grounded in theories of information foraging and suggest ideas for tools that help developers seek, relate, and collect information in a more effective and explicit manner

The state of the art in end-user software engineering

Abstract: Most programs today are written not by professional software developers, but by people with expertise in other domains working towards goals for which they need computational support. For example, a teacher might write a grading spreadsheet to save time grading, or an interaction designer might use an interface builder to test some user interface design ideas. Although these end-user programmers may not have the same goals as professional developers, they do face many of the same software engineering challenges, including understanding their requirements, as well as making decisions about design, reuse, integration, testing, and debugging. This article summarizes and classifies research on these activities, defining the area of End-User Software Engineering (EUSE) and related terminology. The article then discusses empirical research about end-user software engineering activities and the technologies designed to support them. The article also addresses several crosscutting issues in the design of EUSE tools, including the roles of risk, reward, and domain complexity, and self-efficacy in the design of EUSE tools and the potential of educating users about software engineering principles.

Cognitive dimensions of notations

Abstract: classificatory schemes need to be justified in concrete terms. The dimensions concept can be justified by pointing to areas where progress is slow, as I have done above; or by criticising existing systems; or by raising design issues in relation to present growth areas. Let’s take the last, and look at OOPS. Object-oriented systems have been praised as resolving some cognitive problems (Rosson & Alpert 1988), at least in principle. I take no issue with that, but are they adequately usable yet? A fundamental claim in this paper is that system = notation + environment. Research papers on OOPS, however, offer a myriad new languages, with different ideas about the semantics of inheritance, etc., but say very little about environments. Here are some questions arising from the preceding discussion, with remarks relating to one OOPS, Smalltalk-80. I shall take the five dimensions I have described in order. 1. Are there hidden dependencies and one-way links in the structure? Smalltalk-80 scores fairly well here; most relationships can be browsed in both directions, although there are times when it would nice to make dependencies more immediately visible without having to search for them, so that they could at as reminders. However, there is little support in searching for ill-specified targets. “I want something that handles a bitmap, what can I find?” Nor is it easy to find out what kind of object can fill an instance variable slot in a method. 2. If the inheritance hierarchy viscous, or is it easy to reconstruct in a different fashion? The inheritance structure lends to be viscous. For instance, given a class Animal with many sub-classes Trout, Herring, Minnow, etc.. inserting a new class Fish between Animal and its subclasses requires many operations (add a new subclass, Fish, to Animal; move Trout to Animal, etc.) Moreover, changing the inheritance hierarchy normally means changing the pattern of class and instance variables in the hierarchy — our new class, Fish, will contain information relevant to all its subclasses, and this information will have to he extracted from its previous position in the hierarchy and brought together under the new heading. 3. Is the generative order adequately decoupled? Not in Smalltalk-80, where inheritance hierarchies must be created top-down. We lack at present any published evidence on how Smalltalk programmers work, but experts have criticised this aspect in precisely the terms I would expect, namely that when designing the inheritance hierarchy the mental order in which steps are generated is not top-down, so that the effect of the environment’s insistence on top-down working is constrictive (Goldstein & Bobrow 1981; LaLonde 1987). LaLonde’s description is that the expert first designs a specific data type, by focussing on a useful set of operations, and then that data type is positioned in a logical hierarchy. 4. Is it role-expressive? Again, not adequately; although the purpose of object-oriented programming is to clarify relations between parts of programs, one finds that relationships between methods are obscure. The only browsers provided operate on

Learning to program = learning to construct mechanisms and explanations

Abstract: Teaching effective problem-solving skills in the context of teaching programming necessitates a revised curriculum for introductory computer programming courses.

Polymetric views - a lightweight visual approach to reverse engineering

Abstract: Reverse engineering software systems has become a major concern in software industry because of their sheer size and complexity. This problem needs to be tackled since the systems in question are of considerable worth to their owners and maintainers. In this article, we present the concept of a polymetric view, a lightweight software visualization technique enriched with software metrics information. Polymetric views help to understand the structure and detect problems of a software system in the initial phases of a reverse engineering process. We discuss the benefits and limits of several predefined polymetric views we have implemented in our tool CodeCrawler. Moreover, based on clusters of different polymetric views, we have developed a methodology which supports and guides a software engineer in the first phases of a reverse engineering of a large software system. We have refined this methodology by repeatedly applying it on industrial systems and illustrate it by applying a selection of polymetric views to a case study.