Skip to content
Free planNo credit card requiredStart writing
AI for Research home
AI for Research home
Dashboard
Sign inGet started

Search 250 million research papers

Read the abstract, see who wrote it and who cites it, and get the citation in APA, MLA, Chicago or Harvard.

About 1,520 papers for “executable specifications”

Approaches to executable specifications

Stephen W. Smoliar · 1982

At the final panel discussion of the 5th International Conference on Software Engineering, the following obr~rvations were offered by Robert Balzer

Cited by 0Open access

Reasoning with executable specifications

Fraer, Ranan, Bertot, Yves, Institut National de Recherche en Informatique et en Automatique (INRIA), 06 - Valbonne (France). Unite de Recherche de Sophia-Antipolis · OpenGrey (Institut de l'Information Scientifique et Technique) · 1996

Cited by 0

Executable formal specifications with Clojure

Matti Nieminen · Trepo - Institutional Repository of Tampere University · 2015

In software projects, where formal specifications are utilized, programmers usually need to know separate languages and tools for tasks related to programming and formal specifications. To remedy this situation, this thesis proposes a Clojure-based formal specification method consisting of a library and tool for writing and executing formal specifications. \n\nThe library and the tool are targeted for Clojure programmers: the library enables programmers to write formal specifications with Clojure, which allows the usage of the same language for formal specifications and the implementation. The tool, that is used together with the library, allows simulating the specifications by executing them. The method presented in this thesis does not aim for formal verification with mathematical proving. Instead, the goal of the method is to offer support for formal specifications without intimidating the developers. \n\nThe developed method eases the adoption of formal specifications in projects, where Clojure is used but formal specifications are still considered too costly to adopt; the library and the tool enable Clojure programmers to adopt formal specifications in their software projects without additional costs, as the language for the formal specification and the implementation is the same. The author's method also allows working iteratively from the specification to implementation because the models created with the author's library and tool can be transformed into implementation straightforwardly.

Cited by 0Open access

Towards Executable Specifications for Microservices

José Ghislain Quenum, Samir Aknine · 2018

This paper presents an empirical approach for microservice automated testing. With the rise of the agile methodology, automated testing has gained momentum in software development, including using microservices as an architectural style. However, the tests are not always related to the core specifications of the system being developed. In this paper, we discuss an approach to derive the tests, especially the acceptance tests, from the specifications of the systems. To avoid any ambiguity in the specifications, we focus on the formal specifications of the system. To this end, we introduce intelligent agents as a conceptual unit to encapsulate the formal specifications of services. Indeed, a comparison of microservice tenets and the general characterization of agents reveals that both can be thought of as autonomous software entities, driven by goals and evolving within a distributed environment and communicating with one another. Using a real-world application we show how agent formal specifications can be linked to microservice automated testing.

Cited by 7

From Executable Specifications to Java

Angel Herranz, Noelia Maya, Juan Jose Moreno-Navarro · 2003

In this paper the authors study a pair of constructs in a formal specification language that can be directly translated into readable and relatively efficient code. Those constructs are algebraic types and (an extended concept of logical) quantification. The translation is guided by object oriented design patterns that makes the synthesised code easily understandable by ordinary developers.

Cited by 0

PLEASE:Predictable Logic based ExecutAble SpeCifications

Robert B. Terwilliger, Roy H. Campbell · 1986

Article Free Access Share on PLEASE:Predictable Logic based ExecutAble SpeCifications Authors: Robert B. Terwilliger Department of Computer Science, University of Illinois at Urbana-Champaign, 252 Digital Computer Laboratory, 1304 West Springfield Avenue, Urbana, IL Department of Computer Science, University of Illinois at Urbana-Champaign, 252 Digital Computer Laboratory, 1304 West Springfield Avenue, Urbana, ILView Profile , Roy H. Campbell Department of Computer Science, University of Illinois at Urbana-Champaign, 252 Digital Computer Laboratory, 1304 West Springfield Avenue, Urbana, IL Department of Computer Science, University of Illinois at Urbana-Champaign, 252 Digital Computer Laboratory, 1304 West Springfield Avenue, Urbana, ILView Profile Authors Info & Claims CSC '86: Proceedings of the 1986 ACM fourteenth annual conference on Computer scienceFebruary 1986 Pages 349–358https://doi.org/10.1145/324634.325453Published:01 February 1986Publication History 12citation166DownloadsMetricsTotal Citations12Total Downloads166Last 12 Months3Last 6 weeks1 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF

Cited by 11

Executable Interval Temporal Logic Specifications

Cau, Antonio, Kuhn, Stefan, Hoey, James · arXiv (Cornell University) · 2021

In this paper the reversibility of executable Interval Temporal Logic (ITL) specifications is investigated. ITL allows for the reasoning about systems in terms of behaviours which are represented as non-empty sequences of states. It allows for the specification of systems at different levels of abstraction. At a high level this specification is in terms of properties, for instance safety and liveness properties. At concrete level one can specify a system in terms of programming constructs. One can execute these concrete specification, i.e., test and simulate the behaviour of the system. In this paper we will formalise this notion of executability of ITL specifications. ITL also has a reflection operator which allows for the reasoning about reversed behaviours. We will investigate the reversibility of executable ITL specifications, i.e., how one can use this reflection operator to reverse the concrete behaviour of a particular system.

Cited by 0Open access

Executable Specifications for Concurrent Programming

Rafael Ramirez, Roland H.C. Yap, Joxan Jaffar et al. · 2007

this paper, we use as a basis a new concurrent programming model called Open Constraint Programming. Its roots are in Concurrent Constraint Programming where there is a shared constraint store, and synchronization is achieved via constraint entailment. The key advantages here are (a) the concurrent behavior of agents is formalized and explicitly represented as constraints, (b) the specification is executable, that is, agents run only as permitted, (c) there is a clear separation of the concurrent aspects of the agents' behavior from the rest of the code, and (d) agents are programming language independent.

Cited by 0

Executable Specifications for Java Programs

Aleksandar Milicevic, Daniel N. Jackson · DSpace@MIT (Massachusetts Institute of Technology) · 2010

In this thesis, we present a unified environment for running declarative specifications in the context of an imperative object-oriented programming language. Specifica-tions are Alloy-like, written in first-order relational logic with transitive closure, and the imperative language for this purpose is Java. By being able to mix imperative code with executable declarative specifications, the user can easily express constraint problems in-place, i.e. in terms of the existing data structures and objects on the heap. After a solution is found, our framework will automatically update the heap to reflect the solution, so the user can continue to manipulate the program heap in the usual imperative way, without ever having to manually translate the problem back and forth between the host programming environment and the solver language. We show that this approach is not only convenient, but, for certain problems, like puzzles or NP-complete graph algorithms, it can also outperform the manual implementation. We also present an optimization technique that allowed us to run our tool on heaps

Cited by 0Open access

Software estimation from executable specifications

Jie Gong, Daniel D. Gajski, Sanjiv M. Narayan · eScholarship (California Digital Library) · 1994

Previous work in software/hardware codesign has addressed issues in system modeling, partitioning, and mixed module simulation and integration. Software estimation, which provides software metrics to assist the software/hardware partitioning, has not been studied. In order to rapidly explore large design space encountered in software/hardware systems, automatic software estimation is indispensable in software/hardware partitioning in which designers or partitioning tools must trade off a hardware with a software implementation for the whole or a part of the system under design. In this report we present a software estimator that provides three software metrics --- execution time, program-memory size and data-memory size for a specific executing on a given processor. Experiments have shown that our estimator has less than 20% estimation errors on different designs spanning from straight line code to code with branches and loops and even to hierarchical specifications. Experiments also show that our estimator is fast and can provide rapid feedback to the designers or partitioning tools to quickly evaluate different design alternatives.

Cited by 40Open access

Functional programs as executable specifications

David A. Turner · Philosophical Transactions of the Royal Society of London Series A Mathematical and Physical Sciences · 1984

Abstract To write specifications we need to be able to define the data domains in which we are interested, such as numbers, lists, trees and graphs. We also need to be able to define functions over these domains. It is desirable that the notation should be higher order, so that function spaces can themselves be treated as data domains. Finally, given the potential for confusion in specifications involving a large number of data types, it is a practical necessity that there should be a simple syntactic discipline that ensures that only well typed applications of functions can occur. A functional programming language with these properties is presented and its use as a specification tool is demonstrated on a series of examples. Although such a notation lacks the power of some imaginable specification languages (for example, in not allowing existential quantifiers), it has the advantage that specifications written in it are always executable. The strengths and weaknesses of this approach are discussed, and also the prospects for the use of purely functional languages in production programming.

Cited by 29

Specifications are not (necessarily) executable

Ian J. Hayes, Cliff B. Jones · Software Engineering Journal · 1989

Specifications can be written in languages which have formal semantics. Their very formality, and the similarities with some aspects of implementation languages, invites the idea that specifications might be executed. This paper presents a number of arguments against that idea. The aim is to warn of the dangers of limiting specification languages to the point where all of their constructs can be executed. While conceding the difficulties of relating specifications to an understanding of the ‘requirements’ for a system, it is argued that other solutions should be sought than ‘executable specification languages’.

Cited by 197