What if your tools knew when you have done a good job?

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    1 Favorite

    What if your tools knew when you have done a good job? - Presentation Transcript

    1. What if your tools knew when you have done a good job? Jan Wloka, PROLANGS Rutgers University Joint work with Barbara G. Ryder Frank Tip Virginia Tech IBM Research
    2. What do tools know? Our job is changing software systems Using various kinds of tool support: Process-aware Tools Process IDEs Program Behavior Advanced Editors Program Structure Text Editors Resources © Jan Wloka 2009 2
    3. What do tools know? Our job is changing software systems Using various kinds of tool support: Green bar: “warm and fuzzy feeling” © Jan Wloka 2009 2
    4. Example: “I want smarter tools!” Share local changes with team Two “horror” scenarios: 1.Textual merge conflicts 2.Test failures after update Very limited tool support: Textual conflict detection Change effects per file Am I responsible? © Jan Wloka 2009 3
    5. Atomic Change Models [PASTE’01, OOPSLA’04, ICSE’05, TSE’06, ICSE’09] Decomposition into 19 distinct change kinds Reflecting language semantics All atomic: smaller ! merged, bigger ! grouped Potential change in dispatch behavior Lookup change: explicit effect on a dispatch entry Inter-dependences between changes structural:!syntax, containment, change groups mapping:\" cause—effect © Jan Wloka 2009 4
    6. Explicit Representation of Change Example: Additions to an empty class Add © Jan Wloka 2009 5
    7. Explicit Representation of Change Example: Additions to an empty class Class Counter Field Method Method Method sum Counter() getSum() inc() Class MultiCounter Field Method Method counters MultiCounter() inc() Add © Jan Wloka 2009 5
    8. Explicit Representation of Change Example: Additions to an empty class Class Counter Field Method Method Method sum Counter() getSum() inc() Class MultiCounter Field Method Method counters MultiCounter() inc() Add AM4 AM1 AF3 CM5 CM2 © Jan Wloka 2009 5
    9. Explicit Representation of Change Example: Additions to an empty class Class Counter Field Method Method Method sum Counter() getSum() inc() Class MultiCounter Field Method Method counters MultiCounter() inc() Add AM4 AM1 AF3 CM5 CM2 © Jan Wloka 2009 5
    10. Explicit Representation of Change Example: Additions to an empty class Class Counter Field Method Method Method sum Counter() getSum() inc() CL7 Class MultiCounter Field Method Method counters MultiCounter() inc() Add AM4 AM1 AF3 CM5 CM2 CL6 © Jan Wloka 2009 5
    11. Determining Effects on Program Behavior Program Source Code Atomic Change Model Program Behavior AST :: original P I C M M AST :: edited P I C C M M M M © Jan Wloka 2009 6
    12. Determining Effects on Program Behavior Program Source Code Atomic Change Model Program Behavior AST :: original AL P AL I C AC M M C CL AST :: edited AM AM M M P I C C CM CM M M M M © Jan Wloka 2009 6
    13. Determining Effects on Program Behavior Program Source Code Atomic Change Model Program Behavior AST :: original AL call graph :: test1 P AL I C AC M M C CL AST :: edited call graph :: test2 AM AM M M P I C C CM CM M M M M © Jan Wloka 2009 6
    14. Determining Effects on Program Behavior Program Source Code Atomic Change Model Program Behavior AST :: original AL call graph :: test1 P AL I C AC M M C Impact on program behavior CL AST :: edited call graph :: test2 AM AM M M P I C C CM CM M M M M © Jan Wloka 2009 6
    15. Classification of Change I. Change of program elements: add / delete / change Incl. declaration-level changes, e.g. type of class II. Change of dynamic dispatch Static type hierarchy ! changed method lookup Structural vs. behavioral effects III.Change of program behavior Dynamic call graphs ! “exercised changes” Affected tests and affecting changes © Jan Wloka 2009 7
    16. Example: Change-aware Unit Testing Yellow Bar: No failures, but untested changes! Practical coverage goal: 100% changed behavior More effective test development © Jan Wloka 2009 8
    17. Example: Change-aware Process Advisors Advisors = explicit rules + tasks for guiding developers Guard properties of development artifacts Assist/automate tasks to satisfy properties © Jan Wloka 2009 9
    18. Example: Change-aware Process Advisors Advisors = explicit rules + tasks for guiding developers Guard properties of development artifacts Assist/automate tasks to satisfy properties Change-aware rules, e.g., »Require Tests Pass« Require test run to cover all changes Require all affected tests pass © Jan Wloka 2009 9
    19. Example: Change-aware Process Advisors Advisors = explicit rules + tasks for guiding developers Guard properties of development artifacts Assist/automate tasks to satisfy properties Change-aware rules, e.g., »Require Tests Pass« Require test run to cover all changes Require all affected tests pass Assist for change delivery Allow safely deliverable changes Generate tests for changed but untested elements © Jan Wloka 2009 9
    20. Conclusions Change models allow for reasoning about changes Smarter tools aware of effects on structure + behavior Known applications Fault finding, Testing, Change delivery, Refactoring A change-centric view on tools: Process Program Behavior Program Structure Resources © Jan Wloka 2009 10
    21. Conclusions Change models allow for reasoning about changes Smarter tools aware of effects on structure + behavior Known applications Fault finding, Testing, Change delivery, Refactoring A change-centric view on tools: Process Program Behavior Program Structure Advanced Editors Resources © Jan Wloka 2009 10
    22. Conclusions Change models allow for reasoning about changes Smarter tools aware of effects on structure + behavior Known applications Fault finding, Testing, Change delivery, Refactoring A change-centric view on tools: Process Program Behavior IDEs Program Structure Advanced Editors Resources © Jan Wloka 2009 10
    23. Conclusions Change models allow for reasoning about changes Smarter tools aware of effects on structure + behavior Known applications Fault finding, Testing, Change delivery, Refactoring A change-centric view on tools: Process Change-aware Tools Program Behavior IDEs Program Structure Advanced Editors Resources © Jan Wloka 2009 10
    24. Conclusions Change models allow for reasoning about changes Smarter tools aware of effects on structure + behavior Known applications Fault finding, Testing, Change delivery, Refactoring A change-centric view on tools: Change-aware Process Advisors Process Change-aware Tools Program Behavior IDEs Program Structure Advanced Editors Resources © Jan Wloka 2009 10

    + Jan WlokaJan Wloka, 8 months ago

    custom

    519 views, 1 favs, 1 embeds more stats

    You are working in a team changing the code base wi more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 519
      • 495 on SlideShare
      • 24 from embeds
    • Comments 0
    • Favorites 1
    • Downloads 1
    Most viewed embeds
    • 24 views on http://www.eclipsecon.org

    more

    All embeds
    • 24 views on http://www.eclipsecon.org

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories