1. Omnibus: A clean language and supporting tool for integrating different assertion-based verification techniques Thomas Wilson, Savi Maharaj, Robert G. Clark July 2005 Department of Computing Science and Mathematics Workshop on Rigorous Engineering of Fault Tolerant Systems

2. Combining assertion-based verification approaches 3 assertion-based software verification approaches: –Run-time assertion checking (e.g. Eiffel) –Extended static checking (e.g. ESC/Java2) –Full formal verification (e.g. B, LOOP) Support verification at different levels of rigour to match different reliability requirements However, typically supported by separate tools The Omnibus project provides integrated support for all of these approaches –Enables use of different approaches for different parts of a single project –Managed via Verification Policies

3. A clean language similar to Java but simpler for users and provers Currently dominant projects use languages extending Java, C#, etc –Familiar to users, use on existing code –However, problems marshalling complexity –Complex annotations, minefield of aliasing-based special cases in theorem proving –Annotation burdens and theorem proving difficulty stretched to the limits Omnibus: new language –Superficially similar to Java: familiar –Not backward compatible Simplifications, restructuring e.g. value semantics by default –Simpler for users and provers

4. Relevance to dependable systems development and fault tolerance Relevant despite not being specifically designed to support fault tolerance Concrete definitions for important terms –Desired behaviour: given by specifications in assertions –Fault: assertion violation –Failure: top-level assertion violation Omnibus is primarily concerned with fault avoidance but can also be used to support existing fault tolerant techniques –Run-time assertion checks greatly aid fault detection and containment Faults detected earlier, closer to source, stops invalid calls –Check equivalence of diverse designs Integral for multi-version techniques –Statically verifying handling of a-priori known potential faults

5. Questions?