1. D. WijesekeraSWE 699/IT 823: Precise Modeling1 Typing A Behavioral Notion of Subtyping By Barbara Liskov and Jeannette M. Wing in ACM Trans. Of Prog. Languages and Systems Vol 16, No 6, November 1994, Pages 1811-1843

2. D. WijesekeraSWE 699/IT 823: Precise Modeling2 Hierarchy and Inheritance 1.Type A is a subtype of B What does this mean? 2.Subtypes must provide expected methods with compatible signatures. 3.Objects of a subtype ought to behave the same as their super-types. 4.Eg: x: T := E should be legal provided that (type of ) E is a subtype of (the type of) T

3. D. WijesekeraSWE 699/IT 823: Precise Modeling3 What Ensures Stated Expectations? Answer: Invariants, called subtype requirement Subtype Requirement: –Let  x) be a predicate about object x of type T. –Then  y) should be true for objects of type S where S is a subtype of T Notation: –  x), x: S, y:T, S < T This is called a typing judgment  y) - An axiom, if you will, in proof about types

4. D. WijesekeraSWE 699/IT 823: Precise Modeling4 Where are these Issues Important? In programming languages: –In using inheritance properly –In type checking –In using types to catch (and report) errors In object oriented design: –In reuse: common reusable design patterns We need to ensure the “correctness” of reusable components. –In promoting common properties to supertypes –Application: Meta Models

5. D. WijesekeraSWE 699/IT 823: Precise Modeling5 What Should we be looking for in this Paper? We design using UML, hence properties –Drawn using UML –Stated in OCL Do we use/assume Liskov Inheritance –If so where? –Are we aware of the assumption? Do our designs violate them? Meta Model –When we inherit form the meta-model why should our modeling elements have the same behavior?

6. D. WijesekeraSWE 699/IT 823: Precise Modeling6 Back to Liskov+Wing Assumptions about properties They are formulas: –Is this true in UML? If not what should we do about them? –Are there pictorial formulas in UML? Do they satisfy subtype requirement? –How about typing judgments? Are there pictorial typing judgments? –Are properties about state expressible in OCL? All ? Some? None? Can we make an adequacy argument

7. D. WijesekeraSWE 699/IT 823: Precise Modeling7 Back to Liskov+Wing Assumptions about properties Formulas are invariants over: –Single states (to be defined shortly) –History properties over state transitions Properties limited to safety (that is nothing bad happens) Is that enough for UML?

8. D. WijesekeraSWE 699/IT 823: Precise Modeling8 Back to Liskov+Wing Properties not Considered Liveliness properties (that is something good happens) Is the OCL action clause a safety property or a liveliness property? How about constraints preventing two instances of the same object having the same state? Constraints that span across many states

9. D. WijesekeraSWE 699/IT 823: Precise Modeling9 Back to Liskov+Wing Properties not Considered Producer-Consumer: –Only one producer only one consumer Feature Models –Disjoint features

10. D. WijesekeraSWE 699/IT 823: Precise Modeling10 Back to Liskov+Wing Other Questions In the UML all meat-models are classes. Hence subtyping applies to –Sequence diagrams –Statecharts –Use Cases What subtyping principles have been used What inter-diagram consistency principles are necessary for view integration?

11. D. WijesekeraSWE 699/IT 823: Precise Modeling11 Models Models uses Environments, Stores, States and computation sequences. Env: Var -> Obj. Store: Obj -> Val. State: Env X Store. Computation sequence:   Tr 1  1 …  n-1 Tr n  n where. Each  i is a state, and. Each Tr i is a partial function on states.

12. D. WijesekeraSWE 699/IT 823: Precise Modeling12 More Notation! History: A subsequence of states in any computation. Methods come in three main categories: –Constructor: returns values of same type. –Observer: does not change the value. –Mutator: Can change the value. Can have mixed methods. Objects come into existence and get their initial values through Creators. These are class methods. Assumption: No objects are destroyed. Where is it used in Liskov’s paper?

13. D. WijesekeraSWE 699/IT 823: Precise Modeling13 Specifying Types Types name (disc of the) value space Per each method: –Name –Signature Including exceptions –Behavior Pre-conditions Post-conditions Note: no creators bag = type uses Bbag(bag for B) for all b:bag <- parameters put=proc(i:int) requires |b pre.elements| <b pre.bound modifies b ensures b post.elms=b pre.elms U {i}^ b post.bound=b pre.bound

