Put It In Reverse: Using Eclipse to Understand Code that has Already Been Written
•Download as PPTX, PDF•
1 like•539 views
Slides presented for talk at EclipseCon
Recommended
Recommended
More Related Content
Similar to Put It In Reverse: Using Eclipse to Understand Code that has Already Been Written
Similar to Put It In Reverse: Using Eclipse to Understand Code that has Already Been Written (20)
Recently uploaded
Recently uploaded (20)
Put It In Reverse: Using Eclipse to Understand Code that has Already Been Written
- 1. Put it In Reverse Using Eclipse to Understand Code that has Already Been Written Del Myers
- 2. Software Is Complex ? 2
- 3. Browsing Source Code 3
- 4. That’s a Lot of Reading 4
- 5. That’s a Lot of Reading 5
- 6. That’s a Lot of Reading 6
- 7. That’s a Lot of Reading 7
- 8. That’s a Lot of Reading 8
- 9. Dynamic Interactive Views For Reverse Engineering ! 9
- 10. Focus on Features What is it doing? Where does it happen? Why does it happen? How does it happen? 10
- 11. Demo
- 12. Trace Focused UI Move Rotate Quit Game Resume Game Mouse Click 12
- 13. Trace Focused UI Rotate 13
- 14. Summary Focus on features Isolate functionality Analyze using Sequence Diagrams Answer what, where, why, and how Link different views Scale up to production software 14
- 15. Acknowledgements Supervisor Dr. Margaret-Anne Storey Research Collaborations Martin Salois David Ouellet Philippe Charland Chris Bennett Daniel German Jim Buckley 15
- 16. More Information Del Myers delmyers.cs@gmail.com http://diver.sf.net http://delaltctrl.blogspot.com Eclipse MarketPlace Yoxos p2: http://diver.svn.sourceforge.net/svnroot/diver/Development
Editor's Notes
- 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.