Visualisation Research Group
Centre for Software Maintenance
Department of Computer Science
University of Durham
28 May, 1996
Program comprehension is widely recognised as the main activity within many software maintenance or even software development tasks. Particularly within software maintenance activities program comprehension is the vital first task of any maintenance, whether it be adaptive, perfective, corrective or preventative. Despite being such a key activity, program comprehension has not received much research activity until relatively recently with work from a number of key authors. This initial flurry of activity has since receded and again research into program comprehension has made little major progress.
This document summarises a selection of the key theories developed in program comprehension and highlights any commonalities between them. Throughout the document the term maintainer will be used wherever possible to describe the person performing the comprehension task. The reason for this choice over the more popular term programmer is due to the almost monopoly position which software maintenance has on program comprehension activity. Thus, the term maintainer removes the generality and places program comprehension within it’s typical context. Another terminology issue is the use of the terms cognitive model and mental model. Within this document, the term mental model will refer to the maintainer’s internal (mental) representation of the software or results of the comprehension process. The term cognitive model will refer to the complete set of processes, knowledge, heuristics and mental model used during program comprehension. Thus it is the cognitive model which is the subject of the various theories and the focus of this document. This document will now give an overview of the key theories developed in program comprehension. This will begin by highlighting and defining any commonalities, standard terms or standard concepts. This will be followed by a more detailed summary of each of the theories proposed by the various authors.
Mayrhauser [Mayrhauser95] identifies a commonality between the various program comprehension theories. This commonality exists in the software engineers’ cognitive model, and to some extent in the way the model is created and maintained. All the comprehension theories agree that the program comprehension process uses existing knowledge coupled with a comprehension strategy in order to acquire new knowledge. This new knowledge should, through a process of additions and revisions eventually achieve the required level of understanding of the code. The various comprehension strategies used in obtaining this new knowledge have a commonality in that they all formulate hypotheses which can then be refined, revised or rejected. Formulating and verifying these hypotheses makes use of both existing knowledge and the newly acquired knowledge.
The three main components in the cognitive model are the knowledge base, mental model and assimilation process. The knowledge base, which has already been described briefly, contains the maintainers’ understanding of the domain and any related fields. The mental model which is different from the cognitive model, is the maintainers’ internal representation of the program. Within this document the term mental model will be used to describe this internal representation, whereas the term cognitive model will be used to described the overall cognitive system or process used in program comprehension. Finally, the assimilation process is the glue which binds the knowledge base to the mental model, manipulating both to create and revise hypotheses which can then be used to update the knowledge base or mental model. The actual processes involved in this assimilation are the subject of the various theories of program comprehension.
The three main components of the cognitive model will be described in greater detail here:
The knowledge base consists of both existing knowledge and newly acquired knowledge. This knowledge will also consist of two general types, general knowledge and task-specific knowledge. During the comprehension process, the maintainer will obtain more task-specific knowledge, but may also require additional general knowledge which will typically be obtained on an ‘as-needed’ basis. The general knowledge represents information not specifically related to the software itself. Such knowledge could include experience with programming languages, understanding of the implementation platform, or even knowledge of the operational domain of the software for example business rules, control systems or database systems. Task specific knowledge is directly related with the comprehension task and will include knowledge such as design information, programming styles used and overall goals of the program.
Existing knowledge and general knowledge are strongly related, with the majority of existing knowledge being non-task related. However, if the maintainer has prior knowledge of the program then the existing knowledge will contain any fragments of task-specific information related to the program, including any mental models of the software. In contrast, new knowledge is oriented more towards task specific knowledge which is gleaned during the comprehension process. This new knowledge could include information on control flow, data flow, software structure, implementation details or styles, etc. New knowledge can be obtained at any abstraction level and can range from low level implementation details to higher level structural information.
Various authors offer their own interpretations of the knowledge base and how it is arranged, these will be discussed later.
The mental model is the maintainers’ internal representation of the program and can be composed of a number of inter-dependent semantic constructs. The various theories of program comprehension proposed offer a wide variety of forms for these semantic constructs. These constructs include text structures, chunks, plans, hypotheses, beacons, and rules of discourse. The mental model is continuously updated and amended by the assimilation process. Mayrhauser [Mayrhauser95] identifies the dynamic process used in creating these semantic constructs as a combination of behaviours such as strategies, actions, episodes, and processes.
Text structure constructs are formed from the program source code and its structure. The structure of the program text can be derived in two forms. In well presented or styled code, an initial structure can be derived from the text layout, using indentation, comment blocks or blank areas to identify textual chunks. This initial structure can then be refined further to give it a more syntactic meaning such as function blocks, iteration blocks, conditional constructs, etc. Organisation of text structures within the mental model can include nesting and dependencies. For example, an iteration block may be nested or contained within a function block, and two function blocks may be related by a function call.
Chunks are syntactic or semantic abstractions of text structures within the source code. Shneiderman [Shneiderman80] describes a process in which maintainers abstract portions of the source code (text structures) into chunks. Collections of these chunks can then be abstracted further into higher level chunks. Chunks can be constructed from either semantic or syntactic knowledge and need not be fully understood or identified immediately, being returned to at later time for revision. It seems a reasonable assumption to say that typically a chunk formed on the basis of syntactic knowledge, a syntactic chunk, will be revised later to form a semantic chunk. For example, a syntactic chunk derived from a function block or a nesting level will be revised later with semantic meaning or purpose, such as a sort algorithm.
Plans, best described by Mayrhauser [Mayrhauser95], are “knowledge elements for developing and validating expectations, interpretations, and inferences”. Plans, otherwise known as clichés or schemas, are derived from research by Soloway and Ehrlich [Soloway84] which attempted to apply theories from text comprehension to program comprehension. The notion of plans proposed by Soloway and Ehrlich corresponds directly to the notion of schemas in text comprehension, where schemas are “generic knowledge structures that guide the comprehender’s interpretations, inferences, expectations, and attention when passages are comprehended” [Graesser81]. Similarly, plans in the context of program comprehension also capture the maintainers’ attention during the comprehension process.
Mayrhauser describes plans as belonging to two categories, slot types and slot fillers. Slot types can be thought of as generalised templates which the maintainer can apply to a number of specific problems to create slot fillers. Slot fillers are specific to a particular problem. Slot types can thus be thought of as an abstraction of a possibly infinite collection of slot fillers. An example of a slot type could be a function such as a sort routine, whereas a slot filler could be a particular implementation of a sort routine, for example a quick sort. Slot fillers are related to slot types via either a Kind-of or an Is-a relationship.
Plans can be further categorised into programming plans and domain plans [Mayrhauser95]. A simple analogy can be drawn between these types of plan and the knowledge contained within the knowledge base. Programming plans, analogous to task specific knowledge, are plans specific to the task in hand. They can exist at a variety of abstraction levels, ranging from the low-level program code to the abstract function of the program as a whole. Domain plans, analogous to general knowledge, are plans which incorporate all other knowledge of the problem area excluding that contained within the program plans (i.e. the detail of the software). Domain plans give a general concept of the task and how it can be completed. These generally exist at a higher level of abstraction than the actual software system.
Hypotheses are introduced by Brooks [Brooks83] in a paper which suggests how programmers use an iterative, hierarchical method of forming, refining and possibly rejecting hypotheses at varying levels of abstraction during the comprehension process. Brooks states that the program comprehension process is complete when the maintainers’ mental model contains a complete hierarchy of correct hypotheses. This hypothesis hierarchy is described as a bridge between the various domain levels of the problem, the complete model thus bridging from the high level ‘This program is a ...’ hypothesis to the low level hypotheses regarding implementation details. The program comprehension process using hypotheses will be described in greater detail below.
Letovsky [Letovsky86a] investigates the use of hypotheses further in an experiment involving the study of maintainers undergoing a given comprehension task. Letovsky refers to hypotheses as conjectures and describes the mental processes of the maintainers as they create, question and revise these conjectures. Conjectures are associated with a degree of certainty which affects the way in which they are revised or discarded at a later stage. The level of certainty can range from a guess to complete certainty. From the study, Letovsky identifies three main types of conjecture:
The assimilation process is the method which the maintainer uses in undergoing the comprehension task. This process makes use of the mental model and the knowledge base, in conjunction with the source code and any related documentation, to build upon or revise the mental model and thus the maintainer’s understanding of the program. The exact assimilation process used by the maintainer is the subject of a number of research papers which will be discussed in greater detail below. A number of methods or processes can be identified which contribute to the assimilation process and belong to a number of the comprehension theories. Mayrhauser [Mayrhauser95] classifies these as being dynamic elements of the mental model, however they appear more fitting as a process by which the mental model is created. Before describing these processes, two features which aid in facilitating them, beacons and rules of discourse, will be described.
Beacons, first identified by Brooks [Brooks83] then explored further by Wiedenbeck [Wiedenbeck86,91], are recognisable or familiar features within the source code or other forms of (possibly higher level) knowledge. Beacons thus act as cues to the presence of certain structures or features and can be used in either the verification or creation of hypotheses. Brooks’ well cited example of a beacon is the swapping of two variables which could be a beacon for a sorting routine. Even at a higher level, beacons such as the name of a particular procedure or source module are equally valid and useful information. Beacons are used in gaining a higher level of understanding than that in which the beacon occurs, i.e. abstracting from a code chunk to a process or function.
Rules of discourse, as identified by Soloway and Ehrlich [Soloway84], are rules or conventions within programming such as code presentation or naming standards. For example one rule of discourse is that a variable name should usually agree with it’s function. Rules of discourse set up expectations in the mind of the maintainer. These expectations can be very powerful, allowing the pre- fetching of knowledge from long term storage, though they can also be problematic if discourse rules are violated. Soloway and Ehrlich [Soloway84] describe an experiment which shows that comprehension performance is greater for programs which obey the rules of discourse (plan-like programs). Conversely the study also shows that when the rules of discourse are violated, then comprehension performance is hampered, both for expert and novice maintainers. This implies that unconventional algorithms, unusual data structures or unexpected use of a known algorithm as well as unconventional programming styles will render programs more difficult to comprehend.
Strategies define the sequence of actions performed by a maintainer while following a plan to achieve a particular goal. Littman et al. [Littman86] identify two such strategies, the systematic strategy and the as-needed strategy. These two strategies are defined within the context of comprehending an entire program, hence the systematic approach attempts to comprehend the program as a whole before any attempt at maintenance is made. The as-needed approach attempts to localise the comprehension process to only the areas of the program which must be understood to perform the maintenance task. These will be discussed further below.
Two comprehension mechanisms which are aided by strategies are chunking and cross- referencing. The chunking process creates new, higher level chunks from lower level structures or chunks. As structures at the lower level are recognised they are abstracted into a chunk and labelled. These labels can then be used again in forming new, higher level chunks. An example of the chunking process could be the formation of the ‘bubble sort’ chunk from iteration, comparison and variable swapping chunks. Cross-referencing forms relations between different abstraction levels by mapping program parts to functional descriptions. Cross-referencing is essential to building a mental representation spanning a number of abstraction levels.
This section attempts to give a summary of the most notable program comprehension theories proposed by various authors. These theories vary significantly, yet they all relate to the above outline of the cognitive model to some degree. That is, they all subscribe to the idea of a knowledge base, mental model and some form of assimilation process. The exact representation and formation of these components does however vary throughout the theories.
Brooks [Brooks83] proposes a theory for program comprehension based on a number of domains existing through the comprehension model. The theory argues that program comprehension is complete when a complete set of mappings can be made from the top level domain (problem domain) to the bottom level domain (programming domain). The developer of the software initially produces these mappings, whereas the maintainer must recover them.
Brooks identifies two types of information which must be obtained in order to reconstruct these mappings. Intra-domain knowledge will contain information about the objects within each domain. This will include their properties and relationships, operations which can be performed on them and the sequence in which these operations are applied. Inter-domain knowledge will contain information about relationships between objects and operators occupying neighbouring domains. Brooks highlights that these relationships are generally not one to one, and new operations in one domain may be built up from both objects and operators in a previous domain. An example could be a sort routine in an algorithm domain which would map onto a series of statements (operators), variables and functions (objects) in the programming domain.
Brooks’ mental model is constructed in a top-down manner through a hierarchy of hypotheses, as opposed to the more usual idea of a bottom-up process beginning at the source code [Shneiderman79, Basili82]. Robson et al. [Robson88] miss-interpret this model and see it as a bottom-up approach which works from the source code using beacons to form initial hypotheses. Brooks’ theory asserts that the primary hypothesis will be formed as soon as the maintainer obtains any information about the task that the program performs. This information can be as little as the program name, or a short description of it’s function. The level of detail of the primary hypothesis is obviously dependent on the task and the maintainer, though it will generally specify the global structure of the program with respect to inputs, outputs, and major data and processing constructs. No matter how weak the initial hypotheses are, they may be of considerable aid in further comprehension of the program.
Hypothesis generation in Brooks’ model relates strongly to the program writing tasks involved in creating a piece of software. Earlier work by Brooks [Brooks77] proposed a model for this writing process, one property of which was the use of learned patterns or structures in moving top-down from the problem domain to the program domain. Brooks thus sees the program writing process as retrieving known structural units with varying granularity, to fit a particular aspect of the problem, then assembling and possibly modifying them into programs. He sees the hypothesis generation process used in his comprehension theory as retrieving the same units and using these as the formation of further hypotheses. Obviously, these structures will undergo far less assembly and modification, typically sufficient to result in a hypothesis which can be verified against the code. This process is heavily dependent on the maintainer’s knowledge of the problem domain. Weak knowledge of a particular feature implemented in the code, for example an unusual sorting routine, will result in problems in verifying hypotheses.
Brooks proposes that hypotheses are formed in a top-down, breadth-first manner and descent of this hierarchy is terminated when the lowest level hypotheses can be verified against the code. This verification occurs when the operations or data structures specified in the hypotheses can be associated with features or details visible in the code or documentation. Brooks then identifies the notion of beacons which are used in this verification. He also states that beacons can themselves lead to generation of subsidiary hypotheses or more rapid verification of later hypotheses. When the comprehension process is complete a hierarchy of hypotheses will exist with the primary hypothesis at the top and subsidiary hypotheses below. Each subsidiary hypothesis will be bound to a segment of the program code, with no un-bound sections of code remaining.
Shneiderman and Mayer [Shneiderman79] propose that program comprehension is based upon two forms of programming knowledge, syntactic and semantic. They further categorise this into three main types of knowledge, syntactic knowledge, general semantic knowledge, and task related semantic knowledge.
The maintainers’ syntactic knowledge contains details of the domain in which comprehension is to take place. This knowledge will include syntactic details of the programming language used such as keywords, language syntax and available library routines in addition to other relevant areas of the problem domain such as hardware specific details. Syntactic knowledge grows with experience but will typically also fade with lack of use.
The general semantic knowledge of the programmer consists of more general concepts of programming which are not necessarily domain specific. The semantic knowledge may consist of both high level concepts such as tree traversal algorithms, or low-level concepts such as the semantic meaning of programming constructs, for example the FOR...NEXT loop. The maintainer will also possess task related semantic knowledge which relates directly to the problem domain. This knowledge could be quite specific such as the semantic meaning of various program portions, or more general such as knowledge of the environment within which the program resides, for example knowledge of accountancy or medicine. The authors argue that the comprehension process involves the application of syntactic knowledge to create a semantic model of the program.
The maintainer's semantic model of the program may consist of either high-level representations or low- level representations, or both. The former favours a top-down approach to comprehension where the maintainer has a general view of the program structure or purpose and must then discover the low-level details of how it operates (similar to Brooks’ theory). The low-level representation favours a bottom-up approach in which the maintainer attempts to discover the structure or intent of higher level program entities from the low-level implementation details. Shneiderman and Mayer see the program comprehension task as predominantly unidirectional, starting with the program code and continuing in a bottom-up manner until the problem statement is recovered.
Shneiderman in later work [Shneiderman80] describes an information chunking process employed by maintainers during program comprehension. Programmers abstract portions of the source code into chunks, collections of chunks being abstracted further into higher level chunks. Chunks can be constructed from either semantic or syntactic knowledge and need not be fully understood or identified immediately, being returned to at later time. It seems a reasonable assumption that typically a chunk formed on the basis of syntactic knowledge, a syntactic chunk, will be revised later to form a semantic chunk. For example, a syntactic chunk derived from a function block or a nesting level will be revised later with semantic meaning or purpose, such as a sort algorithm.
Letovsky [Letovsky86a] performed an empirical study of programmers attempting to perform a maintenance operation on unfamiliar code. The maintenance task required the maintainers to first obtain an understanding of the code structure and operation then plan the appropriate modifications. The study concentrated on the program comprehension task and attempted to trace the subjects thought processes by encouraging them to "think aloud".
Analysis of the study results concentrated on two recurring behaviours in which the subjects asked questions then conjectured answers. Letovsky proceeded to create a taxonomy of both questions and conjectures then to define his interpretation of the maintainers' cognitive model.
The cognitive model suggested by Letovsky was subdivided into three components, namely a knowledge base, a mental model and an assimilation process. The knowledge base encapsulates the experience and expertise of the programmer, including syntactic knowledge and more generally, problem domain knowledge. The mental model represents the maintainers' internal representation or conception of the program and is further subdivided by Letovsky into the specification, implementation and annotation layers. These layers contain the high-level abstract view of the code, the low-level implementation details, and any known mappings between the two, respectively. Finally, the assimilation process pulls on the knowledge base and any available external help such as the source code or documentation in order to generate and update the mental model. Letovsky suggests that this assimilation process can occur either as bottom-up or top-down where the bottom level is the source code and the top level is the most abstract view of the program. It is also suggested that the maintainer may switch between these techniques in an opportunistic manner, selecting whichever is appropriate at the time to gain the highest return in knowledge gain.
Littman et al. [Littman86] state that program comprehension is based on two distinct strategies, the systematic strategy and the as-needed strategy. This conclusion stems from the results of monitoring the behaviour of a number of expert programmers given a maintenance task to perform upon a small program. From this study they also conclude that the comprehension strategy used strongly influences their resulting knowledge of the program. In addition, they discovered that the extent of a maintainers' knowledge of the program directly determines their ability to perform successful modifications. A programmers choice of systematic or as-needed strategy is dependent on the extent to which they want to understand the program.
The systematic strategy is used when the programmer wants to obtain a full understanding of the program operation before commencing the modifications. This strategy includes extensive studying of both the static and dynamic aspects of the program to obtain an understanding of both the program structure and any causal interactions among program components. This approach is costly in comprehension time but will enable the maintainer to make a more rapid and confident modification.
The as-needed strategy enables the maintainer to minimise on comprehension time by concentrating on the program areas which are likely to require change. The maintainer will immediately attempt to localise areas of code which may require change in order to perform the correct maintenance. Once this initial understanding of the code is obtained, the maintainer will typically proceed to perform the maintenance operation. During maintenance the maintainer will typically require additional information and will then investigate further on an as-needed basis. There is thus no guarantee that the maintainer will gain a full understanding of the causal relationships or dependencies between program components and it is unlikely that they will detect unforeseen impacts of their modifications.
Conclusions which are drawn from the use of these strategies are that the systematic approach requires more time during the comprehension stage of maintenance but results in a strong cognitive model of the program. This model includes static and structural information, but more importantly also includes information on the dependencies and causal interactions between program components. In contrast, the as- needed approach requires less comprehension time but will result in a weaker and incomplete cognitive model. The model will include static information and some structural information, but will generally lack any knowledge of the dependencies or causal interaction between components. It is obvious that these two strategies can only be compared for use on small programs. Program size can rapidly surpass the capability of a single person to obtain a full understanding of it's operation, hence the systematic approach is redundant. However, it may still be possible to subdivide the program into more manageable sections with which the systematic approach may be applied to each section. In the case of large programs, both the as- needed and systematic strategies suffer to sheer volume of information.
Soloway and Ehrlich [Soloway84] describe a study to evaluate the use of programming plans and rules of discourse in expert programmers. Their view is that programs are composed from programming plans which have been adapted to meet the needs of the specific problem. They also believe that these plans are composed in accordance with the rules of programming discourse. They believe that the ease or difficulty with which comprehension can take place is dependent on the extent with which the rules of discourse were obeyed. Programs in which the rules of discourse have been followed (plan-like programs) will generally be easier to understand or maintain than those in which the rules are violated (unplan-like programs).
Their study also aimed to investigate the differences between novice and expert programmer performance when confronted with both plan-like and unplan-like programs. They believed that the experts would perform much better than the novices on plan-like programs due to their experience and expectations of the rules of discourse. Conversely, on unplan-like programs they expected that the performance of expert programmers would drop to the level of the novices. The reason for this being that the experts would be confused by the rule violations, whereas the novices would be less sensitive to them as they have lesser knowledge, and hence lower expectations of the rules of discourse. The results of the study supported this theory and highlighted the fact that expert programmers form strong expectations about program structure and style. When these expectations are violated their performance drops greatly.
In later work, Letovsky and Soloway [Letovsky86b] performed a ‘think aloud’ experiment in which a number of expert maintainers were observed adding a new feature to an existing software system. The authors identify the fact that maintainers are typically under pressure to perform a task, and are normally subject to time constraints. They believe that this results in the maintainer concentrating their attention on localised areas of the code which they believe are required to perform the maintenance task (similar to the as-needed strategy of Littman et al.). When the documentation or the program code do not highlight any remote dependencies these can often be missed by the maintainers’ focused attention and thus may result in an inaccurate understanding of the program as a whole. This in turn may lead to inaccurate or inefficient modifications to the program.
Letovsky and Soloway describe these ‘loose’ dependencies as delocalised plans. Delocalised plans are programming plans which are implemented in a distributed manner throughout the program. The results of the study highlight the problems which delocalised plans cause in the program comprehension task.
Soloway, Adelson and Ehrlich [Soloway88] propose a top-down model of comprehension which is based on the notion of programming plans. This model pulls to some degree on the ideas of Brooks [Brooks83] in that the top-down comprehension model is constructed from an overall idea of the program function. This is however only feasible if the maintainer has had previous experience with a similar task. The model proposed by the authors uses three types of plans: strategic, tactical, and implementation. Strategic plans specify language-independent actions or algorithms and describe a global strategy used in programs or algorithms. Tactical plans are localised strategies used in problem solving which generally describe a particular algorithm, function or process. Finally, implementation plans contain actual source code segments and provide the mapping from the tactical plans to the source code, they perform the actual implementation. The mental model used in this theory is constructed in a top-down manner using a hierarchy of goals and plans. Beacons and rules of discourse are used in mapping from goals to plans, and in forming lower level plans.
Basili and Mills [Basili82] describe an experiment in which they attempt a program comprehension task upon an unknown program without any form of documentation other than the code itself. Although the authors to not propose a theory or cognitive model, the paper is of interest as it describes a study of the comprehension process and places the emphasis not on the actual understanding of the code, but in the capturing or recording of this understanding. This is a vital concept particularly in the task of redocumentation or in recording knowledge gained to aid future maintenance. The method used was to simulate a programmer within a maintenance environment using techniques of program design but adapted for program understanding. The programmer was thus given a program and the task of developing a specification and correctness proof from it.
The authors take the view that the actual process of program understanding is of equal importance to being able to capture or record this understanding. Their reasoning is that a lot of the comprehension effort is repeated due to the loss or poor communication of previously found information. The authors believe that being able to derive a program specification, and in particular a correctness proof is vitally important to both the comprehension and maintenance tasks.
The authors' technique follows a bottom-up approach in that the low-level detail of the program is discovered first, with more abstract or high-level functionality being discovered from this. Their technique thus operated at a number of levels. Initially, simpler parts of the program were reduced into primes using direct cognition. Small looping structures were simplified by the identification of loop invariants. At a higher level, these small program primes are organised into functional segments, the operation of which is determined by further analysis. This process is performed a number of times, obtaining a higher level understanding of the program at each stage until a full specification is achieved.
This document has presented a number of key theories developed for program comprehension. These theories vary to different degrees, yet all maintain a high level commonality or structure in the cognitive model. This commonality can be summarised in that all theories subscribe to the idea of the cognitive model being composed of a knowledge base, mental model and assimilation process. The interpretation and composition of each of these components is the subject of the various theories.
It is well known that program comprehension plays a major part in the majority of software engineering activities, particularly in software maintenance. The level of program comprehension required can vary greatly depending on the task and the complexity, quality and size of the target system. Similarly, program comprehension is not limited solely to extracting information from the source code only. Any forms of system documentation or previous maintenance records are used as an integral part. However, more often than not this documentation will be inaccurate, inconsistent, incomplete or even non-existent. This leaves the maintainer with the complex task of attempting to recover not only the operation and structure of the software system, but many design issues and implicit assumptions made during it’s implementation. All this information being recovered from the source code alone. Clearly this is a non-trivial task. Program comprehension research is thus vital to discover methods or tools which could aid maintainers to recover the intentions behind the code.
It can be seen from the theories described in this document that although the actual comprehension process can be observed, described and predicted, what is really needed are tools to aid or supplant this process. This aid could affect any or several of the main areas of the cognitive model. Systems or databases could extend the maintainers knowledge base. Visualisation or automated program comprehension tools could enable swifter construction or verification of the mental model. Sophisticated searching and cross- referencing mechanisms could aid the assimilation process by integrating other tools. Suffice to say that there is a large scope for automation and computer supported work in program comprehension tasks, and more generally in software maintenance.
This page is maintained by Peter Young, please send any comments, jokes, insults or general abuse to (firstname.lastname@example.org).
Last updated: Monday 8 July, 1996.