Aligning Development Tools with the Way Programmers Think About Code - - PowerPoint PPT Presentation

Aligning Development Tools with the Way Programmers Think About Code Changes

Marat Boshernitsan et al. Presented By: James Mendek

Carleton University - COMP 5900 pmendek@gmail.com

October 13, 2015

James Mendek (CU) iXj: Source Transformations in Java October 13, 2015 1 / 17

Problem Definition

Conceptually simple source code changes often require numerous edits that are similar but not identical, leading to errors and omissions. Most existing automated refactoring tools are counter-intuitive and difficult to use, failing to align with developers’ mental models of programming structures, or integrate well with development environments.

James Mendek (CU) iXj: Source Transformations in Java October 13, 2015 2 / 17

Existing Solutions

Type Examples Issues Text Tools Regular Expressions SED + AWK Language agnostic but dif- ficult to read and under- stand,

• r extend beyond

trivial refactoring IDE Tools Find and Replace, Refactoring Features Ignores code structure. Cannot create custom transformations AST Visualization A*, TAWK, Strat- ego/XT Structure based, but too low level Edit-By-Example EBE, TELS, LAPIS, VISUAL AWK Structure captured from ex- amples, but example collec- tion effort negates automa- tion

James Mendek (CU) iXj: Source Transformations in Java October 13, 2015 3 / 17

Example Solutions

Figure 1 : Text substitution with sed treats source code as flat, structureless text. Figure 2 : TXL - Use an extended syntax of the underlying programming language to specify structured transformations thus improving its readability and maintainability. However, tool is complex and highly specialized

James Mendek (CU) iXj: Source Transformations in Java October 13, 2015 4 / 17

Contributions of Paper

1 A program manipulation paradigm that allows modifying source code

with interactively-constructed visual program transformations, bridging the gap between manipulation of source code structure and lightweight refactoring

2 Design of a visual transformation language and of the accompanying

user-interaction model that combines edit-by-example, iterative refinement, and immediate feedback

3 Extending the traditional evaluative use of the Cognitive Dimensions

framework to earlier design phases

4 The integration of a prototype visual transformation tool into a

professional IDE (Eclipse)

James Mendek (CU) iXj: Source Transformations in Java October 13, 2015 5 / 17

Research Methodology

Goal is easy source code transformation generation. Target audience is experienced java developers. Three iterations of prototype design and verification based on compliance with CD framework Empiracal Study with 5 java developers

Pre-study interview iXJ training session Small code editing task (controlling for transformation type) Post-study interview based on CD questionnaire tailored to programmers Assessment of study results based on same framework.

James Mendek (CU) iXj: Source Transformations in Java October 13, 2015 6 / 17

Cognitive Dimensions of Notations I

Offers non-indepent techniques for interface evaluation and design improvement through building a cognitive profile of a system. 6 dimensions are essential:

1 High Visibility: One must be able to observe both the pattern and

the transformation through a visual representation understandable by the programmer.

2 Moderate diffuseness: The notation for specifying transformations

should be easy to learn for newcomers, but not so verbose that even simple transformations need long descriptions.

3 Low error-proneness: One must be prevented from making errors

wherever possible, but if an error occurs it should be easy to find and fix.

James Mendek (CU) iXj: Source Transformations in Java October 13, 2015 7 / 17

Cognitive Dimensions of Notations II

4 Closeness of mapping: One must be able to intuitively map a

structural tranformation to his/her conceptual understanding of a program structure.

5 Progressive Evaluation: One must be able to check the results of a

transformation-in-progress by examining its effect on the entire body

• f source code before “committing” the transformation.

6 No premature commitment: It should be possible to manipulate

patterns and transformations in any order. Any transformation must be easily reversible after it is applied

James Mendek (CU) iXj: Source Transformations in Java October 13, 2015 8 / 17

Example iXj Mockups

Figure 3 : Transformation rewrites calls to the removeElement() method in java.util.Vector as a combination of calls to remove() and indexOf(). Presents issues with diffuseness, viscosity, error-proneness, and closeness

• f mapping

Figure 4 : Mockup 2 includes context-sensitive interface that assists the user with transformation patterns, thus supposedly reducing error proneness

James Mendek (CU) iXj: Source Transformations in Java October 13, 2015 9 / 17

Example iXj Mockups

Figure 5 : Non-sql based pattern description beginning to more resemble java source code, but still awkward. Figure 6 : Final mockup combines textual and visual elements. Pattern boxes resemble java syntax with intuitive wildcards, while transforming actions in gray (click image for demo)

James Mendek (CU) iXj: Source Transformations in Java October 13, 2015 10 / 17

Example iXj Transformation (From Left to Right)

James Mendek (CU) iXj: Source Transformations in Java October 13, 2015 11 / 17

iXj Notable Properties

From example construction enables programmers to start with a simple transformation that applies to one location in the source code and generalize it to apply to similar code fragments. Iterative Refinement from immediate feedback of the UI means that at any point in the transformation construction process the programmer knows what source code is affected and how it will be

• modified. Encourages playing.

Transformation pending avoids intermediate inconsistent code states by allowing previews before application.

James Mendek (CU) iXj: Source Transformations in Java October 13, 2015 12 / 17

Time Metrics

Figure 7 : Time in seconds spent by users on each of the transformation

• tasks. “Init” is the time spent on the

initial attempt. “Fix” is the time for a subsequent correction. “Total” is total time spent for a transformation.

All this really shows is that tool fluency improved over increased exposure to the tool, which might suggest it is easy to learn.

James Mendek (CU) iXj: Source Transformations in Java October 13, 2015 13 / 17

User Performance Review

Pros

Users reported high visibility, low resistance to change, minimal premature commitment and moderate diffuseness allowing for easy readability of

• transformations. Users thankful for lack of tree structure and for flexibility
• f pending transformations to assist with workflow organization.

Cons

Users sometimes didn’t know they had introduced an error and that their final transformation was incorrect. Users reported difficulty knowing when a pattern is sufficiently generic, or how to write patterns that match targetted code fragments. Users also repeatedly clicked the wrong icon for a task, or failed to click outside of a text field to set the input.

James Mendek (CU) iXj: Source Transformations in Java October 13, 2015 14 / 17

Author Observations

Proposed Solutions

Implement an approximate pattern-matching algorithm that will indicate which variations of the pattern structure exist in the program and which parts of the transformation can be wildcarded to affect more code

• fragments. Possible performance issues in a large code base?

Tool Evaluation Issues

Transformation tasks were too simple, small in scope, and were hand selected, limiting user tool exposure. Results cannot attest to the scalability of the visual approach to transformation tasks.

James Mendek (CU) iXj: Source Transformations in Java October 13, 2015 15 / 17

Discussion Questions

1 Are there any types of tranformation that iXj cannot perform? 2 What are some ways to address the tool’s issues with insufficient

wildcarding of transformation patterns?

3 How can the papers evaluation of iXj’s utility over other tools be

made more convincing?

4 Do the benefits of iXj eclipse integration outweigh the limitations?

Why or why not?

5 Are there any reasons to doubt the tool’s portability to languages

beyond Java?

6 How can the tool’s UI be improved? Are there any important design

criteria or functionality not addressed by the Cognitive Dimensions Framework?

James Mendek (CU) iXj: Source Transformations in Java October 13, 2015 16 / 17

iXj Limitations

James Mendek (CU) iXj: Source Transformations in Java October 13, 2015 17 / 17