Program Comprehension – Concept Assignment Part 3
Before I talk about Concept Assignment using Static Analysis, let me explain why I think this is important and worthwhile reading for any AS/400 RPG developers or managers doing maintenance work: I believe that the maintenance process can be significantly improved by anyone who makes the effort to understand what is actually going on in maintenance work. I think most people just say, “go make these changes,” and that’s as much instruction as anyone typically gets. But in fact, there are a great many ways the process can be improved – both speed and quality – and it all starts with understanding what goes on in the process.
So, the other main technique of Concept Assignment is performed by reading the source code, so called Static Analysis. Researchers have identified a variety of ways that programmers perform this task, depending on the circumstances.
If the programmer has a decent store of domain knowledge (i.e., business knowledge) then the top-down approach is used, and the programmer typically forms a series of hypotheses about the code and attempts to prove them. An example of this was described in Part 1. As the programmer does this he or she makes use of “beacons” as shortcuts to finding the code that represents the concept that is being sought in the code. For example, if trying to map the concept “refunds to new customers require manager authorization”, a good beacon to look for is the flag that represents a new customer. Other possibilities would be fields involved with refunds, such as refund amount, or possibly error messages. The programmer finds these in the code and tries to prove if that section of code represents the concept.
If the programmer has a low level of domain knowledge – or none at all – then typically the bottom-up approach is followed. This means reading the code, mostly line by line, and “chunking” it, first, into small concepts, and then chunking chunks into larger concepts, and so on.
In fact, it has been shown that in many cases programmers use both strategies, switching back and forth repeatedly, this is known as the Integrated approach.
Another approach is the as-needed technique, in which the programmer only attempts to understand the portions of the code relevant to the maintenance task that has been assigned to him or her. This may be the only practical approach in very large programs. If the programmer uses this technique successfully it is faster, however, it carries higher risk of error since the programmer is not developing a complete mental model of the program.
Regardless of which technique the programmer uses, one of the outcomes is that a mental model is formed of the program’s control flow and another model is formed of its data flow. The control flow represents the calls to subroutines, procedures and external code, plus large conditional blocks of code, and the data flow represents the data flowing from input files to output files, including screens and reports.
The over-all mental model can be said to consist of, at a very high level:
- Concept assignment/mapping – concepts mapped to specific code
- Control flow model
- Data flow model
In summary, effective Concept Assignment, aka Concept Location/Feature Location, makes use of Dynamic Analysis (Software Reconnaissance, Dynamic Slicing) and Static Analysis (Top-down, Bottom-up, Integrated, As-Needed Analysis, plus the use of beacons and domain knowledge, Control and Data Flow Modeling, and Static Program Slicing.)
Expert programmers do these things intuitively, and other programmers do some of them with varying degrees of skill. I think software maintenance organizations are missing big opportunities for improving speed and quality if they do not work to improve their team’s skills in these areas.
A good summary of this topic can be found in Theories, Methods and Tools in Program Comprehension: Past, Present and Future ($) by M-A Storey.
Tomorrow: Using Key Statement Analysis to assist with Program Comprehension