1. Specifications Liskov Chapter 9 SWE 619 Last Updated Fall 2008

2. 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. 3 Why Specifications? What do specifications do? Who is the target audience? How are they constructed? What is their use? Do they evolve?

4. 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. 5 Use Implementers: understand system requirements, tasks to be performed Testers: Understand functional requirements Clients: understand how to use the software

6. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15 Classic over specification e.g. Consider a container with method: public Object getElement() Desire any one element from the container Spec: //E: returns 3 rd element in the container Obviously over-constrained.

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

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

26. 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. 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. 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!