|
|
|
|
|
|
|
|
|
|
Software Engineering |
|
Better tools for program comprehension |
|
|
|
Design Rationale |
|
Reverse engineering |
|
What information should we be capturing during
design? |
|
|
|
Artificial Intelligence |
|
Hierarchical recognition of design patterns in
structure and behavior of software |
|
|
|
|
|
|
|
User Studies of Program Comprehension |
|
What info is sought? (program concepts) |
|
How is info extracted? (strategies) |
|
Why? (software maintenance tasks) |
|
|
|
Dr. Jones, a software archaeologist’s assistant |
|
Visualization of structure and behavior |
|
Incremental exploration |
|
Design pattern recognition |
|
|
|
|
|
Navigate source code as hypertext |
|
Verbally describe movement through program |
|
Explain program later |
|
|
|
Browse/edit source code to improve design |
|
Screen capture of editing actions |
|
|
|
Still debugging methods…. |
|
|
|
|
|
From prior studies: |
|
Explaining from the UI backward |
|
Draw UI, write pseudocode |
|
From recent studies: |
|
Top-down vs. Bottom-up |
|
|
|
|
|
|
|
|
|
|
|
|
|
Visualize simple programs |
|
I.e. solitaire |
|
|
|
Compare with Javadoc |
|
|
|
See how it does on big programs |
|
10k LOC |
|
|
|
|
|
Cognitively motivated program understanding
tools |
|
Lethbridge 00, Storey 97 |
|
|
|
Design pattern recognition in programs |
|
Programmer’s Apprentice |
|
|
|
Software visualization |
|
SeeSoft (Eick 94) |
|
|
|
|
|
|
Source code is not “self-documenting” |
|
|
|
Figure out what programmers are looking for |
|
|
|
Abstract from what’s in the code to provide that
info |
|
|
|
Visualize it to see how it all fits together |
|
|
|
|
|
Notes