14. D. WijesekeraSWE 699/IT 823: Precise Modeling14 Specifications Modifies: –Means no others are modified Can have signals specified: get’=proc() returns(int) signals(empty) modifies b ensures if b pre.elms ={} then signal empty else b post.elms=b. pre.elms-{result}^ result  b pre.elms ^ b post.bound-b pre.bound

15. D. WijesekeraSWE 699/IT 823: Precise Modeling15 Specifications Post condition= modifies ^ ensures Specifying Creators bag_create= proc(n:int) returns(bag) requires n>0 ensures new(result) ^ result post =({},100) bag_create_single=proc(i:int) returns(bag) ensures new(result) ^ result post =({i},100)

16. D. WijesekeraSWE 699/IT 823: Precise Modeling16 Ensuring the Validity of Invariants Data Type Induction. Make sure that they are valid when object is created. Show that if the invariant was valid before a call to a method, then it is valid after the call. Therefore, by induction, they are valid through any computation sequence.

17. D. WijesekeraSWE 699/IT 823: Precise Modeling17 Validity of Invariants For the Bag example, we need to show that. number of elements < bound of the bag. Invariant | b .elmts| < b .bound. Technically we need to ensure that.  x:  .x  dom(  ) =>  (x  ). This says that the invariant is true in any state of any computation sequence.

18. D. WijesekeraSWE 699/IT 823: Precise Modeling18 Validity of Invariants: Contd. In order to do so, we require that invariants are established at creation. That is technically stated as. For each creator of type   x:  .x  (result post /x  ). This says that the invariant is true in any state at which the creator is called.

19. D. WijesekeraSWE 699/IT 823: Precise Modeling19 Subtypes Subtype’s value space may be different from the super type’s value space. Therefore, to relate values of the subtype to those of the super-type, there needs to be an abstraction function. A subtype specification must say what are its super types. –We use a subtype clause for this purpose.

20. D. WijesekeraSWE 699/IT 823: Precise Modeling20 Example: Type BStack stack=type uses BStack(stack for S) Invariant length(s .items) < s pre.limit push=proc(i:int) requires s pre.items =/= [] modifies s ensures s post.items=s pre.items || [i] ^ s post.limit=s pre.limit Notation: || is concatenation and [] is the empty sequence

21. D. WijesekeraSWE 699/IT 823: Precise Modeling21 Bstack Continued Subtype of bag [push for put pop for get height for card]  st:S A(st)= where mk_elems : Seq -> M  I:Int, sq:Seq mk_elems([])={} mk_elems(sq||[i])=mk_elems(sq)U{i} Abstraction Function : A() maps elements of subtype to elements of the super type.

22. D. WijesekeraSWE 699/IT 823: Precise Modeling22 First Definition: Constraint Rules <:  =(O ,S,M) is a subtype of  =(O ,T,N) if there is –an abstraction function A: S => T and –A renaming function R: M => N satisfying the following: 1. It respects invariants:  s:S I  (s) => I  (A(s))

23. D. WijesekeraSWE 699/IT 823: Precise Modeling23 First Definition: Continuation-1 2. Subtype methods preserve super type method’s behavior (  subtype of  ). If m  of  is renamed to m  of  then the following must hold: ( 2.1 Signature Rule). A.m  and m  must have the same # of arguments. If the list of argument types of m  is  i, and that of m  is  i, then  i >  i for all i. (contravariance). B. Either both m  and m  must return results or neither does. If there is a result of m  and m  are  and  respectively, then  covariance  C. Exceptions of m  are contained in those of m 

24. D. WijesekeraSWE 699/IT 823: Precise Modeling24 Covariance and Contravariance

25. D. WijesekeraSWE 699/IT 823: Precise Modeling25 First Definition: Continuation-2 2.1 Methods Rule. Pre-Conditions: m .pre[A(x pre )/ x pre ]=>m . pre That means, any precondition holding for the super type must hold for the subtype. Post-Conditions: m . post => m .post[A(x pre )/ x pre, A (x post )/ x post ]. That means, any post condition holding for the sub type must hold for the super type.

