III lecture: Contracts and Abstract Data Types. An obligation from last lecture... An obligation from last lecture... (2) January/February 2013

Transcription

1 III lecture: Contracts and Data Types Dip. di Informatica Università degli Studi di Milano, Italy January/February 201 An obligation from last lecture... An obligation from last lecture... (2) 1 class TEST_STABLE_STATES feature make 4 require ok_pre("make") 5 do print("executing make%n") 6 mycommand 7 ensure ok_post("make") 8 end 9 mycommand 10 require ok_pre("mycommand") 11 do print("executing mycommand%n") 12 ensure ok_post("mycommand") 1 end 14 ok_inv: BOOLEAN do 15 print("%n") 16 Result := True 17 end 18 ok_pre (where: STRING): BOOLEAN do 19 print("checking "+where+"%n") 20 Result := True 21 end 22 ok_post (where: STRING): BOOLEAN do 2 print("checking "+where+"%n") 24 Result := True 25 end 26 invariant ok_inv 27 end 1 class CLIENT root class feature {NONE} 4 s: TEST_STABLE_STATES 5 make do 6 print("making a TEST_STABLE_STATES object s%n") 7 create s.make 8 print("asking s for service mycommand%n") 9 s.mycommand 10 end 11 end Output: Making a TEST_STABLE_STATES object s Checking make Executing make Checking mycommand Executing mycommand Checking mycommand Checking make Asking s for service myfeature Checking mycommand Executing mycommand Checking mycommand 1 class ROOT_TEST_STABLE_STATES feature 4 make 5 require ok_pre("make") Forbidden when root 6 do 7 print("executing make%n") 8 mycommand 9 ensure ok_post("make") 10 end 11 mycommand 12 require ok_pre("mycommand") 1 do 14 print("executing mycommand%n") 15 use myother as a client, not internally 16 Current.myother 17 ensure ok_post("mycommand") 18 end 19 myother 20 require ok_pre("myother") 21 do 22 print("executing myother%n") 2 ensure ok_post("myother") 24 end Output: Executing make Checking mycommand Executing mycommand Checking myother Executing myother Checking myother Checking mycommand Checking make 25 ok_inv: BOOLEAN do print("%n"); Result := True; end 26 ok_pre (where: STRING): BOOLEAN do print("checking " + where + "%N"); Result := True; end 27 ok_post (where: STRING): BOOLEAN do print("checking " + where + "%N"); Result := True; end 28 invariant ok_inv 29 end

2 Final notes on Eiffel The Indirect Invariant Effect Contract are seen only from a client point of view: internally more freedom is available Predicates are supposed to be declarative, but they can be arbitrary code: beware of side-effects Creators make objects that satisfy invariants, and any command or query preserve them. Unfortunately, this does not guarantee that the invariants always hold! The problem is aliasing: even if every a.f preserves the invariant of a, some b.g might influence a via aliasing 1 class A... feature forward: B... 2 invariant (forward /= Void) implies (forward.backward = Current) end 4 class B 5 feature backward: A 6 attach (a1: A) do backward := a1; end 7 end b.attach(void) Data Types (ADT) Stack Describing a type is crucial in specification: but we do not want to over-specify the implementation(s): ideally we want strictly abstract descriptions are a remarkable theory, whose purpose is to describe stacks [E.W. Dijkstra] Unfortunately, few cases are so clean as the classical example of ADT: a stack type. An abstract description make: STACK[G] push: STACK[G] G STACK[G] pop: STACK[G] top: STACK[G] STACK[G] G empty: STACK[G] BOOLEAN indicates partial functions: to restrict the domain we need to express some (pre-)conditions pop(s) requires empty(s) top(s) requires empty(s)

3 Stack axioms Sufficient completeness a. empty(make) b. empty(push(s, x)) c. top(push(s, x)) = x d. pop(push(s, x)) = s Can be used to calculate: top(pop(push(pop(push(push(pop(push(push(push(make, x 1 ), x 2 ), x )),- top(pop(push(push(make, x 4 ), x 5 )))), x 6 )), x 7 ))) x 4 However, not all well-formed expressions are correct: pop(make) An ADT specification for a type T is said to be sufficiently complete when: it is possible to establish correctness of any well-formed expression any correct expression can be computed to a value in a form not involving T Obviously enough, the specification is not useful if is not consistent: i.e., if it is able to give two different results with different derivations/computations. Proving completeness and/or consistency is in general undecidable. Stack is sufficiently complete Stack in Eiffel class library We can start by defining the weight of a Stack expression. weight(make) = 0 weight(push(s, x)) = weight(s) + 1 weight(pop(s)) = weight(s) 1 By mathematical induction is now possible to reason about the completeness. Looking at the Stack class in standard library can be a useful exercise... flatshort.html

