an entry from

Piotr's R&D blog

I'm at ICSE in St. Louis, with a brand-new laptop courtesy of IBM Toronto Labs CAS. It's the third day of the conference (already!), and I thought I'd give live blogging a try; it should help me stay awake in some of the sessions, and provide a record of what I thought was interesting for later followup. The writing won't be very polished, but if you can get something out of it, you're welcome. Perhaps I'll catch up on yesterday's sessions and the tutorial tonight, for completeness' sake...

Object identity in sequence diagrams

When reverse-engineering UML sequence diagrams statically it's difficult to figure out which method calls are going to the same object, and which are going to different ones. Just looking at variable names is not enough due to aliasing. Using "naming analysis" we analyze the flow of references and, in many cases, can figure out that two variables actually point to the same object. The technique is fast and produces reasonably good results, though it fails on code with more complex control flows.

The author also emphasized that they're using static RE since it's not possible to get all the information out of dynamic traces. This is a good point, and means that Reef will probably need to do both static and dynamic RE for sequence diagrams. This is probably too much to fit into the dissertation... :-(

Binary refactoring

A post-source code transformation step for applications, to apply structure-changing optimizations without messing up your source. The declarative transformations must be manually defined by the developer. Probably useful in specific cases where performance is important and unachievable using standard optimization techniques, but not very exciting overall.

Automating component upgrade propagation

When libraries are upgraded, the client code needs to be updated manually to match the changes. However, if instead we capture the (interface) changes, we could automate many of the matching changes in the client. We can do this by recording refactorings -- at least the ones that were applied using the Eclipse refactoring facilities -- then replaying them at the client. Replaying is tricky, since we need to make Eclipse believe the original library source code is there for the refactoring to run. Also, this is not precise, since not all changes are formal refactorings, and not all refactorings change the public interface of the library, but should still reduce the effort needed at the client side.

The problem is that you need to capture a trace of refactorings performed, and read it on the client end, necessitating matching IDEs and plugins. What if, instead, we used original analysis to reverse engineer the most common rename/move refactorings? Not as precise, but less coupling. With a nice UI to let the developer fill in the blanks it could save almost as much effort.

The authors proposed an IDE-independent XML format for recording refactorings. This would be great, and would also benefit RE tools greatly!