2,552 research outputs found
SPEEDY: An Eclipse-based IDE for invariant inference
SPEEDY is an Eclipse-based IDE for exploring techniques that assist users in
generating correct specifications, particularly including invariant inference
algorithms and tools. It integrates with several back-end tools that propose
invariants and will incorporate published algorithms for inferring object and
loop invariants. Though the architecture is language-neutral, current SPEEDY
targets C programs. Building and using SPEEDY has confirmed earlier experience
demonstrating the importance of showing and editing specifications in the IDEs
that developers customarily use, automating as much of the production and
checking of specifications as possible, and showing counterexample information
directly in the source code editing environment. As in previous work,
automation of specification checking is provided by back-end SMT solvers.
However, reducing the effort demanded of software developers using formal
methods also requires a GUI design that guides users in writing, reviewing, and
correcting specifications and automates specification inference.Comment: In Proceedings F-IDE 2014, arXiv:1404.578
A Monitoring Language for Run Time and Post-Mortem Behavior Analysis and Visualization
UFO is a new implementation of FORMAN, a declarative monitoring language, in
which rules are compiled into execution monitors that run on a virtual machine
supported by the Alamo monitor architecture.Comment: In M. Ronsse, K. De Bosschere (eds), proceedings of the Fifth
International Workshop on Automated Debugging (AADEBUG 2003), September 2003,
Ghent. cs.SE/030902
Featherweight VeriFast
VeriFast is a leading research prototype tool for the sound modular
verification of safety and correctness properties of single-threaded and
multithreaded C and Java programs. It has been used as a vehicle for
exploration and validation of novel program verification techniques and for
industrial case studies; it has served well at a number of program verification
competitions; and it has been used for teaching by multiple teachers
independent of the authors. However, until now, while VeriFast's operation has
been described informally in a number of publications, and specific
verification techniques have been formalized, a clear and precise exposition of
how VeriFast works has not yet appeared. In this article we present for the
first time a formal definition and soundness proof of a core subset of the
VeriFast program verification approach. The exposition aims to be both
accessible and rigorous: the text is based on lecture notes for a graduate
course on program verification, and it is backed by an executable
machine-readable definition and machine-checked soundness proof in Coq
Causal reasoning about distributed programs
We present an integrated approach to the specification, verification and testing of distributed programs. We show how global properties defined by transition axiom specifications can be interpreted as definitions of causal relationships between process states. We explain why reasoning about causal rather than global relationships yields a clearer picture of distributed processing.;We present a proof system for showing the partial correctness of CSP programs that places strict restrictions on assertions. It admits no global assertions. A process annotation may reference only local state. Glue predicates relate pairs of process states at points of interprocess communication. No assertion references auxiliary variables; appropriate use of control predicates and vector clock values eliminates the need for them. Our proof system emphasizes causality. We do not prove processes correct in isolation. We instead track causality as we write our annotations. When we come to a send or receive, we consider all the statements that could communicate with it, and use the semantics of CSP message passing to derive its postcondition. We show that our CSP proof system is sound and relatively complete, and that we need only recursive assertions to prove that any program in our fragment of CSP is partially correct. Our proof system is, therefore, as powerful as other proof systems for CSP.;We extend our work to develop proof systems for asynchronous communication. For each proof system, our motivation is to be able to write proofs that show that code satisfies its specification, while making only assertions we can use to define the aspects of process state that we should trace during test runs, and check during postmortem analysis. We can trace the assertions we make without having to modify program code or add synchronization or message passing.;Why, if we verify correctness, would we want to test? We observe that a proof, like a program, is susceptible to error. By tracing and analyzing program state during testing, we can build our confidence that our proof is valid
HOP: a process model for synchronous hardware systems
technical reportModules in HOP are black-boxes that are understood and used only in terms of their interface. The interface consists of d a t a ports, events, and a protocol specification that uses events and asserts/queries values to / from ports. Events are realized as different combinations of control wires or as predicates defined over data conduits. Module await either command events or status events. Data conduits are realized as bus structures that deliver the same data items at the receiving end as items sent at t h e sending end (i.e. the busses do not have any wire-permutations, tappings, etc.). HOP is useful for writing both requirements (a priori) specifications and design (a posteriori) specifications. The manner in which requirements are expressed has usually no bearing on the actual implementation chosen later. Design specifications capture known facts about a system that has been built or has been designed in detail. In a HOP based design methodology, design proceeds hierarchically, and on many occasions (but not always) top-down. For most large systems, t h e requirements specification consists of the specification of a collection of modules and not one module; for these systems, the single module view is only derived a posteriori
Enforcing Behavioral Constraints in Evolving Aspect-Oriented Programs
Reasoning, specification, and verification of Aspect-Oriented (AO) programs presents unique challenges especially as such programs evolve over time. Components, base-code and aspects alike, may be easily added, removed, interchanged, or presently unavailable at unpredictable frequencies. Consequently, modular reasoning of such programs is highly attractive as it enables tractable evolution, otherwise necessitating that the entire program be reexamined each time a component is changed. It is well known, however, that modular reasoning about AO programs is difficult. In this paper, we present our ongoing work in constructing a rely-guarantee style reasoning system for the Aspect-Oriented Programming (AOP) paradigm, adopting a trace-based approach to deal with the plug-n-play nature inherent to these programs, thus easing AOP evolution
Clafer: Lightweight Modeling of Structure, Behaviour, and Variability
Embedded software is growing fast in size and complexity, leading to intimate
mixture of complex architectures and complex control. Consequently, software
specification requires modeling both structures and behaviour of systems.
Unfortunately, existing languages do not integrate these aspects well, usually
prioritizing one of them. It is common to develop a separate language for each
of these facets. In this paper, we contribute Clafer: a small language that
attempts to tackle this challenge. It combines rich structural modeling with
state of the art behavioural formalisms. We are not aware of any other modeling
language that seamlessly combines these facets common to system and software
modeling. We show how Clafer, in a single unified syntax and semantics, allows
capturing feature models (variability), component models, discrete control
models (automata) and variability encompassing all these aspects. The language
is built on top of first order logic with quantifiers over basic entities (for
modeling structures) combined with linear temporal logic (for modeling
behaviour). On top of this semantic foundation we build a simple but expressive
syntax, enriched with carefully selected syntactic expansions that cover
hierarchical modeling, associations, automata, scenarios, and Dwyer's property
patterns. We evaluate Clafer using a power window case study, and comparing it
against other notations that substantially overlap with its scope (SysML, AADL,
Temporal OCL and Live Sequence Charts), discussing benefits and perils of using
a single notation for the purpose
- …