From lechner@cs.uml.edu  Mon Sep 25 20:45:29 2006
Subject: reverse engineering from run-time traces, and TSE bibliog (fwd)
To: lechner@cs.uml.edu (Bob Lechner)
Date: Mon, 25 Sep 2006 20:47:54 -0400 (EDT)
Cc: alison_lea@yahoo.com, kbagley@us.ibm.com, cguffey@gmail.com,
        agabriel@cs.uml.edu, nitin.sonawane@verizon.net,
        nsonawan@cs.uml.edu (Nitin Sonawane), lechner@cs.uml.edu (Bob Lechner),
        sfrye@cs.uml.edu (Scot Frye)

Subject: reverse engineering from run-time traces, and TSE bibliography:

RJLRef:  $PH/06f522/larman_auto_generation_objectsbydesign.{doc,htm} 

The content of  this link is from the website objectsbydesign.com 
whose future goals are relevant to Part II (Dynamic Models) 
of 91.522 OOAD: 


This guote gets right to the point re: the advantage of 
logging and replay for reverse engineering:

"Event-driven state model descriptions of control flow raise the 
level of abstraction and mimimize code-level dependence on programming 
language alternatives and programming style idiosyncrasies."

The following section was taken from this link:
RJLRef: http://objectsbydesign.com/tools/modeling_tools.html

One extract from that link:


In the Future...
Auto-generation   

One feature that we would really like to see in the near future is the ability for modeling tools to help in the generation of interaction and state diagrams.

This is how it should work: the modeling tool should facilitate the creation of a trace file during the execution of an existing program. The purpose of the trace file would be to capture the interaction between objects as they are passing messages between each other. After the trace file is created, the modeling tool would be used to analyze the trace in order to find the patterns of object interactions. The modeling tool should allow the user to select from a group of classes to analyze. The tool could then present each unique set of interactions that have been recorded by the trace file for these classes, and allow the user to select which interactions to model. Finally, the tool should be able to generate either a sequence or collaboration diagram based on actual, recorded object interactions. 

Pretty cool? If this sounds too futuristic it shouldn't, because the tracing technique has already been implemented quite successfully by tools which help developers track down performance bottlenecks in their programs. One nice example of products in this category is JProbe from the KL Group, which is used to analyze the performance of Java programs.

It should also be possibe  to auto-generate state diagrams using the same technique; one modification to the previously described sequence would be to allow the user to specify the name of a base class for the states in the state machine. The modeling tool would trace interactions between derived classes of the base class. From this trace, the modeling tool could create a state diagram by diagramming each of the recorded state transitions.


Two advanced papers on a similar subject are in IEEE TSE July 2006:

Shmerl. Aldrich, Garlan, Kazman, Yan: 
Discovering Architecture from RUnning Systems (454-466)

Barak, Harel, Marelly: InterPlay: Horizontal Scale-Up and Transition 
to Design in Scenario-based Programming (467-485)