Put it In Reverse<br />Using Eclipse to Understand Code that has Already Been Written<br />Del Myers<br />
Software Is Complex<br />?<br />2<br />
Browsing Source Code<br />3<br />
That’s a Lot of Reading<br />4<br />
That’s a Lot of Reading<br />5<br />
That’s a Lot of Reading<br />6<br />
That’s a Lot of Reading<br />7<br />
That’s a Lot of Reading<br />8<br />
Dynamic Interactive Views For Reverse Engineering<br />!<br />9<br />
Focus on Features<br />What is it doing?<br />Where does it happen?<br />Why does it happen?<br />How does it happen?<br /...
Demo<br />
Trace Focused UI<br />Move<br />Rotate<br />Quit Game<br />Resume Game<br />Mouse Click<br />12<br />
Trace Focused UI<br />Rotate<br />13<br />
Summary<br />Focus on features<br />Isolate functionality<br />Analyze using Sequence Diagrams<br />Answer what, where, wh...
More Information<br />Del Myers<br />delmyers.cs@gmail.com<br />http://diver.sf.net<br />http://delaltctrl.blogspot.com<br...
Put It In Reverse: Using Eclipse to Understand Code that has Already Been Written
Upcoming SlideShare
Loading in …5
×

Put It In Reverse: Using Eclipse to Understand Code that has Already Been Written

1,244 views
1,183 views

Published on

Slides presented for talk at EclipseCon

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,244
On SlideShare
0
From Embeds
0
Number of Embeds
180
Actions
Shares
0
Downloads
27
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Hello, and thank you for coming to this talk. My name is Del Myers. I’m from the CHISEL Group at the University of Victoria. CHISEL stands for “Computer-human Interaction and Software Engineering Lab”. Our group focuses on how to improve the ways that people can use computers to do their work.In this talk, I’m going to discuss some of the problems that we developers have in doing our work. Our group has used the Eclipse IDE to help solve some of those problems.
  • So what are the problems that we are looking at?We have all found ourselves in situations that require us to understand software. Maybe we have to look for a bug, or learn a new API, or code that we wrote, but haven’t looked at in years. In these situations, we often will not know where to begin. We just don’t know how or where a feature was implemented.We might not realize it, but what we end up doing is reverse engineering. We search through the software that we have to learn, pulling it apart and reassembling it.Unfortunately, standard tools aren’t built for this kind of work.
  • To solve that problem, we can use the debugger to look at what is going on at runtime. We set a breakpoint, and start stepping through to let the software “tell us” what it is doing during runtime.
  • Unfortunately, both methods require a lot of reading, and that can be taxing. People can quickly forget what it is that we have read, and we have to often resort to keeping cryptic notes about what we’ve seen.Also, both methods really assume that we already know where to look. That is rarely the case, though when we are looking at new code or at code that was written long ago. Before we can even start browsing code or debugging, we have to start by searching for keywords that correspond to how we think the software should work. But how we think it works can be very different from how it actually works, so our searches often lead to dead ends.
  • Unfortunately, both methods require a lot of reading, and that can be taxing. People can quickly forget what it is that we have read, and we have to often resort to keeping cryptic notes about what we’ve seen.Also, both methods really assume that we already know where to look. That is rarely the case, though when we are looking at new code or at code that was written long ago. Before we can even start browsing code or debugging, we have to start by searching for keywords that correspond to how we think the software should work. But how we think it works can be very different from how it actually works, so our searches often lead to dead ends.
  • So, we’ve created a set of plug-ins for Eclipse called Diver which stands for Dynamic Interactive Views for Reverse Engineering. Remember, a lot of what we are doing in this whole process of understanding software is reverse engineering. It is the process of looking at a “completed” product, and trying to understand how it was built and why it does what it does.
  • The way that Diver does this is by helping us developers to focus on the features of software, rather than on source code. It is very difficult to understand software in terms of source code before we have had a chance to be incorporated into that code. The first thing that we typically see is what a program does, not the code that causes it to work. So, we look at questions like these: What is the software doing? Why does it work the way it does? Where does it do the work? And How does it do the work? Diver provides tools that help to answer these kinds of questions.
  • Let me explain what I’m doing here. Diver employs a technique called Software Reconnaissance. It was originally invented by a couple of researchers named Norman Wilde and … Scully, but we utilize it in a unique way. It basically works like this: we have a couple of traces the first trace contains information concerning the feature that we are interested in here, but it also contains a bunch of irrellevant information. In order to isolate the information we are interested in, we capture another trace, here… It contains all of that irrelavent info, but not our feature of interest. To isolate the interesting feature, we perform a set difference on the two traces.
  • This will, hopefully, isolate our feature. At the very least, it will reduce our search space to help us zero in on what we are interested in.
  • Put It In Reverse: Using Eclipse to Understand Code that has Already Been Written

    1. 1. Put it In Reverse<br />Using Eclipse to Understand Code that has Already Been Written<br />Del Myers<br />
    2. 2. Software Is Complex<br />?<br />2<br />
    3. 3. Browsing Source Code<br />3<br />
    4. 4. That’s a Lot of Reading<br />4<br />
    5. 5. That’s a Lot of Reading<br />5<br />
    6. 6. That’s a Lot of Reading<br />6<br />
    7. 7. That’s a Lot of Reading<br />7<br />
    8. 8. That’s a Lot of Reading<br />8<br />
    9. 9. Dynamic Interactive Views For Reverse Engineering<br />!<br />9<br />
    10. 10. Focus on Features<br />What is it doing?<br />Where does it happen?<br />Why does it happen?<br />How does it happen?<br />10<br />
    11. 11. Demo<br />
    12. 12. Trace Focused UI<br />Move<br />Rotate<br />Quit Game<br />Resume Game<br />Mouse Click<br />12<br />
    13. 13. Trace Focused UI<br />Rotate<br />13<br />
    14. 14. Summary<br />Focus on features<br />Isolate functionality<br />Analyze using Sequence Diagrams<br />Answer what, where, why, and how<br />Link different views<br />Scale up to production software<br />14<br />
    15. 15. More Information<br />Del Myers<br />delmyers.cs@gmail.com<br />http://diver.sf.net<br />http://delaltctrl.blogspot.com<br />Eclipse MarketPlace<br />Yoxos<br />p2:<br />http://diver.svn.sourceforge.net/svnroot/diver/Development<br />

    ×