26. D. WijesekeraSWE 699/IT 823: Precise Modeling26 First Definition: Continuation-3 3. Subtype constraints ensure super type constraints Constraint Rule: For all computations C and all states  and  such that  precedes  in C, C   x  x   => C  [A(x  )/ x , A(x  )/x  ]

27. D. WijesekeraSWE 699/IT 823: Precise Modeling27 Applying the Subtype Definition Back to Stack < Bag Example.  =(O stack,S,{push,pop,swap_top,height,equal}).  =(O bag,B,{put,get,card,equal}). Recall: –Bag’s value is a pair (elements, bound). –Stack’s value is a pair (items, limit). –Assume (can be proved that) each specification preserves constraints.

28. D. WijesekeraSWE 699/IT 823: Precise Modeling28 Application: Stack < Bag Example Abstraction function: –A(st) = (mk_elems(st.item),st.limit). maps a stack element to a bag element, where mk_elms is recursively defined as follows: mk_elems([]) = {}. mk_elems(sq || [i]) = mkelems(sq) U {i}. –Can show that function A respects invariants by induction of the length of sq.

29. D. WijesekeraSWE 699/IT 823: Precise Modeling29 Application: Stack < Bag Example Renaming function: R(push) = put R(pop) = get R(height) = card R(equal)=equal –Unmapped “additional” method in the subtype is swap_top

30. D. WijesekeraSWE 699/IT 823: Precise Modeling30 Application: Stack < Bag Example Need to show the correspondences between domain and range methods of R. Example: push and put. Precondition Rule Requires us to prove. |A(S pre ).elms| < A(S pre ).bound Implies. Length(S pre.items) < S pre.limit. Why is this true? –We will argue this informally.

31. D. WijesekeraSWE 699/IT 823: Precise Modeling31 Application: Stack < Bag Example To show that |A(S pre ).elms| < A(S pre ).bound Implies Length(S pre.items) < S pre.limit. Why is this true? –Length of the sequence S pre = size of the multiset A(S pre ).elms, as A maps the stack’s sequence component to bag’s multisets by making each element in the stack go into an element of the bag. –A : (Limit of the Stack) |-> (bound of the bag). Hence S pre.limit = A(S pre ).bound. –put’s precondition implies |A(S pre ).elms| < A(S pre ).bound. –Now substitute equals to equals and get the result.

32. D. WijesekeraSWE 699/IT 823: Precise Modeling32 Informal Justification of the Definition How does this definition guarantee that the subtype’s behavior is similar to the super type? Hence can call a subtype method instead of a super- type method

33. D. WijesekeraSWE 699/IT 823: Precise Modeling33 Informal Justification of the Definition Preservation of Invariants and history properties. –We can show that rules ensure that any proposition true about the super type is true about the subtype. –Like a soundness rule in proofs. Values: –Covariance of returned values. –Contravariance of the inputs. Guarantee that a calling a subtype method does not result in a type violation of the caller-calee relationship.

34. D. WijesekeraSWE 699/IT 823: Precise Modeling34 Review: Covariance and Contravariance

35. D. WijesekeraSWE 699/IT 823: Precise Modeling35 Extension Maps Recall that for the constraint approach to work, we must: –Add all required constraints as predicates. –Prove that subtype constraints ensure super type constraint modulo the abstraction map. Disadvantage: Loss of the history rule: m .pre ^ m .post =>  (x pre /x , x post /x  ).  (x ,x  ).

36. D. WijesekeraSWE 699/IT 823: Precise Modeling36 History Rule We prefer to argue inductively as follows: –For every proposition , If  holds after constructors are called If  holds in state , then  holds in state  after  –Then  must hold. History rule is the above (general) inductive argument! Using this rule, we may prove a property  for a type  that may not hold for a subtype of . Consequence: must specify enough constraints so that all necessary properties can be derived from these constraints.

37. D. WijesekeraSWE 699/IT 823: Precise Modeling37 Subtypes using Extension Maps Invariance Rule: (that abstraction respects invariants) – same as constraint based approach \/s: S I  (s) => I  (s) Signature Rules: –Contravariance of arguments (stays the same) –Covariance of results (stays the same) Method Rules: –Precondition rules strengthened to equality m .pre[A(x pre )/x pre ] =m .pre –Post-condition rule stays the same

