Stan Letovsky

Bio: Stan Letovsky is an academic researcher from Yale University. The author has contributed to research in topics: Documentation & Software system. The author has an hindex of 2, co-authored 2 publications receiving 212 citations.

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.

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

Software reconnaissance: mapping program features to code

Abstract: Maintainers of old code often need to discover where particular program features are implemented. This paper presents a method, called ‘software reconnaissance’ for answering this question through an analysis of the execution of different test cases. The method is quite easy to implement, requiring only a test coverage monitor, some simple tools, and a surprisingly small number of test cases. A statistical case study is presented that shows the kind of results that can be obtained on a typical medium-sized program. The method seems to be effective in identifying a small number of code components that are unique to a particular program feature, though it may not find all components that make up the feature's delocalized plan. A small protocol case study shows that professional programmers can learn to use the method quickly and can use the information that it produces. Software reconnaissance may be a simple but useful addition to the maintainer's tool kit in that it provides starting points for understanding a large program and a way of recovering some requirements traceability information from old code. For the researcher, it also provides a novel functionality ‘view’ of software that maps features to program components at different levels of precision.

LaSSIE: a knowledge-based software information system

Abstract: The authors discuss the important problem of invisibility that is inherent in the task of developing large software systems It is pointed out that there are no direct solutions to this problem; however, there are several categories of systems-relational code analyzers, reuse librarians, and project management databases-that can be seen as addressing aspects of the invisibility problem It is argued that these systems do not adequately deal with certain important aspects of the problem of invisibility-semantic proliferation, multiple views, and the need for intelligent indexing A system called LaSSIE, which uses knowledge representation and reasoning technology to address each of these three issues directly and thereby help with the invisibility problem, has been built The authors conclude with an evaluation of the system and a discussion of open problems and ongoing work >

Asking and Answering Questions during a Programming Change Task

Abstract: Little is known about the specific kinds of questions programmers ask when evolving a code base and how well existing tools support those questions. To better support the activity of programming, answers are needed to three broad research questions: 1) What does a programmer need to know about a code base when evolving a software system? 2) How does a programmer go about finding that information? 3) How well do existing tools support programmers in answering those questions? We undertook two qualitative studies of programmers performing change tasks to provide answers to these questions. In this paper, we report on an analysis of the data from these two user studies. This paper makes three key contributions. The first contribution is a catalog of 44 types of questions programmers ask during software evolution tasks. The second contribution is a description of the observed behavior around answering those questions. The third contribution is a description of how existing deployed and proposed tools do, and do not, support answering programmers' questions.

Intent specifications: an approach to building human-centered specifications

Abstract: This paper examines and proposes an approach to writing software specifications, based on research in systems theory, cognitive psychology and human-machine interaction. The goal is to provide specifications that support human problem solving and the tasks that humans must perform in software development and evolution. A type of specification, called intent specifications, is constructed upon this underlying foundation.