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