38. D. WijesekeraSWE 699/IT 823: Precise Modeling38 Extension Map E: O  x M x Obj* -> Prog must be defined for each method m not in the domain dom(R). For each m, and x: , the following conditions must be true for , the program to which E(x,m,a) maps : –Inputs to  is the sequence [x]||a. –The set of methods invoked in p is contained in the union of dom(R). –The diamond rule must hold.

39. D. WijesekeraSWE 699/IT 823: Precise Modeling39 The Diamond Rule Relate the abstracted values of x at the end of either calling m: –A(x  2 ) Calling the program  : –A(X  ) Need A(x  2 ) = A(X  )

40. D. WijesekeraSWE 699/IT 823: Precise Modeling40 Explanation of the Extension Map Purpose: –Running the extra method is similar to running the explanation program. Diamond diagram says: –Values returned by running the extra methods in the subtype is the same. Note: –The extension rule constrain only what the explanation program does to the method’s object – and not to other objects!

41. D. WijesekeraSWE 699/IT 823: Precise Modeling41 Explanation of the Extension Map Note: –The explanation program does not really run! Its sole purpose is to show what can happen to the object. –In reality, the values do not have to be equal, but observably indistinguishable! (through some bi- simulation relation). Now the history rule is restored by combining the method rules and the extension rule.

42. D. WijesekeraSWE 699/IT 823: Precise Modeling42 Extension Map Applied to the Bag/Stack Example E(s.swap_top(i)) = s.pop();s.push(i) Bag: Super type uses BBag(bag for B) Methods: put, get, card, equal Stack: Sub type uses BStack(stack S) Methods: push, pop, height, equal, swap_top

43. D. WijesekeraSWE 699/IT 823: Precise Modeling43 Informal Justification of the Extension Map Method What we need to show is the subtype requirement. That is the following: If |-- (x), x : S, S < T, y: T then |-- (y) What proof rules are allowed? –Invariants, –covariance of inputs, –contravariance of outputs and post conditions –Equality of pre-conditions –History rule

44. D. WijesekeraSWE 699/IT 823: Precise Modeling44 Informal Justification of the Extension Map Method Consider any property  of objects for which there is a proof of  x  for x: S. We will go through the proof tree of  x  and show that is can be transformed in to a proof tree for the proposition  y  for y: T. Where is the difficulty ? –Assumptions in the proof tree of  x  are at the leaves of the tree: Can each one be transformed in to an assumption valid for the subtype T ? (discuss induction here!). –Can application of proof rules be transformed into valid proof rules?

45. D. WijesekeraSWE 699/IT 823: Precise Modeling45 Informal Justification of the Extension Map Method: Contd. One of the proof rules used is the history rule, that reads as m .pre ^ m .post =>  (x pre /x , x post /x  )  Now suppose that the antecedent of this rule has been proved for the super type. How do we prove it for the sub type?

46. D. WijesekeraSWE 699/IT 823: Precise Modeling46 Informal Justification Contd. That is we need to show that any (history) property  satisfies the following: m .pre /\ m .post =>  [A(x  )/x ,A(x  )/x  ]. Assuming that the following is true for the super type t. m .pre /\ m .post =>  [A(x  )/x ,A(x  )/x  ].

