Aligning Development Tools with the Way Programmers Think About Code … · 2015-10-14 · structural tranformation to his/her conceptual understanding of a program structure

Aligning Development Tools with the Way ProgrammersThink About Code Changes

Marat Boshernitsan et al.

Presented By: James Mendek

Carleton University - COMP 5900

[email protected]

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 editsthat are similar but not identical, leading to errors and omissions. Mostexisting automated refactoring tools are counter-intuitive and difficult touse, failing to align with developers’ mental models of programmingstructures, or integrate well with development environments.


Existing Solutions

Type Examples IssuesText Tools Regular Expressions

SED + AWKLanguage agnostic but dif-ficult to read and under-stand, or extend beyondtrivial refactoring

IDE Tools Find and Replace,Refactoring Features

Ignores code structure.Cannot create customtransformations

AST Visualization A*, TAWK, Strat-ego/XT

Structure based, but toolow level

Edit-By-Example EBE, TELS, LAPIS,VISUAL AWK

Structure captured from ex-amples, but example collec-tion effort negates automa-tion


Example Solutions

Figure 1 : Text substitution with sedtreats source code as flat, structurelesstext.

Figure 2 : TXL - Use an extendedsyntax of the underlying programminglanguage to specify structuredtransformations thus improving itsreadability and maintainability.However, tool is complex and highlyspecialized


Contributions of Paper

1 A program manipulation paradigm that allows modifying source codewith interactively-constructed visual program transformations,bridging the gap between manipulation of source code structure andlightweight refactoring

2 Design of a visual transformation language and of the accompanyinguser-interaction model that combines edit-by-example, iterativerefinement, and immediate feedback

3 Extending the traditional evaluative use of the Cognitive Dimensionsframework to earlier design phases

4 The integration of a prototype visual transformation tool into aprofessional IDE (Eclipse)


Research Methodology

Goal is easy source code transformation generation. Target audienceis experienced java developers.

Three iterations of prototype design and verification based oncompliance with CD framework

Empiracal Study with 5 java developers

Pre-study interviewiXJ training sessionSmall code editing task (controlling for transformation type)Post-study interview based on CD questionnaire tailored toprogrammersAssessment of study results based on same framework.


Cognitive Dimensions of Notations I

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

1 High Visibility: One must be able to observe both the pattern andthe transformation through a visual representation understandable bythe programmer.

2 Moderate diffuseness: The notation for specifying transformationsshould be easy to learn for newcomers, but not so verbose that evensimple transformations need long descriptions.

3 Low error-proneness: One must be prevented from making errorswherever possible, but if an error occurs it should be easy to find andfix.


Cognitive Dimensions of Notations II

4 Closeness of mapping: One must be able to intuitively map astructural tranformation to his/her conceptual understanding of aprogram structure.

5 Progressive Evaluation: One must be able to check the results of atransformation-in-progress by examining its effect on the entire bodyof source code before “committing” the transformation.

6 No premature commitment: It should be possible to manipulatepatterns and transformations in any order. Any transformation mustbe easily reversible after it is applied


Example iXj Mockups

Figure 3 : Transformation rewritescalls to the removeElement() methodin java.util.Vector as a combination ofcalls to remove() and indexOf().Presents issues with diffuseness,viscosity, error-proneness, and closenessof mapping

Figure 4 : Mockup 2 includescontext-sensitive interface that assiststhe user with transformation patterns,thus supposedly reducing errorproneness


Example iXj Mockups

Figure 5 : Non-sql based patterndescription beginning to more resemblejava source code, but still awkward.

Figure 6 : Final mockup combinestextual and visual elements. Patternboxes resemble java syntax withintuitive wildcards, while transformingactions in gray (click image for demo)


https://www.youtube.com/watch?v=cVXscURz3kc

Example iXj Transformation (From Left to Right)


iXj Notable Properties

From example construction enables programmers to start with asimple transformation that applies to one location in the source codeand generalize it to apply to similar code fragments.

Iterative Refinement from immediate feedback of the UI means thatat any point in the transformation construction process theprogrammer knows what source code is affected and how it will bemodified. Encourages playing.

Transformation pending avoidsintermediate inconsistent code statesby allowing previews beforeapplication.


Time Metrics

Figure 7 : Time in seconds spent byusers on each of the transformationtasks. “Init” is the time spent on theinitial attempt. “Fix” is the time for asubsequent correction. “Total” is totaltime spent for a transformation.

All this really shows is that toolfluency improved over increasedexposure to the tool, which mightsuggest it is easy to learn.


User Performance Review

Pros

Users reported high visibility, low resistance to change, minimal prematurecommitment and moderate diffuseness allowing for easy readability oftransformations. Users thankful for lack of tree structure and for flexibilityof pending transformations to assist with workflow organization.

Cons

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


Author Observations

Proposed Solutions

Implement an approximate pattern-matching algorithm that will indicatewhich variations of the pattern structure exist in the program and whichparts of the transformation can be wildcarded to affect more codefragments. Possible performance issues in a large code base?

Tool Evaluation Issues

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


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 insufficientwildcarding of transformation patterns?

3 How can the papers evaluation of iXj’s utility over other tools bemade 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 languagesbeyond Java?

6 How can the tool’s UI be improved? Are there any important designcriteria or functionality not addressed by the Cognitive DimensionsFramework?


iXj Limitations


Documents

Aligning Development Tools with the Way Programmers Think About Code … · 2015-10-14 · structural tranformation to his/her conceptual understanding of a program structure