Abstract

We develop a logic for reasoning about requirement specification of objects with (internal and external) non-determinism. We try to achieve conceptual simplicity by avoiding the use of infinite sequences, restricting ourselves to finite traces, and by formulating a proof system satisfying the classical rules of first order logic. Under-specification is used to capture internal nondeterminism; enabling us to state general facts about any execution. This reduces the language complexity: non-deterministic objects are specified by means of a simple event relation, called the ready relation, whereas the underlying semantics is a set of models, each with a set of such relations. However, due to a non-standard interpretation, standard equational reasoning over object expressions is sound, and we obtain an expressive specification language, enabling us to express internal non-determinism, and enabling us to relate dierent execution points of several objects in the same specification formula, without the risk of making meaningless or inconsistent specifications. Our language is expressive enough to avoid the Brock-Ackerman anomaly and the merge anomaly. We present a sound and (relatively) complete basic proof system. The classical rules and axioms of first order logic with equality are sound. In addition, some rules and axioms are needed for the ready relation and other object operators considered. Refinement may be done in two ways: By enriching a loose specification over a set of objects, one may refine several objects (reducing the set of possible models). By an explicit refinement operator, one may refine a single object (reducing the number of possible executions in each model). Our overall goal is to develop a practically useful formalism for specifying and reasoning about systems of concurrent objects. It is essential that the proof system be simple, and that the specification language be based on concepts that are intuitively clear and mathematically simple. We focus on requirement specifications, rather than abstract system design. The specification of a system should be expressed in terms of observable concepts; and the formalism should be strong enough to express liveness as well as safety properties, and be well suited for system development. The proof system should be compositional, and one should be able to

Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call