Elements of style: analyzing a software design feature with a counterexample detector

JacksonDaniel,; DamonCraig, A

doi:10.1109/32.538605

Cited by 115 publications

(57 citation statements)

References 24 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…§ Confirmar que una especificación operacional satisface especificaciones más abstractas, o generar contraejemplos de comportamiento por el modelo algorítmico de las técnicas de comprobación [21][22][23]. § Generar contraejemplos de las afirmaciones de una especificación declarativa [24]. § Generar escenarios concretos que ilustren características deseadas o no deseadas de la especificación [25], o inferir inductivamente la especificación de escenarios [26].…”

Section: Ventajas De La Formalizaciónunclassified

La especificación formal en contexto: actual y futuro

A²

2014

Ingeniare. Rev. chil. ing.

View full text Add to dashboard Cite

RESUMENLa especificación formal es un área de investigación activa en la ingeniería de software de este siglo, en la que se aplica en diversas configuraciones y técnicas, y aunque su uso industrial todavía es limitado, la comunidad científica tiene actualmente una comprensión diferente acerca de su utilidad y necesidad. Hasta el momento el trabajo de los investigadores se focaliza en la especificación escrita durante el diseño del modelo funcional preliminar, por lo que se centra principalmente en evaluar las herramientas relacionadas. En este trabajo se realiza una revisión a la literatura, se hace un recorrido por la esencia, la función, el uso y los inconvenientes de las técnicas de especificación formal y se analizan algunos criterios de valoración y de evaluación a sus debilidades. Los resultados se convierten en la base para formular trabajos futuros, con el objetivo de buscar que la especificación formal se afiance como actividad básica de investigación.Palabras clave: Técnicas formales, especificación formal, métodos formales, ciencias computacionales, ingeniería de software. ABSTRACT

show abstract

Section: Ventajas De La Formalizaciónunclassified

La especificación formal en contexto: actual y futuro

A²

2014

Ingeniare. Rev. chil. ing.

View full text Add to dashboard Cite

show abstract

“…by putting a bound on the number of aircrafts involved. This implicitly appeals to Daniel Jackson's Small Scope Hypothesis [24] saying that the vast majority of flaws in a system can be found by exhaustively testing all input parameters within some small scope of values. This work also exploits data structures and algorithms for efficient reachability analysis over Petri nets or similar globally asynchronous, locally synchronous systems [5].…”

Section: The Special Sectionmentioning

confidence: 99%

Some current topics in model checking

Huth

2006

Int J Softw Tools Technol Transfer

View full text Add to dashboard Cite

Abstract. Model checking is a particular approach to property verification of systems. One describes a system in a mathematical model, expresses the properties one wishes to verify for the system in a formal language, and then checks whether the model satisfies the formal property. Invented 25 years ago, this approach is fully automatic and has therefore gained wide acceptance and is increasingly being used in commercial research & development units. Impediments remain on the road to successful technology transfer. For one, the size of models often increases exponentially in the number of variables or sub-models, preventing scalable automation. Abstracting a model to reduce its size can be a cost-effective way of addressing this. For another, systems and models may be subject to change, e.g. in an incremental design process. One then seeks cost-effective means of ascertaining that property verifications remain to be valid as models evolve. This special section presents current research on such abstraction and change management of model checking.

show abstract

“…This verification approach is a form of bounded verification [17]. Researchers have argued and experimentally shown that checking all inputs within a small scope can effectively detect a high portion of bugs and achieve high statement and branch coverage [5,12,19,38].…”

Section: Introductionmentioning

confidence: 99%

Verifying systems rules using rule-directed symbolic execution

CuiHeming¹,

HuGang²,

WuJingyue³

et al. 2013

SIGPLAN Not.

View full text Add to dashboard Cite

Systems code must obey many rules, such as "opened files must be closed." One approach to verifying rules is static analysis, but this technique cannot infer precise runtime effects of code, often emitting many false positives. An alternative is symbolic execution, a technique that verifies program paths over all inputs up to a bounded size. However, when applied to verify rules, existing symbolic execution systems often blindly explore many redundant program paths while missing relevant ones that may contain bugs.Our key insight is that only a small portion of paths are relevant to rules, and the rest (majority) of paths are irrelevant and do not need to be verified. Based on this insight, we create WOOD-PECKER, a new symbolic execution system for effectively checking rules on systems programs. It provides a set of builtin checkers for common rules, and an interface for users to easily check new rules. It directs symbolic execution toward the program paths relevant to a checked rule, and soundly prunes redundant paths, exponentially speeding up symbolic execution. It is designed to be heuristic-agnostic, enabling users to leverage existing powerful search heuristics.Evaluation on 136 systems programs totaling 545K lines of code, including some of the most widely used programs, shows that, with a time limit of typically just one hour for each verification run, WOODPECKER effectively verifies 28.7% of the program and rule combinations over bounded input, whereas an existing symbolic execution system KLEE verifies only 8.5%. For the remaining combinations, WOODPECKER verifies 4.6 times as many relevant paths as KLEE. With a longer time limit, WOODPECKER verifies much more paths than KLEE, e.g., 17 times as many with a fourhour limit. WOODPECKER detects 113 rule violations, including 10 serious data loss errors with 2 most serious ones already confirmed by the corresponding developers.

show abstract

Elements of style: analyzing a software design feature with a counterexample detector

Cited by 115 publications

References 24 publications

La especificación formal en contexto: actual y futuro

La especificación formal en contexto: actual y futuro

Some current topics in model checking

Verifying systems rules using rule-directed symbolic execution

Contact Info

Product

Resources

About