1 / 61

Typing

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. Hierarchy and Inheritance. Type A is a subtype of B What does this mean?

gala
Télécharger la présentation

Typing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 SWE 699/IT 823: Precise Modeling

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

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

  4. 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 SWE 699/IT 823: Precise Modeling

  5. 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? SWE 699/IT 823: Precise Modeling

  6. 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 SWE 699/IT 823: Precise Modeling

  7. 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? SWE 699/IT 823: Precise Modeling

  8. 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 SWE 699/IT 823: Precise Modeling

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

  10. 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? SWE 699/IT 823: Precise Modeling

  11. Models • Models uses Environments, Stores, States and computation sequences. Env: Var -> Obj. Store: Obj -> Val. State: Env X Store. • Computation sequence: r1 Tr1r1 …rn-1 Trnrn where. Each ri is a state, and. Each Tri is a partial function on states. SWE 699/IT 823: Precise Modeling

  12. 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? SWE 699/IT 823: Precise Modeling

  13. 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 |bpre.elements| <bpre.bound modifies b ensures bpost.elms=bpre.elmsU{i}^ bpost.bound=bpre.bound Specifying Types SWE 699/IT 823: Precise Modeling

  14. Specifications • Modifies: • Means no others are modified • Can have signals specified: get’=proc() returns(int) signals(empty) modifies b ensures if bpre.elms ={} then signal empty else bpost.elms=b.pre.elms-{result}^ result e bpre.elms ^ bpost.bound-bpre.bound SWE 699/IT 823: Precise Modeling

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

  16. 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. SWE 699/IT 823: Precise Modeling

  17. Validity of Invariants • For the Bag example, we need to show that. number of elements < bound of the bag. Invariant | br.elmts| < br.bound. • Technically we need to ensure that. x:tt.x e dom(r) => f(xr). This says that the invariant is true in any state of any computation sequence. SWE 699/IT 823: Precise Modeling

  18. 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 t. x:tt.x I(resultpost/xr). This says that the invariant is true in any state at which the creator is called. SWE 699/IT 823: Precise Modeling

  19. 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. SWE 699/IT 823: Precise Modeling

  20. Example: Type BStack stack=type uses BStack(stack for S) Invariant length(sr.items) < spre.limit push=proc(i:int) requires spre.items =/= [] modifies s ensures spost.items=spre.items || [i] ^ spost.limit=spre.limit Notation: || is concatenation and [] is the empty sequence SWE 699/IT 823: Precise Modeling

  21. Bstack Continued Subtype of bag [push for put pop for get height for card] st:S A(st)=<mk_elems(st.items),st.limit> 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. SWE 699/IT 823: Precise Modeling

  22. First Definition: Constraint Rules • <: s=(Os,S,M) is a subtype of t =(Or,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 Is(s) => Ir(A(s)) SWE 699/IT 823: Precise Modeling

  23. First Definition: Continuation-1 2. Subtype methods preserve super type method’s behavior ( s subtype of t ). If ms of s is renamed to mt of t then the following must hold: (2.1 Signature Rule). • ms and mt must have the same # of arguments. If the list of argument types of ms is ai, and that of mt is bi, then ai > bi for all i. (contravariance). B. Either both ms and mt must return results or neither does. If there is a result of ms and mt are aandb respectively, then b > a. (covariance). C. Exceptions of ms are contained in those of mt. SWE 699/IT 823: Precise Modeling

  24. Covariance and Contravariance SWE 699/IT 823: Precise Modeling

  25. First Definition: Continuation-2 2.1 Methods Rule. Pre-Conditions: mt.pre[A(xpre)/ xpre]=>ms.pre That means, any precondition holding for the super type must hold for the subtype. Post-Conditions: ms.post => mt.post[A(xpre)/ xpre, A(xpost)/ xpost]. That means, any post condition holding for the sub type must hold for the super type. SWE 699/IT 823: Precise Modeling

  26. First Definition: Continuation-3 3. Subtype constraints ensure super type constraints Constraint Rule: For all computations C and all states r and f such that r precedes f in C, Cs[xr, xf]=> Ct[A(xr)/ xr, A(xf)/xf] SWE 699/IT 823: Precise Modeling

  27. Applying the Subtype Definition • Back to Stack < Bag Example. • s=(Ostack,S,{push,pop,swap_top,height,equal}). • r=(Obag,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. SWE 699/IT 823: Precise Modeling

  28. 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. SWE 699/IT 823: Precise Modeling

  29. 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 SWE 699/IT 823: Precise Modeling

  30. 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(Spre).elms| < A(Spre).bound Implies. Length(Spre.items) < Spre.limit. • Why is this true? • We will argue this informally. SWE 699/IT 823: Precise Modeling

  31. Application: Stack < Bag Example • To show that |A(Spre).elms| < A(Spre).bound Implies Length(Spre.items) < Spre.limit. • Why is this true? • Length of the sequence Spre = size of the multiset A(Spre).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 Spre.limit = A(Spre).bound. • put’s precondition implies |A(Spre).elms| < A(Spre).bound. • Now substitute equals to equals and get the result. SWE 699/IT 823: Precise Modeling

  32. 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 SWE 699/IT 823: Precise Modeling

  33. 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. SWE 699/IT 823: Precise Modeling

  34. Review: Covariance and Contravariance SWE 699/IT 823: Precise Modeling

  35. 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: mt.pre ^ mt.post => f(xpre/xr, xpost/xp). f (xr,xp). SWE 699/IT 823: Precise Modeling

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

  37. Subtypes using Extension Maps • Invariance Rule: (that abstraction respects invariants) – same as constraint based approach \/s: S It(s) => Is(s) • Signature Rules: • Contravariance of arguments (stays the same) • Covariance of results (stays the same) • Method Rules: • Precondition rules strengthened to equality mr.pre[A(xpre)/xpre] =ms.pre • Post-condition rule stays the same SWE 699/IT 823: Precise Modeling

  38. Extension Map • E: Osx M x Obj* -> Prog must be defined for each method m not in the domain dom(R). • For each m, and x:s, the following conditions must be true for p, the program to which E(x,m,a) maps : • Inputs to p 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. SWE 699/IT 823: Precise Modeling

  39. The Diamond Rule • Relate the abstracted values of x at the end of either calling m: • A(xr2) • Calling the program p: • A(Xy) • Need A(xr2) = A(Xy) SWE 699/IT 823: Precise Modeling

  40. Explanation of the Extension Map • Purpose: • Running the extra method is similar to running the explanation program. • Diamond diagram says: • Values returnedby 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! SWE 699/IT 823: Precise Modeling

  41. 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. SWE 699/IT 823: Precise Modeling

  42. Extension Map Applied to the Bag/Stack Example • 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 E(s.swap_top(i)) = s.pop();s.push(i) SWE 699/IT 823: Precise Modeling

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

  44. Informal Justification of the Extension Map Method • Consider any property l of objects for which there is a proof of l(x) for x: S. We will go through the proof tree of l(x) and show that is can be transformed in to a proof tree for the proposition l(y) for y: T. • Where is the difficulty ? • Assumptions in the proof tree of l(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? SWE 699/IT 823: Precise Modeling

  45. Informal Justification of the Extension Map Method: Contd. • One of the proof rules used is the history rule, that reads as mt.pre ^ mt.post => f(xpre/xr, xpost/xp) f • Now suppose that the antecedent of this rule has been proved for the super type. How do we prove it for the sub type? SWE 699/IT 823: Precise Modeling

  46. Informal Justification Contd. • That is we need to show that any (history) property f satisfies the following: ms.pre /\ ms.post => f[A(xr)/xr,A(xy)/xy]. • Assuming that the following is true for the super type t. mt.pre /\ mt.post => f[A(xr)/xr,A(xy)/xy]. SWE 699/IT 823: Precise Modeling

  47. Proof Continued ms.pre /\ ms.post => mt.pre [A(xr)/xr] /\ mt.post [A(xr)xr, A(xy)/xy] 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 mt.pre [A(xr)/xr] /\ mt.post[A(xr)/xr,A(xy)/xy] => f[A(xr)/xr,A(xy)/xy] SWE 699/IT 823: Precise Modeling

  48. 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 SWE 699/IT 823: Precise Modeling

  49. 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. SWE 699/IT 823: Precise Modeling

  50. 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. SWE 699/IT 823: Precise Modeling

More Related