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, which has future goals that are relevant to Part II
(Dynamic Models) of 91.522 OOAD:
http://objectsbydesign.com/tools/modeling_tools.html
This quote 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 minimize code-level dependence on programming
language alternatives and programming style idiosyncracies."
One extract from that link:
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
possible 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.
===============
Related
Bibliography:
Four advanced
papers on a similar subject are in IEEE TSE June and July 2006:
-------------------
Shmerl. Aldrich, Garlan, Kazman, Yan: Discovering Architecture from Running Systems IEEE TSE
July 2006 (454-466)
Barak, Harel, Marelly: InterPlay: Horizontal Scale-Up and Transition to Design in
Scenario-based Programming IEEE TSE July 2006 (467-485)
Sun, Dong: Design
Synthesis from Interaction and State-Based Specifications - IEEE TSE June 2006
(349-364)
Hou, Hoover: Using SCL
to Specify and Check Design Intent in Soure Code -
IEEE TSE June 2006 (404-423)
SCL is their (new)
Structural Constraint Language. This is a possible alternative to graphic
design models. Can SCL express constraints like event-and-guard-based state
transitions? If so, can we auto-generate SCL for run-time checking or bypass
State Diagrams altogether? - They give examples for Java and MFC.]
--------------------