Formal Specification of Interfaces Jason Hallstrom and Murali Sitaraman Clemson University

Basics An interface Describes what classes or components do Does not describe how they should do it Is a contract between component users (clients) and developers (implementers) If the users satisfy the requirements for using the component, the component will provide guarantees

Principles of Interface Design Information hiding Hide details unnecessary to use the component Abstraction Provide a “cover story” or explanation in user-oriented terms so they can understand the interface

Informal Specifications Examples from the web Do they support information hiding? Do they support abstraction? Can they generalize? Is it possible to make them unambiguous?

Informal Specifications Straightforward descriptions Push pushes an object on a stack How much do they help? Use of metaphors A Queue is like a line at a fastfood restaurant Do they generalize? Use of implementation details Push behaves like AddElement method on Vector Is this appropriate for a user-oriented cover story?

Characteristics of Good Specifications Simple Clear Precise Concise Implementation-independent Consistent Sufficient completeness Others …

What does this code do? int x, y; … x = sum(x, y); y = difference(x, y); x = difference(x, y);

What does this code do? int x, y; … x = foo(x, y); y = bar(x, y); x = bar(x, y);

Specification of Integer Operations Think of ints as integers in math int sum (int i, int j); requires MIN_VALUE <= i + j and i + j <= MAX_VALUE; ensures sum = i + j; int foo (int i, int j); ensures foo = i + j;

Contract specifications 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

Contract specifications Requirements and guarantees Requires clauses are preconditions Ensures clauses are postconditions Who is responsible for requires clauses? Client (i.e., caller) Implementer Neither Both Consequences

Specification of Stacks Mathematical modeling What can we think of stacks as “mathematically”?

Mathematical Strings Unlike sets, strings have order Notations Example: Str(Z) for String of integers Notations Empty string (written empty_string or L) Concatenation ( alpha o beta ) Length ( |alpha| ) String containing one entry ( <5> )

Specification of IntStack Interface Suppose IntStack is an interface uses Integer_Theory, String_Theory; Think of stacks of Integers as “math strings” of integers this: Str(Z); Suppose Max_Depth is the maximum size Constraints |this| <= Max_Depth; Specification of Constructor Initialization ensures this = empty_string; Exercises: Specification of other Stack operations

Specification of IntStack Interface Operation push (int x); updates this; restores x requires |this| < Max_Depth ensures this = <x> o #this; int Operation pop (); updates this; requires |this| > 0; ensures #this = <result of pop()> o this; int Operation depth (); preserves this; ensures result of depth = |this|;

Specification of IntStack Interface Operation push (int x); updates this; restores x requires |this| < Max_Depth ensures this = <x> o #this; int Operation pop (); updates this; requires |this| > 0; ensures #this = <pop()> o this; int Operation depth (); preserves this; ensures depth = |this|;

Other Specification Questions What is the specification of “=“ to assign one IntStack object to another? If you defined a “clone” method, what is its specification? What are the advantages of using “=“ over “clone”? What are the advantages of using “clone” over equal?