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 gt 0
• // E returns x such that x gt y
• Specificand set (possible implementations)
• return y 1, return y k (k gt 0)
• return y 2, return y k (k gt 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 gt 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 dont 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!