1 / 18

Spec#: A Formal Approach to Enhancing C# Software Development with Contracts and Verification

Spec# is an extension of C# developed by Microsoft Research that implements a sound programming methodology aimed at enhancing the correctness and maintainability of software. It introduces non-null types, checked exceptions, and class contracts, enabling developers to specify preconditions and postconditions for methods. Additionally, it integrates with Visual Studio to provide tooling support like Boogie static verifier, IntelliSense, and runtime checks. As software development increasingly demands formal specifications to eliminate hidden assumptions, Spec# offers an accessible way for newcomers to adopt rigorous software practices.

connor-black
Download Presentation

Spec#: A Formal Approach to Enhancing C# Software Development with Contracts and Verification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Spec# Andreas Vida

  2. Motivation • Correct and maintainable software • Cost effective software production • Implicit assumptions easily broken→ Need more formal specification • Integration into a popular language

  3. What has been done before • Pioneering languages • Gipsy • Euclid • More recent developments • Eiffel • SPARK • JML

  4. Now: Spec# • Extension of C# (Microsoft Research) that provides: • A sound programming methodology • Tools to enforce this methodology • Smooth adoption path for new-comers

  5. Components of Spec# • Boogie static-verifier • Spec# compiler • Emits run-time checks • Integration into Visual Studio • IntelliSense code completion • Syntax Highlighting

  6. Spec# language features • non-null types • checked exceptions • class contracts (object invariants) • method contracts • pre- and (exceptional) postconditions • frame conditions • inheritance of specification

  7. Non-null types • Notation: T! • Constructors need initialiser-fields for each non-null field→ evaluated before base-class-constructor call! class Student: Person { Transcript! t; public Student(string name, EnrollmentInfo! e): t(new Transcript(e)), base(name) { /*…*/} //… }

  8. Checked vs. unchecked exceptions • C# only has unchecked exceptions • Spec# in this way similar to Java • Considers 2 types of exceptions: • Admissible failures → interface: ICheckedException • Client failures, observed program errors → derived from: Exception

  9. Method contracts • Preconditions example: class ArrayList { publicvirtualvoid Insert(int index, object value) requires 0 <= index && index <= Count; requires !IsReadOnly && !IsFixedSize; { /* … */ } //… }

  10. Preconditions • Enforced by run-time checks that throw a RequiresViolationException • An alternative exception type can be specified using an otherwise clause: class A { publicvoid Foo(int a) requires a > 0 otherwise ArgumentOutOfRangeException; { /* … */ } }

  11. Postconditions • ArrayList.Insert’s postconditions: ensures Count == old(Count) + 1; ensures value == this[index]; ensures Forall{ int i in 0: index; old(this[i]) == this[i]}; ensures Forall{ int i in index: old(Count); old(this[i]) == this[i+1]} • Complex quantified expressions supported • Boogie attempts to verify postconditions • Eiffel’s mechanism: old() are saved away at the method’s entrance

  12. Exceptional postconditions • Methods have a throws-set (as in Java) • throws clause (only for checked exceptions) can be combined with postconditions: void ReadToken(ArrayList a) throws EndOfFileException ensures a.Count == old(a.Count); { /*… */ } • “Foolproof”: if static checks can’t ensure that the exception is checked then run-time checks are emitted

  13. Class contracts • Object invariants: class AttendanceRecord { Student[]! students; bool[]! absent; invariant students.Length == absent.Length; /*…*/ } • Often need to be temporarily broken → do this explicitely:expose (variable) { … };

  14. Frame conditions • Restrict which part of the program state can be modified by a method class C { int x, y; void M() modifies x; { x++; } } • How to change private parts of an outside class? → wildcards: modifies this ^ ArrayList; • Still a problem: aggregate objects

  15. Run-time checking • Pre- and postconditions are turned into (tagged) inlined code • Conditions violated at run-time → appropriate contract exception • 1 method is added to each class using invariants • Object fields added: • invariant level • owner of an object

  16. Boogie: Static verification • Intermediate language → BoogiePL • Inference system • Obtains properties (loop invariants) then adds assert/assume statements • Creates acyclic control flow graph by introducing havoc statements • Calls the “Simplify” theorem prover • Maps results back onto source code

  17. Future plans • Out-of-band specification • Add specification for the .NET base class library → semi-automatically • Provide Transformations: • Contracts to natural language • Spec# to C# compiler

  18. Time for questions

More Related