TraceContract: A Scala DSL for Trace Analysis

Barringer, Howard; Havelund, Klaus

doi:10.1007/978-3-642-21437-0_7

Cited by 92 publications

(62 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Many specification-based runtime-monitoring frameworks have been proposed, including four approaches to parametric monitoring: an automaton-based approach [5,7,15,16,18,20,28,34]; a regular expression-and grammar-based approach [1,18,24]; an approach based on temporal logic [6, 8, 9, 18-20, 24, 32, 33, 39, 48-50]; and a rule-based approach [4,6,35].…”

Section: Related Workmentioning

confidence: 99%

Runtime Monitoring for Concurrent Systems

Yamagata

Artho

Hagiya

et al. 2016

Runtime Verification

View full text Add to dashboard Cite

Abstract. Most existing specification languages for runtime verification describe the properties of the entire system in a top-down manner, and lack constructs to describe concurrency in the specification directly. CSP E is a runtime-monitoring framework based on Hoare's Communicating Sequential Processes (CSP) that captures concurrency in the specification directly. In this paper, we define the syntax of CSP E and its formal semantics. In comparison to quantified event automata (QEA), as an example, CSP E describes a specification for a concurrent system in a bottom-up manner, whereas QEA lends itself to a top-down manner. We also present an implementation of CSP E , which supports full CSP E without optimization. When comparing its performance to that of QEA, our implementation of CSP E requires slightly more than twice the time required by QEA; we consider this overhead to be acceptable. Finally, we introduce a tool named stracematch, which is developed using CSP E . It monitors system calls in (Mac) OS X and verifies the usage of file descriptors by a monitored process.

show abstract

Section: Related Workmentioning

confidence: 99%

Runtime Monitoring for Concurrent Systems

Yamagata

Artho

Hagiya

et al. 2016

Runtime Verification

View full text Add to dashboard Cite

show abstract

“…As a result we introduce, in this paper, a slightly improved version of the Classic Zielonka Algorithm along with a heavily optimized implementation in Scala Programming Language [30,31]. Scala is a high-level language, proven to be well performing [21], with object and functional oriented features, that recently has come to the fore with useful applications in several fields of computer science including formal verification [4]. Our experiments show that, by using all Scala features extensively, we are able of gaining two order of magnitude in running time with respect to the implementation of the Zielonka algorithm in PGSolver.…”

Section: Condition Complexitymentioning

confidence: 99%

Solving Parity Games in Scala

Stasio

Murano

Prignano

et al. 2015

Formal Aspects of Component Software

View full text Add to dashboard Cite

Abstract. Parity games are two-player games, played on directed graphs, whose nodes are labeled with priorities. Along a play, the maximal priority occurring infinitely often determines the winner. In the last two decades, a variety of algorithms and successive optimizations have been proposed. The majority of them have been implemented in PGSolver, written in OCaml, which has been elected by the community as the de facto platform to solve efficiently parity games as well as evaluate their performance in several specific cases. PGSolver includes the Zielonka Recursive Algorithm that has been shown to perform better than the others in randomly generated games. However, even for arenas with a few thousand of nodes (especially over dense graphs), it requires minutes to solve the corresponding game. In this paper, we deeply revisit the implementation of the recursive algorithm introducing several improvements and making use of Scala Programming Language. These choices have been proved to be very successful, gaining up to two orders of magnitude in running time.

show abstract

“…TraceContract [4,5] is a so-called internal DSL (an extension of an existing programming language), an API in the Scala programming language, offering an interesting combination of data parameterized state machines and temporal logic. It is currently being tried out by the testing team on the SMAP project [13] at JPL (a future earth orbiting satellite measuring soil moisture), and by the LADEE project [10] at NASA Ames Research Center (a future moon orbiting satellite measuring dust in the lunar atmosphere).…”

Section: Logscope and Tracecontractmentioning

confidence: 99%

Requirements-Driven Log Analysis (Extended Abstract)

Havelund

2012

Testing Software and Systems

Self Cite

View full text Add to dashboard Cite

Imagine that you are tasked to help a project improve their testing effort. In a realistic scenario it will quickly become clear, that having an impact is difficult. First of all, it will likely be a challenge to suggest an alternative approach which is significantly more automated and/or more effective than current practice. The reality is that an average software system has a complex input/output behavior. An automated testing approach will have to auto-generate test cases, each being a pair (i, o) consisting of a test input i and an oracle o. The test input i has to be somewhat meaningful, and the oracle o can be very complicated to compute. Second, even in the case where some testing technology has been developed that might improve current practice, it is then likely difficult to completely change the current behavior of the testing team unless the technique is obviously superior and does everything already done by existing technology.So is there an easier way to incorporate formal methods-based approaches than the full fledged test revolution? Fortunately the answer is affirmative. A relatively simple approach is to benefit from possibly already existing logging infrastructure, which after all is part of most systems put in production. A log is a sequence of events, generated by special log recording statements, most often manually inserted in the code by the programmers. An event can be considered as a data record: a mapping from field names to values. We can analyze such a log using formal methods, for example checking it against a formal specification. This separates running the system from analyzing its behavior. It is not meant as an alternative to testing since it does not address the important input generation problem. However, it offers a solution which testing teams might accept since it has low impact on the existing process. A single person might be assigned to perform such log analysis, compared to the entire testing team changing behavior.Note that although logging often is manually programmed, it can be performed using automated code instrumentation, using for example aspect-oriented programming. The point here, however, is that manual logging is often already

show abstract

TraceContract: A Scala DSL for Trace Analysis

Cited by 92 publications

References 13 publications

Runtime Monitoring for Concurrent Systems

Runtime Monitoring for Concurrent Systems

Solving Parity Games in Scala

Requirements-Driven Log Analysis (Extended Abstract)

Contact Info

Product

Resources

About