E. Soloway and K. Ehrlich, Empirical Studies of Programming Knowledge, IEEE Transactions on Software Engineering, Vol. SE10, No. 5, pp 595-609, September 1984.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....Rico strategies required fewer cognitive elements to understand, and when programmers deviated from using these simpler strategies they made more errors. Soloway and Ehrlich later extended the idea of looping strategies into a more general programming comprehension model of goals and plans [11]. A plan is a canned solution for a certain type of problem. As programmers develop skills, they develop a repertoire of plans that they are able to append, nest, and merge with each other to solve problems. Plans can be seen as the mechanisms put into the computer to solve the problem. ....

Soloway, E. and Ehrlich, K. (1984). Empirical Studies of Programming Knowledge. IEEE Transactions on Software Engineering, SE-10, 5, pp. 595-609.

....Cliche recognition. Experienced programmers can rapidly recognize cliched patterns (see e.g. McKeithen et al. 403] Much of the research in relation to this ability has been concerned with the recognition of the so called programming plans [51, 241, 609, 707] and programming idioms [6,611]. However the findings probably generalize for all relevant recurrent structures (text structures, control flow structures [266] design patterns, architectural patterns, etc. As one would expect, these structures would need to be relevant to the programming language, and the programmer would ....

Soloway, E. M., and Ehrlich, K. Empirical studies of programming knowledge. IEEE Transactions on Software Engineering, SE-10(5), Sept. 1984, pp. 595--609.

....task. The software engineer must examine both the structural aspect of the source code (e.g. programming language syntax) and the nature of the problem domain (e.g. comments, documentation, and variable names) to extract the information needed to fully understand any part of a software system [7, 13, 31, 42, 45]. A number of tools and methods [1, 7, 8, 20, 27, 30, 41] have been investigated to address both of these aspects. In general, structural information is easy to extract, but the real problem is on how to utilize that information properly. Semantic information, on the other hand, is much more ....

Soloway, E. and Ehrlich, K., "Empirical Studies of Programming Knowledge", IEEE Transactions on Software Engineering, vol. 10, no. 5, September 1984, pp. 595-609.

....of functional abstractions in the source code can be seen as a particular problem of program segmentation. Segmenting a program means breaking it into chunks of code which are easier to manage. When the chunks relate to a unique functional behavior, they are the manifestation of programming plans [42]. While plans are abstract structures which programmers use as a programming template, the manifestation of plans in the programs is often delocalized [31] because they are realized by statements which are non sequential. The usefulness of a segmentation technique increases the more the plans are ....

E. Soloway and K. Ehrlich, "Empirical Studies of Programming Knowledge," IEEE Trans. Software Eng., vol. 10, no. 5, pp. 595-609, 1984.

....have serious limitations. Student s programs would have much more patterns than those maintained within a knowledge base. The second item is not a serious one. Almost all systems developed in the past are designed for a specific programming language such as Fortran[2] Lisp[5] and Pascal[4,7,10]. We can easily understand that most programming knowledge obtained through experiences of writing programs in a specific programming language such as Pascal is applicable in writing and reading programs in other languages such as C and Fortran. Most programming knowledge would be transformed in a ....

Soloway, E. and Ehrich, K., Empirical Studies of Programming Knowledge, IEEE Trans. on Soft. Eng., Vol.SE-10, No.5, pp.595-609, 1984.

....refinement through several levels of abstraction. The knowledge of experienced programmers is essentially having solutions to generic problems and how to apply them in particular situations. Empirical studies have shown that programming knowledge can be encapsulated as collections of derivations [SE84] To a certain extent, modern programming languages encourage programmers 11 to indicate levels of abstraction through the use of abstract data types and structured programming methods, but it is not always possible to express all the structure in the program text. The refinement paradigm is ....

Elliot Soloway and Kate Ehrlich. Empirical studies of programming knowledge. IEEE Transactions on Software Engineering,SE- 10(5):595--609, 1984.

....similar enough to a previous situation in which information X was used, then it is highly possible that information X is also needed in the current situation. Software developers often use meaningful comments and identifier names to communicate the concept or the functional purpose of programs [1, 29, 40]; doc comments of Java are specifically introduced for that purpose. Other self revealing information includes the signatures of modules that define the types of input and output data [47] Therefore, the relevance of a component to the task at hand can be determined by the conceptual similarity ....

....characterization is similar to the 3C model of Tracz [41] who uses concept, content, and context to describe a component. Important concepts of a program are often contained in its informal information structure. Informal information includes structural indentation, comments, and identifier names [40], which are important beacons to understanding programs [1, 28, 29] One important constraint of a program is its type compatibility, which is manifested in its signature. For a reusable component to be easily integrated, its signature should be compatible with the environment into which it is ....

Soloway, E., and Ehrlich, K. Empirical Studies of Programming Knowledge. IEEE Trans. on Software Engineering, 1984. SE-10(5): 595-609.

....maintenance cycle of a software system and its source code can be helpful in a number of tasks. A few notable examples are: Program comprehension; existing cognition models share the idea that program comprehension occurs in a bottom up manner, a top down manner, or some combination of the two [30, 6, 37, 26]. Tracing areas of code to related sections of an application domain handbook, to a set of design documents, or to manual pages, supports both top down and bottom up comprehension. In top down comprehension it provides hints on where to look for beacons that either confirm or confute a hypothesis, ....

E. Soloway and K. Ehrlich. Empirical studies of programming knowledge. IEEE Transactions on Software Engineering, SE-10(5):595--609, 1994.

....page 3 of 11 the results. Eliott Soloway, for instance, tried for years to model novice programmer s errors in order to make skilled debuggers or Intelligent Tutoring Systems able to remediate programming misconceptions(e. g: [8]) One of those misconceptions may originate thousands of errors in the millions of lines of Ada code for the US DoD. The work was hard, and not really supported; it was stopped in spite of the encouraging results around PROUST. We were not interested in the Communication component of the Wiener ....

Soloway, E., Ehrlich, K. (1984) Empirical Studies of Programming Knowledge, IEEE Transactions on Software Engineering, Sept.

....programmers ability to comprehend programs [7] This observation has prompted several researchers to investigate the processes involved in understanding programs. Of interest to this paper are works from two disparate communities: academic researchers in computer science and psychology, such as [1, 3, 18, 19], and practitioners and managers in the industry, such as [22, 23, 25] The papers [3, 18] propose theoretical models of cognitive processes involved in program understanding. These models have been subjected to experimental analysis by other researchers [9, 20] The experiments are typically ....

E. Soloway and K. Ehrlich. Empirical studies of programming knowledge. IEEE Trans. Softw. Eng., SE--10(5):595--609, Sept. 1984.

....comprehension meta model consists of (1. Program model, 2. Top down model, 3. Situation model, 4. Knowledge base. Code Size Subjects Language Experimental Reference Purpose Expertise Method Understand 15 LOC 94 Novice Pascal Cloze Test Soloway (Module) 45 Grad (Fill in blank) Ehrlich [9] Students Understand 12 42 LOC 10 Novice Pascal Cluster Analysis Rist (Module) 7 Grad [6] Students Understand 15 LOC 80 Experts 50 Cobol Free recall Pennington (Module) Professional 50 Fortran Response time to [5] Comprehension Questions Understand 20 LOC 52 Novice Fortran Strict ....

....LOC 11 Experts Procedural Protocol Analysis von Mayrhauser Corrective, Module Sys) Professionals (e. g C, C Vans [12, 13] Adaptation, shell,etc) Enhancement Table 1: Comprehension Experiments The basis for the top down (also known as Domain model) component is Soloway and Ehrlich s [9] topdown model while Pennington s [5] program and situation models are reflected in the program and situation model components of the meta model. These three model components reflect mental representations and the strategies used to construct them. They represent views of code at various levels of ....

Elliot Soloway and Kate Ehrlich, "Empirical Studies of Programming Knowledge", In:IEEE Transactions on Software Engineering, Vol. SE-10, No. 5, pp. 595-609, September 1984.

....from the repository that has high similarity to the contextual circumstance is then delivered. Systems like Remembrance Agent [19] and Letizia [12] fall into this category. In the case of reusable component location, a goal acquisition approach will be similar to the recognition of a program plan [23]. It needs to recognize program plans from the program under development, and deliver reusable components that can be used to realize the recognized program plans. Recognition of program plans from complete programs are extremely difficult, let al..one from partially constructed programs. Therefore, ....

....development is essentially a cooperative process among many software developers. Programs include both formal information for executability and informal information for readability by peer software developers. Informal information includes structural indentation, comments, and identifier names [23]. Comments and identifier names are important beacons for the understanding of programs [4, 14] Modern programming languages such as Java enforce the inclusion of self explaining informal information further by introducing the concept of doc comments. A doc comment begins with and continues ....

Soloway, E. and K. Ehrlich, "Empirical Studies of Programming Knowledge," IEEE Trans. on Soft. Eng., SE10 (5), pp. 595-609, 1984.

....of program understanding and thus maintenance. The first step in satisfying a maintenance engineer s information needs is to define a model of how programmers understand code. For years, researchers have tried to understand how programmers comprehend programs [1, 2] 8] 12, 13] 15] [16, 17]. The literature provides two approaches to comprehension: cognitive models that emphasize cognition by what the program does (a functional approach) and a controlflow approach which emphasizes how the program works. Chapin s Software Maintenance Life Cycle [3] divides maintenance into sub tasks ....

