Scenario adapters were developed around the idea of
components getting in and out of an execution scenario,
allowing actions to be executed at these points, therefore, a
scenario must define at least two different operations: enter
and leave. These actions must take place respectively before
and after each of the component’s operation in order to
setup the conditions required by the scenario. For example,
in a compressed scenario, enter would be responsible to
decompress the component’s input data, while leave would
compress its outputs.
In the software domain, components are objects which
communicate using method invocation (considering an OOPbased
approach) and the execution of all operations are
naturally sequential, so the scenario adapters were originally
developed to provide means to just efficiently wrap the
method calls to an object with enter and leave operations.
However, in the hardware domain, components have input
and output signals instead of a method or function interface,
and all operations are intrinsically parallel. These different
characteristics required some modifications on the original
scenario adapter. The new scenario adapter is shown in figure