Two-Way Traceability and Conflict Debugging for AspectLTL Programs

Abstract

Tracing program actions back to the concerns that have caused them and blaming specific code artifacts for concern interference are known challenges of AOP and related advanced modularity paradigms. In this work we address these challenges in the context of AspectLTL, a temporallogic based language for the specification and implementation of crosscutting concerns, which has a composition and synthesis-based weaving process whose output is a correctby-construction executable artifact. When a specification is realizable, we provide two-way traceability information that links each allowed or forbidden transition in the generated program with the aspects that have justified its presence or elimination. When a specification is unrealizable, we provide an interactive game proof that demonstrates conflicts that should be fixed. The techniques are implemented and demonstrated using running examples.

A symbolic justice violations transition system for unrealizable GR(1) specifications

“…e speci cation contains an assumption that a docking request is only sent if the mechanism was in a ready state at some point previously, as expressed in the environment assumption G dockRequest -> ONCE(ready). All systems satisfying the speci cation will eventually be ready to accept docking requests, expressed by justice Figure 1: Concrete CS LTS for the docking mechanism speci cation, as computed by existing tools such as [4,10,18].…”

“…To try to understand the problem using existing tools [4,10,18], the engineer can generate a concrete CS, as shown in Fig. 1 (the complete result will list in each state the assignments to all of the variables; to avoid clu er, we show assignments only for states s 4 and s 7 ).…”

“…Previous work has shown how the debugging of an unrealizable speci cation, in the context of GR(1), can be done via the extraction of a counter-strategy (CS), which the engineer may explore in order to analyze the source of unrealizability [10,18]. First a Rabin game is played over the speci cation, and then intermediate values saved during the game are used to extract the concrete CS.…”

“…Previous works on debugging unrealizable speci cations for reactive synthesis (e.g., [1,4,10,18]) have considered the notion of unrealizable core, and the idea of semi-automatic discovery of possible assumptions to repair an unrealizable speci cation. To the best of our knowledge, all have used concrete CSs and none has considered a symbolic representation such as the JVTS.…”

Steps towards Scenario-Based Programming with a Natural Language Interface

“…Techniques that use model-checking, planning and synthesis, have been developed, to look ahead and choose an execution order in a smarter fashion [18,32]. Synthesis can often be used to verify that the specification is valid or to exhibit inconsistencies [33].…”