4 Implementing ADTs /Concrete relationship 1 class STACK_ARRAYUP feature 4 make do 5 create rep.make_empty 6 end 7 empty: BOOLEAN do 8 Result := rep.is_empty 9 end 10 top: INTEGER 11 require not empty 12 do 1 Result := rep[rep.upper] 14 end 15 push (x:integer) do 16 rep.force(x, rep.upper + 1) 17 end 18 pop: INTEGER 19 require not empty 20 do 21 Result := top 22 rep.remove_tail(1) 2 end 24 feature {NONE} 25 rep: detachable ARRAY[INTEGER] 26 end 1 class STACK_LIST feature 4 make do 5 create rep.make 6 end 7 empty: BOOLEAN do 8 Result := rep.is_empty 9 end 10 top: INTEGER 11 require not empty 12 do 1 Result := rep.last 14 end 15 push (x:integer) do 16 rep.extend(x) 17 rep.finish 18 end 19 pop: INTEGER 20 require not empty 21 do 22 Result := top 2 rep.remove 24 end 25 feature {NONE} 26 rep: detachable LINKED_LIST[INTEGER] 27 end Object 1 a 1 f Object 2 a 2 abstraction Concrete Object 1 c1 feature abstraction Concrete Object 2 c2 To be consistent, this diagram must commute: if f (a 1 ) = a 2 then abstraction(c1.feature) = a 2 To the abstraction (partial) function corresponds a representation relation. Implementation invariants to Java Certain assertions appear in invariants although they have no direct counterparts in the abstract data type specifications. These assertions involve attributes, including some secret attributes which, by definition, would be meaningless in the abstract data type. There are several attempts to export to Java (considered more mainstream ). Using assertion and/or assertion libraries: poor support of the Including it in the language by exploiting special comments or Java attributes (code metadata): it is possible to take into account inheritance, etc.

5 example example = "DummyContract") 2 public class Dummy{ protected List m_stuff = new LinkedList(); 4 public int additem(object item){ 5 m_stuff.add(item); 6 return m_stuff.size(); 7 }} 8 public class DummyContract extends ContractBase<Dummy>{ 9 public DummyContract(Dummy target){ 10 super(target); 11 } 12 1 public void classinvariant(){ 14 assert m_target.m_stuff!= null; 15 } public void pre_additem(object item) { 18 super.setpreconditionvalue("list size", m_target.m_stuff.size()); 19 } public void post_additem(object item) { 22 assert m_target.m_stuff.contains(item); 2 int presize = super.getpreconditionvalue("list size"); 24 assert presize == m_target.m_stuff.size() 1; 25 assert m_target.m_stuff.size() == super.getreturnvalue(); 2} 1 import com.google.java.contract. ; "class invariant 1", 4 "class invariant 2" 5 }) 6 class MyClass { precondition") postcondition") 9 SomeType somemethod(...) { } "multi clause", 15 "precondition" 1) "SomeException", "exceptional postcondition" }) 18 AnotherType anothermethod(...) { } 21 } A pragmatic approach In general, since DbC is added, these frameworks suggest a more pragmatic (= open to compromise) use of the constructs. From documentation: Should you put a precondition on pop that forbids its invocation if the stack is empty? Well that depends. In the end it is a design question. 1 class ConservativeStack<T> { 2 public boolean isempty() {... } 5 public T pop() {... } 1 class LiberalRobustStack<T> { 2 public boolean isempty() {...} => result == null") 5 public T pop() {... } A more sophisticated approach is taken by : the Java Modeling Language (Leavens, 1999). A ing language: contracts are on s of code The abstraction function can be made explicit Rich assertion language \forall, nullable, assignable... 1 class LiberalStack<T> { 2 public boolean isempty() {...} "isempty()"}) 5 public T pop() {... }

6 Example example (concrete) 1 public class Account { 2 private int bal; 4 requires amt >= 0; ensures balance() == / 6 public Account(int amt) { 7 bal = amt; 8 } 9 10 requires amt > 0 && amt <= acc.balance() && acc!= null; ensures balance() == \old(balance()) + amt && acc.balance() == \old(acc.balance() / 1 public void transfer(int amt, Account acc) { 14 acc.withdraw(amt); 15 deposit(amt); //@ public invariant balance() >= 0; 19 public / int balance() { 20 return bal; 21 } 1 public class ArrayOps { 2 private / Object[] a; //@ public invariant 0 < a.length; 4 requires 0 < arr.length; ensures this.a == arr; / 7 public void init(object[] arr) { 8 this.a = arr; 9 } 10 } Modeling issues Stack example Can private fields be mentioned in public specifications? Can pre-conditions be hidden from clients? Similar questions for invariants introduces variables, used only in the specification. 1 public interface Gendered { 2 //@ public instance String gender; //@ ensures 4 result == gender.equals("female"); 5 public / boolean isfemale(); 7 8 public class Animal implements Gendered { 9 protected boolean gen; //@ in gender; 10 protected represents gender < (gen? "female" : "male"); / 1 public / boolean isfemale() { 14 return gen; 15 } 1 in is a keyword, meaning in which data group the variable falls. Model feature s group contains features used in its represents.

7 Syntactic sugar Ghost variables 1 protected / int feature = 0; 2 // Syntactic sugar for 4 5 //@ public int feature; 6 //@ protected int _feature = 0; //@ in feature; 7 //@ protected represents feature <- _feature; Sometimes one needs even specification-only data, without any represents clause. They are called ghost feature. 1 public class Object { 2 //@ public ghost Object owner = null; /... / 4 } 5 Assignment: 6 //@ set a.owner = this;