Introduction to Components and Specifications Using RESOLVE

1. Introduction to Components and Specifications Using RESOLVE Murali Sitaraman Clemson University

2. Overview • Specifications provide user-oriented cover story • Designs address efficiency and sufficient functional completeness issues • Specifications hide implementation-specific information • Multiple implementations may be developed to satisfy the same specification

3. Languages for Formal Specification ANNA (and SPARK) for Ada JML for Java Larch/C++ for C++ Spec# for C# … Eiffel RESOLVE … VDM Z

4. Common Principles: Data Abstraction Specification Specifications are contracts Formal; unambiguous Mathematical logic Use a combination of well-known mathematical theories and notation Specify mathematical models for objects Specify the behavior of operations using those models

5. Example: Use of Mathematical Theories Concept Stack_Template(type Entry; …); uses String_Theory; Type Family Stack is modeled by … Operation Push… Operation Pop… … end Stack_Template;

6. Alternative Specification of Push Operation Operation Push_1 (restores E: Entry; updates S: Stack); requires |S| < Max_Depth; ensures S = <E> o #S; Note: Implementation needs to make a copy of the Entry E. This could be inefficient if entries are large.

7. Alternative Specification of Push Operation Operation Push_2 (clears E: Entry; updates S: Stack); requires |S| < Max_Depth; ensures S = <#E> o #S; Note: Implementation needs to “clear”, i.e., initialize the Entry E. …

8. Alternative Specification of Push Operation Operation Push (alters E: Entry; updates S: Stack); requires |S| < Max_Depth; ensures S = <#E> o #S; Note: Implementation may change Entry E in any way, so it permits the most efficient implementations; it is the most flexible specification

9. Clients have flexibility… Operation Push (alters E: Entry; updates S: Stack); requires |S| < Max_Depth; ensures S = <#E> o #S; Example code to do Push_1 (i.e., “restore” pushed entry): Copy(E, Temp); Push(Temp, S); Example code to do Push_2 (i.e., “clear” the pushed entry: Push(E, S); Clear(E);

10. Specification of Operations Operation Push (alters E: Entry; updates S: Stack); requires |S| < Max_Depth; ensures S = <#E> o #S; Operation Pop (replaces R: Entry; updates S: Stack); requires |S| > 0; ensures #S = <R> o S; Operation Depth (restores S: Stack): Integer; ensures Depth = |S|; …

11. Specification of Operations Operation Push (alters E: Entry; updates S: Stack); requires |S| < Max_Depth; ensures S = <#E> o #S; Operation Pop (replaces R: Entry; updates S: Stack); requires |S| > 0; ensures #S = <R> o S; Operation Depth (restores S: Stack): Integer; ensures Depth = |S|; …

12. Requires and Ensures clauses • Requirements and guarantees • Requires clauses are preconditions • Ensures clauses are postconditions • Who is responsible for requires clauses? • Client (i.e., caller) • Implementer • Neither • Both • Discussion of consequences

13. Requires and Ensures clauses • Requirements and guarantees • Requires clauses are preconditions • Ensures clauses are postconditions • Who is responsible for requires clauses? • Client (i.e., caller) • Implementer • Neither • Both • Discussion of consequences

14. Understanding specifications • Please see the tutorials at the web interface under help on: • String theory notations • Understanding specification parameter modes • Understanding details of specifications

15. Using Reusable Components • Users (clients) need to know only interface specifications • Users need to supply appropriate parameters to instantiate • Depending on the paradigm, special operations are automatically available on objects • Assignment in Java (e.g., S = T) • Swap in RESOLVE (e.g., S :=: T)

16. Multiple Implementations • Alternative implementations provide the same functionality • Provide performance trade-offs • time vs. space • average case vs. worst case • Efficiency vs. predictability • some subset of methods vs. some others • Users pick ones best fitting their requirements when instantiating