....that all code is understood at the same level of thorough detail. For large size software this does not seem feasible nor desirable and we need a better model to understand code cognition in an industrial setting. To this end we investigated two existing comprehension models: Soloway Ehrlich [16, 17] which is a top down comprehension model, and Pennington s [12, 13] control flow and functional program understanding models (a bottom up comprehension model) Each model contains a process that programmers use for comprehension, the pieces of information or knowledge which is input to these ....

[Article contains additional citation context not shown here]

Elliot Soloway and Kate Ehrlich, Empirical Studies of Programming Knowledge, In: IEEE Transactions on Software Engineering, September 1984, Vol. SE-10, No. 5, pp. 595-609.

....allows writing program specification with FPL icons. Each FPL icon represents one programming construct. Cunniff et al. 1986) concluded that FPL performed equally well as Pascal in some bug types but much better in others. Experts and novices use programming plans to accomplish programming tasks (Soloway and Ehrlich 1984; Rist 1986) These plans are . program fragments that represent stereotypic action sequences in programming . Soloway and Ehrlich 1984) Therefore a language such as BridgeTalk (Bonar and Liffick 1990) that allows specifying programs by using programming plans takes a more natural approach ....

....FPL performed equally well as Pascal in some bug types but much better in others. Experts and novices use programming plans to accomplish programming tasks (Soloway and Ehrlich 1984; Rist 1986) These plans are . program fragments that represent stereotypic action sequences in programming . (Soloway and Ehrlich 1984). Therefore a language such as BridgeTalk (Bonar and Liffick 1990) that allows specifying programs by using programming plans takes a more natural approach and hence imposes less cognitive load on users than conventional languages. Each icon in BridgeTalk looks like a piece in a jigsaw puzzle and ....

