1 / 24

Topics in OO, Design Patterns, Reasoning About Program Behavior ... (part 2)

Topics in OO, Design Patterns, Reasoning About Program Behavior ... (part 2). Neelam Soundarajan Computer Sc. & Eng. e-mail: neelam@cse. Specifying A Class (methods). For each method: Specify pre-condition, post-condition;

kaiyo
Download Presentation

Topics in OO, Design Patterns, Reasoning About Program Behavior ... (part 2)

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. Topics in OO, Design Patterns, Reasoning About Program Behavior ...(part 2) Neelam Soundarajan Computer Sc. & Eng. e-mail: neelam@cse

  2. Specifying A Class (methods) For each method: Specify pre-condition, post-condition; Pre-condition: Assertion on parameters, values of member variables; Post-condition: parameters, results, values of memebers at start and end. E.g.: pre-deposit(x) ≡ true; ?? post-deposit(x) ≡ [(x = #x) && (bal = #bal + x) pre-withdraw(x) ≡ true; ?? post-withdraw(x)≡ [(x = #x) && (bal = #bal - x)

  3. Specifying A Class (class invariant) Invariants: Often useful to specify a class invariant; Example: (bal > 0) Note: Invariant need not hold during method execution. But: What if one method calls another?

  4. Concrete vs. Abstract Specs Concrete specs: In terms of member variables of class. Disadv: Violates spirit of abstraction; why should client think in terms of internal details of class? Adv: Easier for the class implementer to work with. Abstract specs: In terms of an “abstract” model of class. (See Jones book for detailed discussion.)

  5. Abstract Specs Model-based: Define a conceptual (math) model corresponding to the class; map class operations into corresponding operations on model (rather: specify pre- and post-conditions in terms of model); Property-based: Specify properties of the various operations in terms of axioms. Trace-based: In terms of traces of calls to methods of the calls and what those calls will return.

  6. Model-based Specs Goal: Make model as “abstract” as possible. The designer will choose a representation based on implementation considerations. Proof of correctness: Provide a retrieve function that maps back from the representation to the model/abstraction. Adequacy: At least one rep element for any abstract value (usually shown by construction).

  7. Abs Abs Fa rep retr Rep Rep Fr Model-based Specs (contd.) For operations: Fa is an abstract operation, Fr the corr. op. in the impl.: retr(Fr(rep(a))) = Fa(a) [For all a in Abs] I.e.: Fr’s behavior is same as Fa’s. Better: retr(Fr(r)) = Fa(retr(r)) [For all r in Rep]

  8. Model-based Specs (contd.) Domain rule: pre-A(retr(r)) → pre-R(r) [for all r in Rep] I.e., pre-cond. of the operation in the rep is not too “narrow” Result rule: [pre-A(retr(r1)) && post-R(r1, r2) ] → post-A(retr(r1), retr(r2)) I.e., Any pair of states in the post-R relation, when viewed under the retr() function, must satisfy the post-A relation.

  9. Model-based Specs (contd.) Advantages: • Provides concrete model; easy to understand. Disadvantages: • May bias implementation (i.e., too concrete). Complications: • Operations are partial and non-deterministic; • Retrieve functions are many-to-one (so their inverses are not functions).

  10. Model-based Specs (contd.) Example: • A “biased” Queue which keeps the old elements • A “rep” function from Queue to Queueb cannot be constructed. • Def: A model-oriented spec is based on an underlying set of states. It is biased if there exist different elements of the set that cannot be distinguished by any sequence of operations. • Problems with abstraction/retrieve functions; see paper by Bruce Weide and others and the references therein.

  11. Property-based Specs Idea: Specify properties of the various operations in terms of axioms. Detail: Spec consists of a signature and a set of equations.

  12. Property-based Specs (contd.) Spec for a Stack of integers: init: → Stack push: N x Stack → Stack top: Stack → (N U Error) remove: Stack → Stack isEmpty: Stack → Bool top(init()) = Error top(push(i,s)) = i remove(init()) = init() remove(push(i,s)) = s isEmpty(init()) = true isEmpty(init()) = false

  13. Property-based Specs (contd.) Advantages: Abstract: no model bias. Disadvantages: May be too abstract? Equations may not be obvious - may not even have a model! Or, conversely equations may not exist. E.g.: Veloso’s traversable stack: in addition to normal operations, stack can be read from a point indicated by cursor; cursor can be reset to top of stack or moved down one element; normal pop and push only with cursor at top. Easy to specify with model; impossible with prop-based spec?

  14. Trace-based Specs Idea: Specify in terms of the structure of traces of calls to methods of the class and the values returned. Detail: Specify the legal traces; (behavior of the module in response to illegal traces is undefined). Specify which traces are equivalent to each other. Specify the output of a legal trace that ends in a function call (i.e., a method that returns a value).

  15. Trace-based Specs (contd.) Definition: Legal traces: Which series of procedure calls are legal (i.e., not regarded as error)? These are indicated by semantic assertions of the form L(trace). Values: What is the output of a legal trace that ends in a function call? These are denoted by assertions of the form V(trace) = value

  16. Trace-based Specs (e.g.) NAME stack SYNTAX push: int; pop: ; top: → int; SEMANTICS (forall T, i) (L(T) → L(T.push(i)) (forall T, i) (L(T.top) ↔ L(T.pop)) [not: (L(T.top) → L(T.pop)) (forall T, i) (T ≡ T.push(i).pop) (forall T, i) (L(T.top) → T ≡ T.top) (forall T, i) (L(T) → V(T.push(i).top = i)

  17. Trace-based Specs (contd.) Problem: Trace-based specs can become complex quickly. Solution: Hoffman and Snodgrass introduce a number of heuristics to help with this. E.g.: Define a normal-form for traces. Then most of the spec need only worry about normal-form traces. For STACK, normal-form: sequence of push’s.

  18. Trace-based Specs (contd.) Advantages: No bias; everything specified in terms of observable behavior. [This is, in fact, a general principle that one could adopt in specifying behaviors.] Disadvantages: Specs can get too complex. (The idea of normal-forms for traces as well as using suitably defined functions/macros seem to help with this.)

  19. Behavioral Subtyping (Liskov, Wing: Behavioral notion of subtyping, 1994.) Basic Idea: Substitutability principle is good. Question: How to formalize it so it works in the presence of aliasing and in the presence of multiple users? Part of the answer: The subtype operations’ specs must be consistent with those of the corresponding supertype operation.

  20. Behavioral Subtyping (contd.) Example: A given object may be treated as a bounded bag by one user (using operations, put, get); and used as a bounded stack by another user (operations: push, pop, swapTop). Requirement: The first user should be able to reason about the object using invariant and history properties of bounded bag.

  21. Behavioral Subtyping (contd.) [Note: Turns out there are some technical problems that arise in some subtle situtations; I won’t go into them; read Liskov and Wing for the details.] Constraint-based approach: Have a constraint clause in base type that expresses history properties that must be preserved by subtype. [e.g.: bound of the bag is not changed.] Explanation-based approach: For each extra method in subtype, explain how to implement it using methods already defined in supertype. [e.g.: swapTop = pop; push; ]

  22. Behavioral Subtyping (contd.) For σ to be behavioral subtype of τ: Iσ and Iτ are the invariants; A is an abstraction function (from subtype to supertype). mt.pre and mt.post are pre/post- conditions of m() in τ; similarly ms.pre and ms.post in σ. Constraint-based approach: 1. Invariant-rule: Iσ(s) → Iτ(A(s)) 2. mt.pre[A(xpre)/xpre] → ms.pre 3. ms.post → mt.post[A(xpre)/xpre, A(xpost)/xpost] 4. Constraint rule: For any computation c, and states s, s’ in c, Cσ → Cτ[A(xs)/xs, A(xs’)/xs’ ]

  23. Behavioral Subtyping (contd.) For σ to be behavioral subtype of τ: Explanation-based approach: 1. Invariant-rule: As before 2. Pre-conditions: As before (not quite?) [For somewhat strange example, see L-W paper.] 3. Post-conditions: As before. 4. Extension rule: Formalizes the requirement that each additional method of σ can be written as a sequence of calls to methods of τ. The L-W paper considers all kinds of involved situations.

  24. Behavioral Subtyping How do you define behavioral subtyping in the property-based approach? Ans: Not sure! I suspect it will be kind of difficult because you would have to work with the axioms that make up the spec. How do you define behavioral subtyping in the trace-based approach? Ans: Not sure! But I think this is actually doable. If you are looking to work on an interesting (and, I think, solvable) problem, this may be one. Talk to me.

More Related