\chapter{Introduction}
%The initial part of the introduction was taken from the abstract. Maybe some modifications are to be done here...
Debugging applications is very tedious work. One of the hardest steps to find a fault in a program is to reproduce the steps that lead to the program failure. Capture and replay aims at making the execution of a program repeatable, removing this burden from the developer. In order to be able to replay an application, it is necessary to isolate the deterministic part of the application that needs to be replayed (observed part) and the non-deterministic parts, like user input, storage or network (unobserved part). Once the behavior of the unobserved part can be captured and replayed, it is also possible to replay the observed part. Although capture and replay is commonly known as capturing mouse and keyboard events, there are approaches that go further and capture events from all interactions with the environment. All these approaches have one thing in common: They have a fixed border between observed and unobserved part.

Selective capture and replay \cite{orso05may} makes it possible to individually define the observed part. Because the information flow is not equally intense between all parts of a program, this offers the possibility to optimize the amount of information that needs to be captured. To reduce the amount of captured data, selective capture and replay uses a special technique: whenever an object passes the border, only its type and a unique identifier is recorded, unless the passed object is from a basic type. It is possible to show, that this suffices to replay the observed part. This technique ensures that the amount of recorded data is linear to the number of variables passed through the border, in contrast to other techniques which capture the whole data that is passed

We have developed a selective capture and replay framework for Eiffel. It allows capture and replay functionality for whole applications with some changes in the runtime and modifications in the libraries that are significantly smaller than for traditional approaches.

The original implementation for selective capture and replay was made for Java. The technique proposed in the original paper can not be completely applied to Eiffel because some language features differ between Eiffel and Java. Some of these differences make an implementation easier, for example it is not possible to change attributes of other classes, and some make it harder, for example multiple inheritance. Selective capture and replay relies on code instrumentation to capture accesses across the border. The original implementation instruments method and attribute accesses on the caller (client) side, whereas we instrument code at the callee side. The instrumentation our modified compilers adds to the program is the same for both the capture and the replay run. Hence no recompilation between the two phases is necessary. Depending on the program, compilation times can last for tens of minutes up to hours. For some capture and replay applications a recompilation can be prohibitive, therefore this feature is necessary. The original implementation instruments the program at the bytecode level and consequently doesn't need a complete recompile when the changing the code instrumentation.

  This thesis provides an implementation that shows the feasibility of selective capture and replay in Eiffel, rather than the possible performance. Nonetheless, some performance measurements will be presented, based on a simple example application.


