Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

David C. Littman

dblp:92/484 · DBLP profile ↗
← Back
5ranked-venue papers
3as first author
0since 2021 · last 1993
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 2 · 1 first-authorArtificial intelligence and machine learning · 1 · 1 first-authorSecurity and privacy · 1Graphics, computer vision, multimedia, augmented reality and games · 1 · 1 first-authorHuman-computer interaction and ubiquitous computing · 1 · 1 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Artificial intelligence
2 papers
Knowledge representation and reasoning · 100%
Interdisciplinary, comprehensive, and emerging computing
1 paper
Computing education · 100%
Human-computer interaction and pervasive computing
1 paper
User interface design and tools · 100%

Topics — the 2 heaviest of 4, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Knowledge, reasoning and agents › Knowledge representation and reasoning
knowledge engineering
0.011987
Modelling Human Expertise in Knowledge Engineering: Some Preliminary Observations · Int. J. Man Mach. Stud. 1987
Computing education
programming education
0.011986
An Analysis of Tutorial Reasoning about Programming Bugs · AAAI 1986

Methods — techniques the papers use, named apart from their topics

think-aloud protocol · 0.0empirical analysis · 0.0
YearPublicationVenuePosition
1993 Integration of formal and heuristic reasoning as a basis for testing and debugging computer security policy
abstract
Errors can arise in defining and evaluating computer security policy as well as in translating computer security policy into procedures.The effect of such errors in policy upon the secure operation of information systems can impose unacceptable levels of risk from the perspective of procurers and users of information systems.Relying on computer security paradigms based solely on formal methods makes it difficult if not impossible to detect and/or reason about certain classes of threats to computer security and vulnerabilities of information systems to these threats, especially for those aspects of information systems that are more readily amenable to modeling via non-formal methods.We present a paradigm integrating formal and heuristic reasoning as a basis for testing for and debugging computer security policy.To illustrate our approach, and to support our arguments, we consider the problem of reasoning about the plans of an agent who may be trying to compromise the security of an information system.
James Bret Michael, Edgar H. Sibley, David C. Littman
NSPW3
1993 The role of policy in requirements definition
abstract
Three significant challenges facing the discipline of software engineering are understanding how software designers reason about policy, understanding how they define requirements based on this reasoning, and providing machine-based intelligent tools that support reasoning about policy. The authors are developing the concept of a policy workbench: knowledge-based tools that support reasoning about such properties of policies as consistency, completeness, and correctness, and the implications of policy for the behavior of a system. They discuss how such a workbench might help software designers reason about the relationships between policies and requirements.>
Edgar H. Sibley, Richard L. Wexelblat, James Bret Michael, Michael C. Tanner, David C. Littman
RE5
1987 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.
David C. Littman
Int. J. Man Mach. Stud.1
1987 Mental models and software maintenance
David C. Littman, Jeannine Pinto, Stanley Letovsky, Elliot Soloway
J. Syst. Softw.1
1986 An Analysis of Tutorial Reasoning about Programming Bugs
David C. Littman, Jeannine Pinto, Elliot Soloway
AAAI1