specifications - Caltech

CS 3Introduction to Software Engineering8: Specifications(Chapter 9)

Announcement: “Midterm”• Midterm “project” has two parts.– First part (built into upcoming homework set):Implement a data abstraction I will specify.– Second part (next week’s homework set):Implement a program using that abstraction.2

Announcement• Welcome to second “half” of term.• Shift focus to programming “in the large”.– Specifications, testing, design, analysis.• Final project starts soon.– Begin forming groups now (2-4 persons).– Plan and complete any software development projectyou decide on.– Proposal due Monday, May 9.– No dropping the course after that.– Presentations in class on last day (Jun 4 or May 28).• What should rules for seniors be?3

Specifications(Chapter 9)

Specifications“logical firewalls that permit divide-and-conquer to succeed.”(Liskov, p. 216)• To divide coding labor between programmers, each must know:– Responsibilities of his/her module.– Capabilities of other modules (to help).• Specifications limit what each must know about others’ modules.I.e., don’t have to know anything except specification.• Also provide freedom for implementors.As long as specification is satisfied, anything goes.• Today: a little more formal look at how this works.5

“Meaning”• To talk seriously about specifications, needformal vocabulary.– When is one spec stronger/weaker than another?– Can a spec be too strong? too weak? when?– Is a spec clear?• What exactly must it convey?• What are potential sources of confusion?• In other words, we must first clarify thesemantics of specifications.– That is, given a specification, what does it “mean”?6

Where Specs Come From• Interpretation of specs as English sentencesdepends on context:Who’s doing the specifying?• Scenario I: Open-Source Library– Developer invents algorithm (or whatever).– Codes up as library, posts on web.– Provides Javadoc documentation alongside.• Explains what each public/protected member of each publicclass/interface is for.– Specs are advertisement: “This is what I do.”7

Where Specs Come From• Scenario II: Work for Hire– Customer needs software for certain purpose.– Hires developer to create it.– Instructs developer as to what classes/methods/procedures areneeded, what they must do.– Specs are requirements: “This is what I need.”• Scenario III: In-House Teamwork– Everyone working on same project.– Lengthy design process results in plan for implementation.– Meetings, negotiations to specify modules and assignprogrammers to implement.– Each spec is requirement to someone and advertisement toothers.8

Where Specs Come From• Scenario II: Work for Hire– Customer needs software for certain purpose.– Hires developer to create it.– Instructs developer as to what classes/methods/procedures areneeded, what they must do.– Specs are requirements: “This is what I need.”• Scenario III: In-House Teamwork– Everyone working on same project.– Lengthy design process results in plan for implementation.– Meetings, negotiations to specify modules and assignprogrammers to implement.– Each spec is requirement to someone and advertisement toothers.9

Where Specs Come From• Scenario IV: Maintenance– Complete system exists, but needs to be changed.– Specifications are descriptive: “This is how it works.”– Changes easiest if they can be localized.• The fewer modules must change, the better.• Changes to one module can affect others:Module no longer satisfies old spec ⇒write new spec ⇒ revisit all modules that use it.• Therefore, the fewer specifications must change, the better.– Specifications are guides: As long as they stay true,complexity of change is under control.10

