Specifications Liskov Chapter 9

1. SpecificationsLiskov Chapter 9 SWE 619 Last Updated Fall 2008

2. Overview/Agenda • Review why we use specifications as a software construction tool? • Restating the reasons from chapter 1 • How to write good specs (for desired behavior)? • Advice from Liskov • Some formal ways to specify behavior • Z, OCL (SWE 623)

3. Why Specifications? • What do specifications do? • Who is the target audience? • How are they constructed? • What is their use? • Do they evolve?

4. Construction • Intended for: designers, implementers, testers, maintenance people, clients • In short: intended for people [users] • How formal can specifications be? • Must clearly state what the must the software do • Can informal specs be clear? • Must be understood by users of the specification.

5. Use • Implementers: understand system requirements, tasks to be performed • Testers: Understand functional requirements • Clients: understand how to use the software

6. Understanding abstractions • What must be understood? • Behavior of some abstraction • How to specify behavior? • abstract state, changes to abstract state • abstract descriptions • Leads to multiple implementations that satisfy an abstraction • Satisfy? Implementations follow contract i.e., pre and post conditions

7. Meaning of an abstraction • The set of implementations that satisfy an abstraction is the specificand set. • Specificand set is the meaning of an abstraction • Example public int 3DigitNumber() //E: return an integer greater than 99 // and less than 1000 What is the meaning of this abstraction?

8. Liskov example static int p (int y) // R: y > 0 // E: returns x such that x > y Specificand set: (possible implementations) {return y + 1;}, { return y + k ;} (k > 0) {return y * 2;}, {return y * k ; } (k > 1) {return 4y – 2;} What about {return 4y – 3;} ?

9. Liskov example (contd.) static int p (int y) // R: true // E: returns x such that x > y • What does strengthening/weakening of pre/post conditions do to the specificand set? • weakening pre  smaller specificand set • New set is a subset of old set • strengthening post  smaller specificand set • Again, new set is a subset of old set

10. Specs for desired behavior • Note that “desired” differs from “correct” • Specs determine specificand set • Do all members of specificand set exhibit desired behavior? • Throw out implementations that do not • Are there missing members of specificant set? • Add implementations that are missing

11. Sufficiently restrictive specs • Rephrase specs  prune specificand set • Example: Iterator for a (mutable) bag bag = [Book, Book, Pen, Pencil] //E: returns every element in bag • Type of implementations for this spec? • Duplicates? • Elements not in bag? • What about order? • What about mutability?

12. Refining specs for desired behavior • If do not desire duplicates (i.e. Pen once, Book once): // E: returns all unique elements in bag only once • If order matters: // E: returns elements in order they were put in the bag (FIFO) • If mutability matters: // R: No change to bag while iterator in use // E: returns every element in bag

13. Refining specs for desired behavior (contd.) • If mutability matters: //E: returns every element in bag, throws // CME if iterator modified while in use • If only elements in bag desired: //E: returns only the elements in bag

14. Sufficiently general specs • Apparent contradiction with the earlier goal of pruning specs! • What if the specs are over specified? • i.e., some valid and desired implementations are not the members of the specificand set • Over specifications are bad in the sense that some desired implementations are lost

15. Classic over specification e.g. Consider a container with method: public Object getElement() • Desire any one element from the container • Spec: //E: returns 3rd element in the container • Obviously over-constrained.

16. Generality of specs • Specifications come in 2 flavors • Operational: A recipe or algorithm • Definitional: Some property or constraints that inputs/outputs satisfy • Prefer definitional specs • More freedom to implementer regarding choice of algorithm • But not a natural choice for most students

17. Clarity • Every user of the spec should have the same interpretation of the spec! • Possible if we allow formal specs • Not easy to understand formal specs! • Clear, unambiguous specifications are hard to get • Expect to make mistakes! • What to do? • Allow redundancy in specs

18. Redundancy • Specs are not concise  • Easier to understand  • 2 flavors • i.e. redundant definition • e.g. provide an example • Reduces chances of missing an important point

19. Liskov example static boolean subset (Set s1, Set s2) throws NPE // E: if s1 or s2 is null, throws NPE else returns true // if s1 is a subset of s2, else returns false • Makes sense to every reader • What could be wrong here?

20. Example contd. • What if s1 equals s2? • Design decision about what to return for improper subset. • Rephrasing specs as: //E: … NPE else, returns true if every element of s1 is an element of s2, else false • Is this a better spec?

21. Example continued • Second spec allows improper subset • Eliminates ambiguity. • But why not use accepted terms? • Liskov: don’t replace, include both! //E: …NPE, returns true if s1 is a subset of s2, i.e., returns true if every element of s1 is an element of s2, else false

22. Alternate spec • Still better way to make sense to a wide variety of audience is to add more redundancy (without being repetitive) // E: … NPE, returns true if s1 is a subset of s2, i.e., returns true if every element of s1 is an element of s2, else false, e.g., subset({7}, {3, 7}) returns true, subset({3}, {7}) returns false, subset ({7}, {7}) returns true

23. How much effort into specs? • Avoid verbosity, repetitiveness but not compromise on clarity • Examples are powerful as specifiers, good idea to include them • Only a handful of examples can help you think about restrictive and general specs

24. Test Driven Development as a Specification Exercise Basic idea: Define tests first Then develop code to satisfy tests Lots of process stuff as well Connection to current lecture: Specification examples are tests Specification examples greatly help specifier understand abstraction Rule of thumb: Most development artifacts are more useful if they are executable 24

25. Formal specifications • Specifications/ Analysis in Z (Zed) • Occasionally taught in SWE 623 • Basis for OCL in UML

26. Specification in Z • Scenario: We maintain a membership list and an associated phone database. [Person, Phone] |----PhoneDB----------------------------------- |members: P Person (‘set of’ person) |phones : Person  Phone (relation) |------------------------------------------------------- |dom phones ⊆ members (invariant) |---------------------------------------------------

27. Z Operation: Assign a Phone • Scenario: Someone would like a phone. (Note: Missing precondition) |----Assign----------------------------------- | p? : Person; n? : Phone |  PhoneDB |------------------------------------------------------- | phone’ = phone  { p?  n? } | members’ = members |---------------------------------------------------

28. Example • members  {jim, sue} • phones {(jim, 1231), (sue, 3956)} • Assign(alice, 1231) • Cool Z property: Can calculate minimal preconditions!! • Simple analysis: leave out preconditions and find minimum constraint to maintain invariants!