Dr. Jones: A Software Archaelogist’s Magic Lens
| 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 | ||
Why is source code hard to understand?
| 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 | ||
Application-Specific Knowledge
| 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 | |