Specificand Sets• For any specification (of a procedure) consider the set of allprocedures that satisfy it.– Almost always either empty (not useful) or infinite.• Example:/** REQUIRES: x >= 1* EFFECTS: Returns some y where 0 < y = 1, 0 < f(x)

Specificand Sets• For any specification (of a procedure) consider the set of allprocedures that satisfy it.– Almost always either empty (not useful) or infinite.• Example:/** REQUIRES: x >= 1* EFFECTS: Returns some y where 0 < y = 1, 0 < f(x)

Specificand Sets• For any specification (of a procedure) consider the set of allprocedures that satisfy it.– Almost always either empty (not useful) or infinite.• Example:/** REQUIRES: x >= 1* EFFECTS: Returns some y where 0 < y = 1, 0 < f(x)

Specificand Sets• For any specification (of a procedure) consider the set of allprocedures that satisfy it.– Almost always either empty (not useful) or infinite.• Example:/** REQUIRES: x >= 1* EFFECTS: Returns some y where 0 < y = 1, 0 < f(x)

Changing Specificands/** Returns some integer* y < x.*/int f(int x);int f(x) { return x; }int f(x) { return x-1; }int f(x) {if (x == 1) return 1;else return x-1; }int f(x) {/* calculate and returnthe greatest y s.t.y 2

Changing Specificands/** Returns some integer* y < x.*/int f(int x);int f(x) { return x; }int f(x) { return x-1; }int f(x) {if (x == 1) return 1;else return x-1; }int f(x) {/* calculate and returnthe greatest y s.t.y 2

Changing Specificands/** Returns some integer* y

Changing Specificands/** Returns some integer* y

Changing Specificands/** Returns some integer* y s.t. 0 < y

Changing Specificands/** Returns some integer* y s.t. 0 < y

Changing Specificands/** REQUIRES: x >= 1.* EFFECTS:* Returns some integer* y s.t. 0 < y

Changing Specificands/** REQUIRES: x >= 1.* EFFECTS:* Returns some integer* y s.t. 0 < y

Changing Specificands/** REQUIRES: x > 1.* EFFECTS:* Returns some integer* y s.t. 0 < y

Changing Specificands/** REQUIRES: x > 1.* EFFECTS:* Returns some integer* y s.t. 0 < y

Changing Specificands/** REQUIRES: x >= 1.* EFFECTS:* Returns some integer* y s.t. 0 < y 2

Changing Specificands/** REQUIRES: x >= 1.* EFFECTS:* Returns some integer* y s.t. 0 < y 2

Stronger/Weaker• Let S and T be specifications.• Definition: S is stronger than T if(specificand set of S) ⊆ (specificand set of T)– Intuition: Anything that satisfies S satisfies T.– Maybe not conversely.– T is “easier” to satisfy.• Stronger specifications give clients moreinformation.• Weaker specifications give implementors morefreedom.27

Restrictiveness• Client must work no matter what member of specificand set is provided.• Therefore, specifications should be strong enough.• Must be able to answer all of clients’ questions about module’s behavior.– Can it handle… ?E.g., Can I insert null into this Set?– What will happen if… ?– What does this outcome mean?E.g., I call myMap.get(x) and it returns null. Does that mean x is not in myMap?Or: I try to create a FileReader and get an exception. Is it worth trying again?28

Restrictiveness• Client must work no matter what member of specificand set is provided.• Therefore, specifications should be strong enough.• If spec doesn’t answer all questions, client can’t depend on behavior.Might be anything any member of specificand set might do.Might change in future releases; might be different every time!– Had better not insert null into set.– Can’t conclude anything from myMap.get returning null.– Don’t know how to handle exception from FileReader.29

Generality• The implementor must provide a member of the specificand set.• Specifications should not be too strong.• Some specs are unsatisfiable.– May be some input for which no allowable outcome exists.E.g., “For any x, 0 < f(x) < x.” What if x < 0?– Set of allowable outcomes may depend on unavailable information.• Specification may describe an uncomputable function.• Some specifications hard to satisfy efficiently.• Usually good to say what something does without saying how.– Implementor free to choose an approach.– Maintainers free to change the approach.30

Specifications and Correctness• A specification is the thing wrt which a module isjudged correct or not.• An implementation is correct iff it’s a member ofthe specificand set of the spec.• If procedure has requirements R and effects E,then specificand set is:{M | For any x s.t. R(x), M(x) has effect E(x)}• To prove an implementation correct, show it hasthat property.31

Correctness of Client Code• Most modules are clients of at least one other.• Is this correct?/* Returns true if n is even, false if n is odd. */boolean isEven(int n) { return g(n-1); }Depends on what g “does,” of course.• Formally, correctness of isEven depends (only) on:– Specification of isEven.– Code of isEven.– Specification of g.• If g’s spec says something like: /* Returns true if n odd, else false */then isEven is correct.– Don’t need to look at g’s code:If g’s code doesn’t meet its spec, problem is g’s fault, not isEven’s.• If g’s spec doesn’t imply isEven correct, ∃ poss. impl. of g s.t. isEven fails.Therefore, isEven is incorrect.– What g’s code actually does is irrelevant, because it may change.32

Correctness of Client Code• Most modules are clients of at least one other.• Is this correct?/* Returns true if n is even, false if n is odd. */boolean isEven(int n) { return g(n-1); }Depends on what g “does,” of course.• Formally, correctness of isEven depends (only) on:– Specification of isEven.– Code of isEven.– Specification of g.• If g’s spec says something like: /* Returns true if n odd, else false */then isEven is correct.– Don’t need to look at g’s code:If g’s code doesn’t meet its spec, problem is g’s fault, not isEven’s.• If g’s spec doesn’t imply isEven correct, ∃ poss. impl. of g s.t. isEven fails.Therefore, isEven is incorrect.– What g’s code actually does is irrelevant, because it may change.33

Correctness of Client Code• Most modules are clients of at least one other.• Is this correct?/* Returns true if n is even, false if n is odd. */boolean isEven(int n) { return g(n-1); }Depends on what g “does,” of course.• Formally, correctness of isEven depends (only) on:– Specification of isEven.– Code of isEven.– Specification of g.• If g’s spec says something like: /* Returns true if n odd, else false */then isEven is correct.– Don’t need to look at g’s code:If g’s code doesn’t meet its spec, problem is g’s fault, not isEven’s.• If g’s spec doesn’t imply isEven correct, ∃ poss. impl. of g s.t. isEven fails.Therefore, isEven is incorrect.– What g’s code actually does is irrelevant, because it may change.34

Correctness of Client Code• Judge correctness of each moduleindependently, using specifications.Module is correct if it meets its spec assuming othermodules meet theirs.(No other assumptions about other modules allowed.)• If M calls P and P’s specificand set is S, thenM is correct iff:For any ∀N∈S, if P is implemented by N and R(x), thenM(x) does E(x).35

Integration• True or false?If each module in a system implements its abstraction correctly by using otherscorrectly, then the whole system will be correct.• False! Counterexample:/* Returns true if n is even, false if n is odd. */public static boolean isEven(int n) {return isOdd(n-1);}/* Returns true if n is odd, false if n is even. */public static boolean isOdd(int n) {return isEven(n+1);}• Example of integration error.– For each of these, true that it works if the other does.– But taken together, they don’t make a working system.36

Integration• True or false?If each module in a system implements its abstraction correctly by using otherscorrectly, then the whole system will be correct.• False! Counterexample:/* Returns true if n is even, false if n is odd. */public static boolean isEven(int n) {return isOdd(n-1);}/* Returns true if n is odd, false if n is even. */public static boolean isOdd(int n) {return isEven(n+1);}• Example of integration error.– For each of these, true that it works if the other does.– But taken together, they don’t make a working system.37

Integration Errors• What really happened there?38