47. D. WijesekeraSWE 699/IT 823: Precise Modeling47 Proof Continued m .pre /\ m .post => m .pre [A(x  )/x   /\ m .post [A(x  )x , A(x  )/x  ] Follows from the method rules (i.e. equality of the precondition and contravariance of the post condition) Because the formula is proved for the super type, we get m .pre [A(x  )/x  ] /\ m .post[A(x  )/x ,A(x  )/x  ] =>  [A(x  )/x ,A(x  )/x  ]

48. D. WijesekeraSWE 699/IT 823: Precise Modeling48 Type Hierarchies Concern: –Are Liskov/Wing sub-typing rules too strong? –That is, do they include or exclude many applications of subtypes ? We consider two common ways of constructing subtypes –Extension subtypes –Constrained subtypes

49. D. WijesekeraSWE 699/IT 823: Precise Modeling49 Extension Subtypes Two non-exclusive ways of having extension subtypes –Have more methods than the super type. Method mapping may not be one-to-one. –Have more “state” than the super type. Abstraction function is many-to-one. If a subtype object is used as a super type object (should be possible), then the super-type methods cannot distinguish finer details about subtype state.

50. D. WijesekeraSWE 699/IT 823: Precise Modeling50 Extension Subtypes Contd. Example 1: Sets of Integers. –Super type has insert, delete, select, size. –Subtype has union, intersection in addition. No extra state, only methods. Extension map method has to explain each additional method in terms of insert, delete and select methods. –Need to do similar work if we were to implement union and intersection using insert, delete and select.

51. D. WijesekeraSWE 699/IT 823: Precise Modeling51 Extension Subtypes Contd.-II If using constraints, must show that subtypes constraints imply super types constraints. What constraints can we impose? –Bound of the set is invariant. How do we state this ? –bound  = bound  for states  < .

52. D. WijesekeraSWE 699/IT 823: Precise Modeling52 Example II: “More State” in Subtype Immutable pairs –Methods: fetchFirst, fetchLast Immutable Triples –Extra methods fetchMiddle Semi-mutable triples –Extra methods fetchMiddle replaceMiddle

53. D. WijesekeraSWE 699/IT 823: Precise Modeling53 Extension Subtypes – Contd. Immutable types have mutable subtypes provided that mutations are invisible to the super type Subtype has more state than the super type. Hence, abstraction map is many-to-one. Notice: –Super type states are equivalence classes over subtype classes

54. D. WijesekeraSWE 699/IT 823: Precise Modeling54 Observerbility and Subtyping Equality methods: Call x.equal(y). pair_equal = proc (p: pair) returns (bool). ensures result = (p.first=q.first /\ p.second=q.second). triple_equal = proc (p: pair) returns (bool). ensures result = (p.first=q.first /\ p.second=q.second. /\ p.third=q.third). The difficulty arises when the equal method is called on subtype object.

55. D. WijesekeraSWE 699/IT 823: Precise Modeling55 Observability Cont. Any method call that expose the abstract state of a method can run into trouble. Example: Suppose pairs and triples are implemented as arrays, and the unparse method must give the components. –The unparse method for the super type must give only two components ie. X.unparse returns (x 1, x 2) in the supertype. X.unparse returns (x 1, x 2,x 3 ) in the subtype.

56. D. WijesekeraSWE 699/IT 823: Precise Modeling56 Constrained Subtypes Subtype more constrained than the super type. Abstraction mapping is usually in-to.

57. D. WijesekeraSWE 699/IT 823: Precise Modeling57 Constrained Subtypes One way to constrain bags is by constraining the bound. Other ways of constraining bags is to remove the non- determinism in get and put methods. By constraining these, we get. –Sequences, queues, stacks. What would be a constraint on bags: that the bound is fixed (note: not an invariant). –Hence a bag that changes its bound (variable bag) would not be a subtype of bag. Virtual Types: Only collects common features of subtypes. They don’t “exist”.

58. D. WijesekeraSWE 699/IT 823: Precise Modeling58 Comparing Subtype Definitions Constraints –Simple, all history properties that need preservation need to be explicitly stated –Method and specifications and constraints have to be consistent (sometime redundant) Example: put = proc(n :int) requires | b pre.elements | < b pre.bound modifies b ensures b pre.bound = b post.bound /\ Blah Blah Blah

59. D. WijesekeraSWE 699/IT 823: Precise Modeling59 Comparing Subtype Definitions Need to graduate common properties from method specifications to constraints. Thereby allow common properties of type families to be stated directly. In the explanation based approach, sometimes must put some extra methods to prevent history properties not holding for subtypes holding for super types.

60. D. WijesekeraSWE 699/IT 823: Precise Modeling60 Comparison Continued Change_bound =proc(n:int) requires n > |b pre.elems| modifies b ensures b post.elems=b pre.elems /\ b post.bound=n If the above method did not exist in varyingBag, then in the extension map based method, we can deduce that the bound does not change by using the history rule

61. D. WijesekeraSWE 699/IT 823: Precise Modeling61 Comparison Continued Disadvantage of the constraint based approach. –Because the history rule is absent, must specify all constraints carefully. –Loss of the history rule. –If used history rule would prove properties that do not hold for subtypes. Explanation based approach is more operational. –Useful if subtype only adds more methods.