Tracing execution

While recording execution traces, we manipulated the H-VAD setting by repeatedly pressing buttons so that the software would exercise as many branches as possible. Figure 3 illustrates how we systematieally prepared test cases based on the following guidelines ... 

The work of [Jorge and Brazdil 94] is another attempt at trace-based synthesis of logic programs. Their specifications by examples are augmented with partial execution traces, called algorithm sketches. 

Note that Astr6e computes an abstract semantics and provides local abstract invariants attached to program points. Thus, in case of a potential runtime error users can access the alarm message along with its context and the invariants. But it does not provide a concrete execution trace for the alarm, since each abstract trace represents a set of concrete execution traces. 

There are several features of Event-B that make the ft-amework an attractive option for modelhng SoS. Firstly, abstraction allows us to define system-wide properties of complex systems and verify them over all execution traces. Secondly, refinement enables system modelling at different architectural layers. Furthermore, proofs in combination with refinement allow us to verify complex systems in a highly automated manner. Finally, a special form of refinement decomposition — allows us to derive specifications of constituent systems in such a way that system-level properties would be preserved despite their autonomy. In the next section, we will demonstrate how to derive a generic specification of a SoS by refinement in Event-B. 

Integrating dynamic and static analysis seems to be beneficial. The static and dynamic information could be shown as separated views or merged in a single view. In general, the outcome of the dynamic analysis could be visualized as a set of diagrams, each one associated with one execution trace of a test case. Although, the construction of these diagrams can be automated, their analysis requires human intervention in most cases. Dynamic analysis depends on the quality of the test cases. 

Maoz and Harel (2010) present a powerful technique for the visualization and exploration of execution traces of models that is different from previous approaches that consider execution traces at the code level. This technique belongs to the domain of model-based dynamic analysis adapting classical visualization pwadigms and techniques to spiecific needs of dynamic analysis. It allows relating the system execution traces and its models in different tasks such as testing whether a system run satisfies model properties. We consider that these results allow us to address reverse engmeering challenges in the context of model-driven development. 

Dynamic analysis allows generating execution snapshot to collect hfe cycle traces of object instances and reason from tests and proofs. Execution tracer tools generate execution model snapshots that allow us to deduce complementary information. The execution traces of different instances of the same class or method, could guide the construction of invariants or pre- and post-conditions respectively. 

A SLIM model can be evaluated using model checking techniques, in order to guarantee that it satisfies the required functional properties. To this aim, the model can be translated into a Labeled Transition System (LTS) and exhaustively analyzed by the model checker to check whether the properties hold. If a property does not hold, a counterexample trace can be generated to show an execution trace of the model that violates the property. To cope with the state explosion problem, advanced techniques can be applied, in particular sjun-bolic techniques based on Binary Decision Diagrams (BDD) [9] and SAT-based Bounded Model Checking [4,5,22,18] (BMC). Verification can also benefit from advanced techniques for compihng temporal properties into a symbolic LTS [12]. 

In this paper, we adopt the CBD framework supported by the OCRA tool [4]. In particular, we use a finite-state discrete-time model of the system. Component interfaces are described with Boolean or bounded integer data ports and with events, which are instantaneous triggers of changes (from the formal point of view, they are Boolean labels on the state transitions). An execution trace of the component is therefore a sequence of states, which are assignments to the port variables. The transition from a state to another one can be labeled with an event. Assertions on the execution traces are specified by means of linear-time temporal logic. In particular, we use LTL [7] with past operators and predicates over current and next variables to represent state changes, as informally described in Table 1. 

If we remove one of these assumption, the OCRA tool gives us a counterexample showing an execution trace that violates the top-level contract. Note however that these assumptions are not guaranteed to be the weakest conditions. 

The work in [3] introduced the notion of a Parallelism Opportunity (POP). This is a code fragment or construct that can be executed by processing elements in parallel. This could be a parallel block, parallel iterations of a for loop over a structure or container, parallel evaluations of subprogram calls, and so on. That work also introduced the term tasklet to capture the notion of a single execution trace within a POP, which the programmer can express with special syntax, or the compiler can implicitly create. 

Goofi-2 defines faults as time-location pairs according to a fault-free execution of a workload. Here locations are randomly selected bits to be flipped from the ISA registers or the memory words, and time is a point in the execution trace. 

The part a) in Figure 1.9 is a representation of a program with two consecutive IF instructions and a WHILE instruction. An analysis of the execution paths in operation may lead to the selection of two execution traces. The characterization of these tracks is revealed by crossing points. The crossing points may be local (several pieces of information are stored) or global (a single variable is manipulated) indicators. 

Figure 6.11 Execution trace for the iterative incremental scheduling algorithm.

---