Java Reference
In-Depth Information
Prototype 1: Physical recording
. The framework components implementing
functionalities for state logging, state recovering, physical recording of
both single and complex operations, and managing undo
■
redo of simple
operations.
Prototype 2: Logical recording
. The framework components implementing
functionalities for logical recording of state transitions.
■
18.4
■
Prototype 1: Physical recording
The focus of this prototype is on the framework's mechanisms for physical
recording of the application's state and of state changes.
18.4.1
Analysis
All the operations on recoverable classes taking place during the evolution of
the tracked application are recorded in a journal, which is called
tracking
log
, or simply log, of the application. This journal is written in a sequential
fashion and records all information that may be necessary for undoing or
redoing operations.
For physically recorded operations, the actual states of the affected
object(s) before and after the operation are directly available in the log,
hence idempotence is easily guaranteed.
These operations are considered as elementary operations, meaning that
they cannot be further decomposed into simpler components. A
complex
operation
or
macro operation
is a sequence of simple operations on a set of
recoverable classes. Complex operations may be arbitrarily nested, hence
defining a hierarchy of nested complex operations. Nesting of complex oper-
ations and interleaving of simple and complex operations is depicted in
Figure 18.2, where the horizontal axis represents increasing time and the
origin is the beginning of the tracked application. Simple operations are
represented as "
and dashed boxes delimit the boundaries of complex
operations.
It may be useful periodically to define stable states, i.e. frozen states
before which we are not interested in going backwards in the computation.
Saving a stable state means taking a snapshot of the current state of the
recoverable classes. This state becomes the initial state from which undo or
redo operations may take place.
For the sake of simplicity, we limit our analysis to user interactive appli-
cations, where the evolution is determined by the sequence of external
events corresponding to user stimuli as in the test application described in
t
Figure 18.2
Graphical representation of simple and complex operations
