6894

1
6894 workshop in software designlecture 8
october 28, 1998 declarative specs
2
contents

• why specify?
• basic notions
• elements of declarative spec
• abstract types
• procedures
• satisfaction
• expression languages
• pragmatics
• advanced notions

3
why specify?

• by specification, i mean
• description of behaviour of system components
• contrast to partial, system-wide models
• specs can play many roles
• before implementation
• help allocate work
• make division of responsibility clear
• during implementation
• as comments on helper components
• make review of code and debugging easier
• after implementation
• to document existing system
• for opening up interface
• for code review (generally more effective than
  testing)
• surprises
• often get nasty (but useful) surprises when
  writing specs
• eg, intentions are unclear, behaviour is not
  realizable, behaviour is not desirable

4
basic notions

• spec as contract
• between implementor and client of component
• decouple development activities, reduce
  communication burden
• spec has two parts
• obligations on client
• promises to client
• what not how
• spec describes observable behaviour alone
• client cannot distinguish different
  implementations
• avoid operational specs do this, then that
• weak is good
• weak means strong obligations, weak promises
• gives more implementation freedom, so better
  performance
• Java interfaces
• are primitive kind of machine-processable spec
• decoupling provided is the essence of several GOF
  design patterns

5
abstract types

• basic idea
• encapsulate procedures and data
• make clients representation-independent
• spec should also be rep-independent
• operations
• constructors make new objects of the type
• mutators change values of objects of the type
• observers extract values of other types
• abstract values
• figure out what functionality is provided
  abstractly
• ask what observers can tell after sequences of
  ops
• cant tell order of insertion? unordered
• cant tell number of insertions? set-like
• get last element inserted? stack-like
• get first element inserted? queue-like

6
example of ADT spec

• class FileCabinet
• model
• map Name -gt File
• found set File
• FileCabinet ()
• post result.map result.found
  
• void insert (File f, Name n)
• pre n not in dom this.map
• mod this
• post this.map this.map (n, f)
  this.found
• File find (Pattern name) throws NotFound
• mod this
• post ((no n in dom map n matches
  name) throws NotFound found )
• or ((exists n n matches name
  result map.n result not in found)
  found found result)

7
relating abstract rep values

• basic idea
• to reason about correctness
• need to relate code to specs
• but code is in terms of representation
• abstraction function
• A Rep -gt Abstract
• an abstract value may have several
  representations
• not all representations map to an abstract value
• rep invariant
• I Rep -gt Bool
• I(r) is true iff r is legal, ie. maps to an
  abstract object
• I(r) -gt r in dom A, but converse not necessary
• example
• set represented as vector
• A(v) e exists i. vi e
• I(v) no dup elements

Abstract
A
Rep
I
8
beneficent side effects

• what is an observer?
• an operation that doesnt change the value of the
  object
• which value? abstract value!
• in diagram, OP is an observer
• r ! r, but a a
• beneficent side effect
• operation changes rep, but not abstract, value
• for performance reasons
• balancing a tree
• caching frequently accessed element

a
a
OP_A
r
r
OP_R
9
procedures

• precondition
• describes obligation on client
• form predicate on state before execution of op
• precondition is a disclaimer
• if not satisfied, anything can happen
• includes returning ok this time, and fouling up
  later
• modifies
• describes what might be modified
• form list of names of objects/state components
• in practice, very subtle (aliasing, etc)
• omission generally means modifies nothing
• rationale intuitive, shortens postcondition,
  sometimes machine-checkable
• postcondition
• describes promise by implementor to client
• form predicate on state before and after
• may be non-deterministic
• several post-states for given pre-state

10
sample specs

• pathological cases
• precondition false?
• postcondition true?
• implicit postconditions
• T setchoose ()
• pre this !
• post result in this
• T seqdeq ()
• pre this ! ltgt
• post this this ltresultgt
• int int factorize(int x)
• pre x is not prime
• post result1 x result2 x result1 gt 1
  result2 gt 1

11
expression languages

• what language are the pre, post, mod clauses
  written in?
• theory-based
• roll-your-own datatypes with algebraic specs
• example
• Larch (Guttag, Horning, Wing, Garland)
• Larch Shared Language datatypes described
  algebraically
• Larch interface language one for each
  programming language
• model-based
• fixed set of datatypes sequence, set, mapping,
  tuple, etc
• examples
• VDM (Jones and Bjorner), grew out of work on
  language definition
• Z (Abrial, Morgan, Hoare, Spivey, et al), most
  popular FSL
• Object modelling notations (OCL, Alloy), based on
  sets and relations
• hacker-based
• informal, use observer methods as if they were
  predicates
• eg, pre table.containsKey (k)

12
good bad points of languages

• model-based languages
• dont need to reinvent basic types
• users find more intuitive
• risk of bias may pick the wrong model
• eg, model set using a sequence datatype
• theory-based languages
• can be more abstract
• can invent clever new types
• easy to get algebraic specs wrong
• hacker-based languages
• pragmatic economical
• easily understood
• easily misunderstood
• no machine processing possible

13
pragmatics

• where to focus your effort
• usually not feasible to formally specify all
  components
• so focus according to risk
• risk P(failure) x Cost(failure)
• examples
• widely used class with complex representation
• badly-designed component that youre forced to
  use
• in general
• rep invariants are almost always worthwhile
• non-trivial preconditions should be recorded
• stylistic issues
• i dont like modifies convention
• should never draw inference from the omission of
  a spec!
• same rationale for multiplicity markings in
  object model (in contrast to OMT blobs)
• declarative specs
• not always possible
• when methods bound at runtime are called, just
  say so

14
advanced topics

• things to look into yourself
• satisfaction
• what does it mean for an implementation to
  satisfy a spec?
• for one spec to be more demanding than another?
• is an abstraction function enough? (no)
• compositional spec
• have seen conjunction within clauses
• can entire specs be conjoined?
• views conjunction of specs with different state
  spaces
• preconditions vs. exceptions
• when should preconditions be used?
• when should they be checked by the implementor?
• unchecked vs. checked exceptions in Java?

15
composition by conjunction

• conjunctive postconditions
• describing sorting
• s Nat -gt T
• all i, j si lt sj -gt i lt j
• exists permutation p s (p s)
• composing operation schemas
• in Z, can form operations by logical composition
• OP1 OP2 OP3
• OP (OPerror SIGNAL) OPsuccess
• OP1 (Choose1 OP1) (Choose2 OP2)
• gives nice separation of aspects of an operation
• eg, error behaviour
• views composing entire specs
• can form an entire spec by composing operations
  of two specs
• all composition is conjunction
• states may be different!

16
example of view composition editor

• file view
• File left, right seq Char
• csrLeft ? File ? c Char ? left left
  ?c? ? right ?c? right
• insertChar ? File, c Char left left
  ?c? ? right right
• grid view
• Grid lines seq seq Char, x, y Nat y ?dom
  lines ? x ?dom lines(y) ?l ?ran lines ? l ?
  max ? last(l) ? spc, cr ? cr ? front(l)
• csrUp ? Grid y y-1 ? x min x,
  lines(y) ? lines lines
• composition
• Editor File Grid left right / lines
  left ( / (1..y-1) lt lines) (1..x-1) lt
  lines(y)
• Editor_csrLeft ? Editor csrLeftEditor_inse
  rtChar ? Editor insertCharEditor_csrUp
  ? Editor csrUp

17
class exercise

• add to the editor spec
• an operation that deletes lines
• a search/replace operation
• soft hyphenation
• questions
• which view did you have to change?
• how complex would the op be in the other view?
• can you predict exactly what will happen when the
  op executes?