d. wijesekeraswe 699/it 823: precise modeling1 typing a behavioral notion of subtyping by barbara...

D. Wijesekera SWE 699/IT 823: Precise Modeling 1

Typing

A Behavioral Notion of SubtypingBy Barbara Liskov and Jeannette M. Wing

inACM Trans. Of Prog. Languages and Systems

Vol 16, No 6, November 1994, Pages 1811-1843


Hierarchy and Inheritance1. 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


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


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


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?


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


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?


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


Back to Liskov+Wing Properties not Considered

• Producer-Consumer:– Only one producer

only one consumer

• Feature Models– Disjoint features

Class: Thread ID: integer Buffer: *char getLockToBuff() giveLockOfBuf()

Producer FillBuffer()

Consumer EmptyBuf()

Feature

Nessasary

Exclusive


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?


Models• Models uses Environments, Stores, States and

computation sequences.Env: Var -> Obj.Store: Obj -> Val.State: Env X Store.

• Computation sequence: Tr1 1 …n-1 Trn n where.Each i is a state, and.Each Tri is a partial function on states.


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?


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 = typeuses Bbag(bag for B)for all b:bag <- parametersput=proc(i:int)

requires |bpre.elements| <bpre.boundmodifies bensures bpost.elms=bpre.elmsU{i}^

bpost.bound=bpre.bound


Specifications

• Modifies: – Means no others are modified

• Can have signals specified:get’=proc() returns(int) signals(empty)

modifies bensures if bpre.elms ={} then signal empty

else bpost.elms=b.pre.elms-{result}^ result bpre.elms ^ bpost.bound-bpre.bound


Specifications

• Post condition= modifies ^ ensures• Specifying Creators

bag_create= proc(n:int) returns(bag)requires n>0ensures new(result) ^ resultpost=({},100)

bag_create_single=proc(i:int) returns(bag)ensures new(result) ^ resultpost=({i},100)


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.


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.


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 (resultpost/x).

This says that the invariant is true in any state at which the creator is called.


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.


Example: Type BStackstack=typeuses BStack(stack for S)Invariant length(s.items) < spre.limitpush=proc(i:int)

requires spre.items =/= []modifies sensures spost.items=spre.items || [i] ^ spost.limit=spre.limit

Notation: || is concatenation and [] is the empty sequence


Bstack ContinuedSubtype 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:Seqmk_elems([])={}mk_elems(sq||[i])=mk_elems(sq)U{i}

Abstraction Function : A() maps elements of subtype to elements of the super type.


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))


First Definition: Continuation-12. Subtype methods preserve super type

method’s behavior ( subtype of ).

If mof 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 mis i, and that of mis i, then i > i for all i. (contravariance).

B. Either both m and mmust return results or neither does. If there is a result of mand m are and

respectively, then covarianceC. Exceptions of m are contained in those of m


Covariance and Contravariance

Inputs

Inputs

Outputs

Outputs

Super class method

Sub class method


First Definition: Continuation-2

2.1 Methods Rule.Pre-Conditions:m.pre[A(xpre)/ xpre]=>m.pre

That means, any precondition holding for the super type must hold for the subtype.

Post-Conditions:m.post => m.post[A(xpre)/ xpre, A(xpost)/ xpost].

That means, any post condition holding for the sub type must hold for the super type.


First Definition: Continuation-3

3. Subtype constraints ensure super type constraintsConstraint Rule: For all computations C and all states and such

that precedes in C,

Cxx=> C[A(x)/ x, A(x)/x]


Applying the Subtype Definition• Back to Stack < Bag Example.=(Ostack,S,{push,pop,swap_top,height,equal}).=(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.


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.


Application: Stack < Bag Example• Renaming function:

R(push) = put R(pop) = getR(height) = cardR(equal)=equal– Unmapped “additional” method in the subtype is

swap_top


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.


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.


Informal Justification of the Definition

• How does this definition guarantee that the subtype’s behavior is similar to the super type?

Super type Super type

Sub type Sub type

Pre-cond rule allows substitution

Post-cond rule guarantees strength

• Hence can call a subtype method instead of a super-type method


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.


Review: Covariance and Contravariance

Input types Preconditions

Inputs types Preconditions

Output types Postconditions Invariants

Output types Postcondirions Invariants

Super class method

Sub class method


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 => (xpre/x, xpost/x).(x,x).


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.


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(xpre)/xpre] =m.pre– Post-condition rule stays the same


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.


The Diamond Rule• Relate the abstracted

values of x at the end of either calling m:– A(x2)

• Calling the program :– A(X)

• NeedA(x2) = A(X)

X : S

X2 : S X : S

Y : S

A A

E(x.m(a))x.m(a)


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!


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.


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


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


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?


Informal Justification of the Extension Map Method: Contd.

• One of the proof rules used is the history rule, that reads asm.pre ^ m.post => (xpre/x, xpost/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?


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].


Proof Continuedm.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 getm.pre [A(x)/x] /\ m.post[A(x)/x,A(x)/x]

=> [A(x)/x,A(x)/x]


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


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.


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.


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 = boundfor states < .


Example II: “More State” in Subtype• Immutable pairs

– Methods:• fetchFirst, fetchLast

• Immutable Triples– Extra methods

• fetchMiddle

• Semi-mutable triples– Extra methods

• fetchMiddle• replaceMiddle

Immutable pairs

immutable triples semi-mutable triples


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


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.


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 (x1, x2) in the supertype.• X.unparse returns (x1, x2,x3) in the subtype.


Constrained Subtypes

• Subtype more constrained than the super type.• Abstraction mapping is usually in-to.

bag

Large bag Bound=232

mediumBag 101<bound<232

SmallBag Bound<101

bag_150 bound=150


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”.


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 | bpre.elements | < bpre.boundmodifies bensures bpre.bound = bpost.bound /\ Blah Blah Blah


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.


Comparison Continued

Change_bound =proc(n:int)requires n > |bpre.elems|modifies bensures bpost.elems=bpre.elems

/\ bpost.bound=n

varyingBag

dynamicBag bag

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


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.

d. wijesekeraswe 699/it 823: precise modeling1 typing a behavioral notion of subtyping by barbara...

Documents