Distributed systems: methods and tools for specification. An advanced course
Distributed systems: methods and tools for specification. An advanced course
Programming in MODULA-2 (3rd corrected ed.)
Programming in MODULA-2 (3rd corrected ed.)
Systematic software development using VDM
Systematic software development using VDM
What it means for a concurrent program to satisfy a specification: why no one has specified priority
POPL '85 Proceedings of the 12th ACM SIGACT-SIGPLAN symposium on Principles of programming languages
Concurrency Control in Distributed Database Systems
ACM Computing Surveys (CSUR)
Proving Liveness Properties of Concurrent Programs
ACM Transactions on Programming Languages and Systems (TOPLAS)
Specifying Concurrent Program Modules
ACM Transactions on Programming Languages and Systems (TOPLAS)
Communicating sequential processes
Communications of the ACM
A really abstract concurrent model and its temporal logic
POPL '86 Proceedings of the 13th ACM SIGACT-SIGPLAN symposium on Principles of programming languages
A Calculus of Communicating Systems
A Calculus of Communicating Systems
Reasoning about nonatomic operations
POPL '83 Proceedings of the 10th ACM SIGACT-SIGPLAN symposium on Principles of programming languages
"Sometime" is sometimes "not never": on the temporal logic of programs
POPL '80 Proceedings of the 7th ACM SIGPLAN-SIGACT symposium on Principles of programming languages
Introduction to VLSI Systems
The Collapsing Hierarchies
A Relational Notation for State Transition Systems
IEEE Transactions on Software Engineering
A logical view of composition and refinement
POPL '91 Proceedings of the 18th ACM SIGPLAN-SIGACT symposium on Principles of programming languages
Mechanically Verifying Concurrent Programs with the Boyer-Moore Prove
IEEE Transactions on Software Engineering
A stepwise refinement heuristic for protocol construction
ACM Transactions on Programming Languages and Systems (TOPLAS)
Ada/TL specification and verification of a distributed computation
SAC '92 Proceedings of the 1992 ACM/SIGAPP symposium on Applied computing: technological challenges of the 1990's
ACM Transactions on Programming Languages and Systems (TOPLAS)
ACM Transactions on Software Engineering and Methodology (TOSEM)
An introduction to assertional reasoning for concurrent systems
ACM Computing Surveys (CSUR)
Compositional specification and verification of distributed systems
ACM Transactions on Programming Languages and Systems (TOPLAS)
Inheritance of interface specifications (extended abstract)
IDL '94 Proceedings of the workshop on Interface definition languages
Interfacing Ada with verification languages
SETA2 Proceedings of the second international symposium on Environments and tools for Ada
ACM Transactions on Programming Languages and Systems (TOPLAS)
Interconnecting formalisms: supporting modularity, reuse and incrementality
SIGSOFT '95 Proceedings of the 3rd ACM SIGSOFT symposium on Foundations of software engineering
Proceedings of the 17th international conference on Software engineering
Creating formal specifications from requirements documents
ACM SIGSOFT Software Engineering Notes
Four dark corners of requirements engineering
ACM Transactions on Software Engineering and Methodology (TOSEM)
Proving specifications of tasking systems using Ada/TL
TRI-Ada '90 Proceedings of the conference on TRI-ADA '90
Covering the life cycle with Ada: Ada all the way
WADAS '89 Proceedings of the sixth Washington Ada symposium on Ada
Protection in programming-language translations
Secure Internet programming
Some guidelines for non-repudiation protocols
ACM SIGCOMM Computer Communication Review
Secure implementation of channel abstractions
Information and Computation
Getting computers to understand
Journal of the ACM (JACM)
Specifying Graceful Degradation
IEEE Transactions on Parallel and Distributed Systems
Comments on 'Temporal Logic-Based Deadlock Analysis for Ada' by G.M. Karam and R.J.A. Burh
IEEE Transactions on Software Engineering
A Theory of Interfaces and Modules - I: Composition Theorem
IEEE Transactions on Software Engineering
Specifying Transaction-Based Information Systems with Regular Expressions
IEEE Transactions on Software Engineering
Specification and Validation of Control-Intensive IC's in hopCP
IEEE Transactions on Software Engineering
On the Existence of Network Invariants for Verifying Parameterized Systems
Correct System Design, Recent Insight and Advances, (to Hans Langmaack on the occasion of his retirement from his professorship at the University of Kiel)
Security Protocols and Specifications
FoSSaCS '99 Proceedings of the Second International Conference on Foundations of Software Science and Computation Structure, Held as Part of the European Joint Conferences on the Theory and Practice of Software, ETAPS'99
Approaching a Formal Definition of Fairness in Electronic Commerce
SRDS '99 Proceedings of the 18th IEEE Symposium on Reliable Distributed Systems
Specifying reactive systems with attributed finite state machines
IWSSD '93 Proceedings of the 7th international workshop on Software specification and design
Developing reactive systems in a VDM framework
IWSSD '91 Proceedings of the 6th international workshop on Software specification and design
Eternity variables to prove simulation of specifications
ACM Transactions on Computational Logic (TOCL)
Distributed Computing
Operational specification with joint actions: serializable databases
Distributed Computing - Special issue: Specification of concurrent systems
Specifying modules to satisfy interfaces: a state transition system approach
Distributed Computing - Special issue: Specification of concurrent systems
Critique of the lake arrowhead three
Distributed Computing - Special issue: Specification of concurrent systems
Proving refinement using transduction
Distributed Computing - Special issue: Verification of lazy caching
Distributed Computing - Special issue: Verification of lazy caching
How the design of JML accommodates both runtime assertion checking and formal verification
Science of Computer Programming - Formal methods for components and objects pragmatic aspects and applications
Roadmap for enhanced languages and methods to aid verification
Proceedings of the 5th international conference on Generative programming and component engineering
Journal of Integrated Design & Process Science
Engineering and theoretical underpinnings of retrenchment
Science of Computer Programming
Universal extensions to simulate specifications
Information and Computation
Simulation Refinement for Concurrency Verification
Electronic Notes in Theoretical Computer Science (ENTCS)
Abstract compositional analysis of iterated relations: a structural approach to complex state transition systems
A formal analysis of the deferred update technique
OPODIS'07 Proceedings of the 11th international conference on Principles of distributed systems
Representing abstract architectures with axiomatic specifications and activation conditions
ECBS'97 Proceedings of the 1997 international conference on Engineering of computer-based systems
Simulation refinement for concurrency verification
Science of Computer Programming
MoDELS'05 Proceedings of the 2005 international conference on Satellite Events at the MoDELS
Principles for Computer System Design
ACM Turing award lectures
Behavioral interface specification languages
ACM Computing Surveys (CSUR)
Mathematical and Computer Modelling: An International Journal
Encapsulating deontic and branching time specifications
Theoretical Computer Science
Hi-index | 48.22 |
Over the past few years, I have developed an approach to the formal specification of concurrent systems that I now call the transition axiom method. The basic formalism has already been described in [12] and [1], but the formal details tend to obscure the important concepts. Here, I attempt to explain these concepts without discussing the details of the underlying formalism.Concurrent systems are not easy to specify. Even a simple system can be subtle, and it is often hard to find the appropriate abstractions that make it understandable. Specifying a complex system is a formidable engineering task. We can understand complex structures only if they are composed of simple parts, so a method for specifying complex systems must have a simple conceptual basis. I will try to demonstrate that the transition axiom method provides such a basis. However, I will not address the engineering problems associated with specifying real systems. Instead, the concepts will be illustrated with a series of toy examples that are not meant to be taken seriously as real specifications.Are you proposing a specification language? No. The transition axiom method provides a conceptual and logical foundation for writing formal specifications; it is not a specification language. The method determines what a specification must say; a language determines in detail how it is said.What do you mean by a formal specification? I find it helpful to view a specification as a contract between the user of a system and its implementer. The contract should tell the user everything he must know to use the system, and it should tell the implementer everything he must know about the system to implement it. In principle, once this contract has been agreed upon, the user and the implementer have no need for further communication. (This view describes the function of the specification; it is not meant as a paradigm for how systems should be built.)For a specification to be formal, the question of whether an implementation satisfies the specification must be reducible to the question of whether an assertion is provable in some mathematical system. To demonstrate that he has met the terms of the contract, the implementer should resort to logic rather than contract law. This does not mean that an implementation must be accompanied by a mathematical proof. It does mean that it should be possible, in principle though not necessarily in practice, to provide such a proof for a correct implementation. The existence of a formal basis for the specification method is the only way I know to guarantee that specifications are unambiguous.Ultimately, the systems we specify are physical objects, and mathematics cannot prove physical properties. We can prove properties only of a mathematical model of the system; whether or not the system correctly implements the model must remain a question of law and not of mathematics.Just what is a system? By "system," I mean anything that interacts with its environment in a discrete (digital) fashion across a well-defined boundary. An airline reservation system is such a system, where the boundary might be drawn between the agents using the system, who are part of the environment, and the terminals, which are part of the system. A Pascal procedure is a system whose environment is the rest of the program, with which it interacts by responding to procedure calls and accessing global variables. Thus, the system being specified may be just one component of a larger system.A real system has many properties, ranging from its response time to the color of the cabinet. No formal method can specify all of these properties. Which ones can be specified with the transition axiom method? The transition axiom method specifies the behavior of a System—that is, the sequence of observable actions it performs when interacting with the environment. More precisely, it specifies two classes of behavioral properties: safety and liveness properties. Safety properties assert what the system is allowed to do, or equivalently, what it may not do. Partial correctness is an example of a safety property, asserting that a program may not generate an incorrect answer. Liveness properties assert what the system must do. Termination is an example of a liveness property, asserting that a program must eventually generate an answer. (Alpern and Schneider [2] have formally defined these two classes of properties.) In the transition axiom method, safety and liveness properties are specified separately.There are important behavioral properties that cannot be specified by the transition axiom method; these include average response time and probability of failure. A transition axiom specification can provide a formal model with which to analyze such properties,1 but it cannot formally specify them.There are also important nonbehavioral properties of systems that one might want to specify, such as storage requirements and the color of the cabinet. These lie completely outside the realm of the method.Why specify safety and liveness properties separately? There is a single formalism that underlies a transition axiom specification, so there is no formal separation between the specification of safety and liveness properties. However, experience indicates that different methods are used to reason about the two kinds of properties and it is convenient in practice to separate them. I consider the ability to decompose a specification into liveness and safety properties to be one of the advantages of the method. (One must prove safety properties in order to verify liveness properties, but this is a process of decomposing the proof into smaller lemmas.)Can the method specify real-time behavior? Worst-case behavior can be specified, since the requirement that the system must respond within a certain length of time can be expressed as a safety property—namely, that the clock is not allowed to reach a certain value without the system having responded. Average response time cannot be expressed as a safety or liveness property.The transition axiom method can assert that some action either must occur (liveness) or must not occur (safety). Can it also assert that it is possible for the action to occur? No. A specification serves as a contractual constraint on the behavior of the system. An assertion that the system may or may not do something provides no constraint and therefore serves no function as part of the formal specification. Specification methods that include such assertions generally use them as poor substitutes for liveness properties. Some methods cannot specify that a certain input must result in a certain response, specifying instead that it is possible for the input to be followed by the response. Every specification I have encountered that used such assertions was improved by replacing the possibility assertions with liveness properties that more accurately expressed the system's informal requirements.Imprecise wording can make it appear that a specification contains a possibility assertion when it really doesn't. For example, one sometimes states that it must be possible for a transmission line to lose messages. However, the specification does not require that the loss of messages be possible, since this would prohibit an implementation that guaranteed no messages were lost. The specification might require that something happens (a liveness property) or doesn't happen (a safety property) despite the loss of messages. Or, the statement that messages may be lost might simply be a comment about the specification, observing that it does not require that all messages be delivered, and not part of the actual specification.If a safety property asserts that some action cannot happen, doesn't its negation assert that the action is possible? In a formal system, one must distinguish the logical formula A from the assertion ⊢ A, which means that A is provable in the logic; ⊢ A is not a formula of the logic itself. In the logic underlying the transition axiom method, if A represents a safety property asserting that some action is impossible, then the negation of A, which is the formula ┐A, asserts that the action must occur. The action's possibility is expressed by the negation of ⊢ A, which is a metaformula and not a formula within the logic. See [10] for more details.