Dr. Jones : a software design explorer's crystal ball

The Problem: Most of software design is redesign. Redesign happens when the programmer finds a better solution for the initial design problem or the problem itself changes. Yet there is a dearth of effective tools for effective software redesign ‐ it proceeds primarily by planning with pen and paper, away from the computer where tools could help the programmer the most. To address this problem, I am developing Dr. Jones, an assistant that helps the programmer improve the design of Java programs. Dr. Jones diagrams the design of a Java program and allows the user to improve its design by applying refactorings, localized patterns of structural change in object-oriented programs that improve their design, without changing their visible behavior [1]. Dr. Jones records the programmer’s intended refactorings and updates the diagram with the resulting (presumably improved) design. It will support the kind of design exploration a programmer would ordinarily do with pen and paper, while also providing a “crystal ball:” the ability to see design evolve. This facilitates exploring the design space of the program, enabling the programmer to choose the best alternative design. Motivation: Effective software redesign is crucial step in reducing the cost of software maintenance. But planning such redesign is presently a cumbersome manual process. The first step ‐ getting a clear picture of the current design ‐ typically requires a programmer to manually reverse engineer the program into hand-drawn diagrams. Next, problems and necessary refactorings are noted on these diagrams. Finally, the programmer returns to the source and implements the refactorings using the diagram as a guide. If further refactoring is needed ‐ or the refactoring plan has to be rethought ‐ this process must begin from scratch. Tools like Dr. Jones have immense potential for streamlining this process. Diagrams that accurately reflect the current program design can be generated automatically by analyzing source code. Refactoring proceeds by interacting with the diagram, where cumulative impact can be measured, alternatives explored, and plans recorded, without the need for manual redrawing. Previous Work: Nearly all existing refactoring systems are based on the metaphor of source code transformation ‐ a refactoring immediately alters the source text of the program [2]. This limits the programmer to refactorings that can be done safely and automatically. Partially automating source-level refactorings doesn’t help, because it forces the programmer to make detailed programming decisions when she would rather be thinking about design.