Communicating sequential processes
Communicating sequential processes
“Sometimes” and “not never” revisited: on branching versus linear time temporal logic
Journal of the ACM (JACM) - The MIT Press scientific computation series
A classical mind
The Unified Modeling Language reference manual
The Unified Modeling Language reference manual
Communication and Concurrency
A Calculus of Communicating Systems
A Calculus of Communicating Systems
Petri Net Theory and the Modeling of Systems
Petri Net Theory and the Modeling of Systems
The Theory and Practice of Concurrency
The Theory and Practice of Concurrency
Design and Synthesis of Synchronization Skeletons Using Branching-Time Temporal Logic
Logic of Programs, Workshop
Combining Independent Specifications
FASE '01 Proceedings of the 4th International Conference on Fundamental Approaches to Software Engineering
The temporal logic of programs
SFCS '77 Proceedings of the 18th Annual Symposium on Foundations of Computer Science
A hierarchy of failures-based models: theory and application
Theoretical Computer Science - Expressiveness in concurrency
Machine-Verifiable Responsiveness
Electronic Notes in Theoretical Computer Science (ENTCS)
| Hi-index | 0.00 |
Consistency between a process and its specification expressed in CSP is typically presented as a refinement check. Within the traces model consistency is measured by examining only the traces of the systems, whilst in the finer stable failures model the possibility of subsequently refusing a combination of events is also taken into consideration. The contribution of this paper is to identify and motivate the need for alternative measures of consistency, and to present and prove the soundness and completeness of general techniques for automatically verifying such consistencies. We achieve this by masking all failures information other than that associated with the measure in question. More concretely, we describe methods for automatically checking: that a process can refuse a given set of events after any trace only if its specification can refuse the same set of events after the same trace; that a process might deadlock after any trace only if its specification might also deadlock after the same trace; and that a process might after any trace refuse a given number of events of a particular class only if its specification might also refuse the same set after the same trace.