The Community for Technology Leaders
Green Image
<p>To reverse engineer scenarios from event traces, one must infer causal relationships between events. The inferences are usually based on a trace with sequence numbers or timestamps corresponding to some kind of logical clock. In practice, there is an explosion of potentially causal relationships in the trace, which limits one's ability to extract scenarios. This work defines a more parsimonious form of causality called <it>scenario causality</it> that concentrates on certain major causal relationships and ignores more subtle potentially causal links. The influence of an event is restricted to the particular scenario it is part of. An event which is not a message reception is defined to be caused by the previous event in the same software object, while a message reception is caused by a sending event in another object. The events are ordered to form a <it>scenario event graph</it> where typed nodes are events and the typed edges are certain causal relationships. Intuitively, we might say that most logical clocks, which identify events which “happened before” a given event and, thus, are potentially causal, give an upper bound on the set of causal events; scenario causality identifies a lower bound. The much smaller lower bound set makes it possible to reverse engineer and automate the analysis of scenarios.</p>
logical clock, causal order, software tracing, graph grammar, trace analysis, distributed programming, reverse engineering, event labeling, debugging, web services

C. Hrischuk and C. Woodside, "Logical Clock Requirements for Reverse Engineering Scenarios from a Distributed System," in IEEE Transactions on Software Engineering, vol. 28, no. , pp. 321-339, 2002.
97 ms
(Ver 3.3 (11022016))