Soloway, E. and Ehrlich, K. (1984), Empirical studies of programming knowledge. IEEE Transactions on Software Engineering, 10(5), 595-609.

.... cognitive components [14] What will these cognitive structures be Historically, it has been proposed that Pascal novices think in terms of plans , groups of statements that typically consume some data, operate upon on it in some characteristic way, and produce results for use by another plan [27] [29] there is some empirical evidence to support this proposal, although the plan is at best only one of the possible cognitive structures that programmers may employ. e.g. Pennington [28] demonstrated that text st ructures were also relevant; Gilmore and Green [7] demonstrated that ....

Soloway, E. and Ehrlich, K. (1984) Empirical studies of programming knowledge. IEEE Transactions on Software Engineering, SE-10, 595-6

....mental representations of programs are not well understood. Historically, it has been proposed that Pascal novices think in terms of plans , groups of statements that typically consume some data, operate upon on it in some characteristic way, and produce results for use by another plan (Soloway and Ehrlich, 1984; Rist, 1986) there is some empirical evidence to support this proposal, although the plan is at best only one of the possible cognitive structures that programmers may employ. e.g. Pennington, 1987, demonstrated that text structures were also relevant; Gilmore and Green, 1988, demonstrated ....

Soloway, E. and Ehrlich, K. (1984) Empirical studies of programming knowledge. IEEE Transactions on Software Engineering, SE-10, 595-609.

....stumbling blocks for novices learning to program. Rather, the real problems novices have lie in putting the pieces together, composing and coordinating components of a program [35, 36] Expert programmers know a great deal more than just the syntax and semantics of language constructs (e.g. [2, 5, 13, 18, 27, 31]. They have built up large libraries of stereotypical solutions to problems as well as strategies for coordinating and composing them. Students should be taught explicitly about these libraries and strategies for using them. Teaching programming in schools is a particularly hot topic now: On the ....

....that violate the rules of discourse are often very difficult to comprehend. In fact, in a recent study, the performance of advanced programmers was reduced to that of novice programmers when the advanced programmers were asked to deal with programs that violated various rules of discourse ([31]) Simulation: Making Explicit the Dynamic Properties of a Program Although stepwise refinement and plan composition methods deal with putting pieces of solutions together, the resulting solution must in fact do what it is supposed to do. That is, the former three strategies deal with plans as ....

Soloway, E., and Ehrlich, K. Empirical studies of programming knowledge. IEEE Trans. Softw. Eng. SE-10, 5 (1984), 595-609.

No context found.

E. Soloway and K. Ehrlich, Empirical Studies of Programming Knowledge, IEEE Transactions on Software Engineering, Vol. SE10, No. 5, pp 595-609, September 1984.

No context found.

E. Soloway and K. Ehrlich. Empirical studies of programming knowledge. IEEE Transactions on Software Engineering, SE-10(5):595--609, September 1984.

No context found.

E. Soloway and K. Ehrlich. Empirical studies of programming knowledge. IEEE Transactions on Software Engineering, SE-10(5):595--609, 1994.

No context found.

E. Soloway and K. Ehrlich, `Empirical studies of programming knowledge', IEEE Transactions on Software Engineering, SE-10, 595--609 (1984).

No context found.

Soloway, E. and Ehrlich, K. "Empirical Studies of Programming Knowledge." IEEE Transactions on Software Engineering, SE-10:9, 1984.

No context found.

Soloway, E. and Ehrlich, K. "Empirical Studies of Programming Knowledge." IEEE Transactions on Software Engineering, SE-10:9, 1984.

No context found.

Elliot Soloway and Kate Ehrlich, Empirical Studies of Programming Knowledge, In: IEEE Transactions onSoftware Engineering, September 1984, Vol. SE-10, No. 5, pp. 595-609.

No context found.

Soloway, E. and Ehrlich, K. Empirical Studies of Programming Knowledge, IEEE Transactions on Software Engineering, SE-10(5), September 1984.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC