Program Comprehension Models

1
Program Comprehension Models

• CIS 411
• Senior Seminar
• Spring 1999

2

• Material adapted from von Mayrhauser and Vans
  (1995) Program Understanding Models and
  Experiments. In M. Yovits and M. Zelkowitz,
  Advances in Computers, volume 40. San Diego
  Academic Press, pp. 1-38.

3

• The process of taking computer source code and
  understand it.
• Deimel and Naveda (1990)
• Program comprehension is a process that uses
  existing knowledge to acquire new knowledge.
• von Mayrhauser and Vans (1995)

4
Comprehension as a Process (1)

• Constructive
• implies the creation of partial, tentative
  explanations
• Knowledge Driven
• needs both problem (domain) and programming
  knowledge

5
Comprehension as a Process (2)

• Knowledge developed through the comprehension
  process describes the software product.
• Knowledge may relate
• functionality
• implementation choices
• control and data flow

6
Comprehension as a Process (3)

• Constructed knowledge bridges multiple levels of
  abstraction in both the problem domain and the
  solution domain.

7
Mental Model (1)

• A mental model is the readers existing,
  current, representation ( therefore
  understanding) of the system under study.

8
Mental Model (2)

• Mental Model is hierarchical.
• text structures
• chunks
• plans
• hypotheses

9
Mental Model (3)

• Microstructure
• individual program statements
• Macrostructure
• abstraction of program statements into a higher
  level chunk

10
Mental Model (4)

• Abstractions
• Chunks
• Hierarchy of abstractions
• Higher level chunks include relations between the
  chunks it contains
• Plans
• Describe the intent, or strategy in a block of
  code
• (not necessarily contiguous lines)
• Exist at varying levels of abstraction

11
Programming Plans (1)

• Program fragments that represent stereotypical
  actions sequences and rules of discourse (rules
  that specify the conventions in programming).

12
Programming Plans - Example(1)

• A program that reads and sums data until it
  reaches a termination point and then outputs the
  average of the data.

13
Programming Plans - Example(2)

• Goal Report the Average
• 1. Compute the Average
• 1.1 Sum the Data
• 1.2 Count the inputs
• 1.3 Divide the sum by the count
• 2. Output the Average

14
Program Average (input,output) CONST
SENTINEL9999 Var Total, Count, dataIn
integer Avg real BEGIN 1 Count0 2
Total0 3 Writeln(Enter an integer)
4 readln(dataIn) 5 While dataInltgtSENTINEL
DO BEGIN 6 TotalTotal dataIn 7
CountCount1 8 Writeln (Enter an
integer) 9 Readln(dataIn) 10 END
while 11 if Countgt0 THEN BEGIN 12
AverageTotal/Count 13 Writeln(Avg) 14
END if 15 ELSE Writeln(no valid
inputs) END.
15
Running Total Loop Plan

• 1 Count0
• 2 Total0
• 3 Writeln(Enter an integer)
• 4 readln(dataIn)
• 5 While dataInltgtSENTINEL DO BEGIN
• 6 TotalTotal dataIn
• 7 CountCount1
• 8 Writeln (Enter an integer)
• 9 Readln(dataIn)
• 10 END while

16
Counter Loop Plan

• 1 Count0
• 2 Total0
• 3 Writeln(Enter an integer)
• 4 readln(dataIn)
• 5 While dataInltgtSENTINEL DO BEGIN
• 6 TotalTotal dataIn
• 7 CountCount1
• 8 Writeln (Enter an integer)
• 9 Readln(dataIn)
• 10 END while

17
Evidence for Plans

• In studies of program recall experts tend to
  recall program fragments that correspond to plan
  structures before they recall other elements.

18
Problem with Plans

• The theory of plans does not account for when and
  how plans are used (strategies that govern
  retrieval and application of plans). One might
  say we have a theory of plans without a theory of
  planning.

19
Domain Plans

• Domain plans apply to objects in the problem
  domain. They define causal relationships between
  entities that must translate to programming level
  entities and relations.
• Control-flow plans are not sufficient.

20
Hypotheses

Hypotheses are drivers of cognition. They guide
the exploration. Hypotheses are generated which
focuses the readers attention on various areas
of the program, or based on some clue within a
code fragment the reader may suggest a hypothesis
on its purpose of behavior.
21
Dynamic Elements

• Strategy
• Guides the sequence of actions towards a goal
• Systematic or opportunistic
• Cross-referencing
• Relates items at different levels of abstraction
  or between the program structure and the problem
  domain
• Chunking
• Creates new abstraction
• Actions

22
Expertise

• Experts organize by functional characteristics of
  the domain, not program structure.
• Experts have specialize knowledge representations
  in the domain.
• Specialized representations support rapid
  retrieval for decomposition and abstraction.
• Experts are flexible in approaches.