Formal Specification

1
Formal Specification

• Specification are classified as
• informal -- natural language
• semiformal -- SA, SSA, SADT, PSL/PSA, SREM
• formal -- Z, RML, VDM, GIST, OCL

2
Definition

• A formal software specification is a
  specification expressed in a language whose
  vocabulary, syntax, and semantics are formally
  defined (i.e., based on mathematics)
• A language used to specify systems is known as a
  formal specification language

3
Philosophy

• Philosophy of formal methods of software
  development
• We should use mathematics to record as much of
  the development as is practical

4
Formalization

• The process of making a vague notion precise can
  be applied to software development as well as to
  other areas of applied mathematics
• Specification
• Verification

5
Underlying Theme

• Formal methods lead to more precise
  specifications than semiformal or informal
  methods can.
• Formal methods are most widely used in the
  specification of the functional requirements

6
Systems Analysis

• As specifications are refined, understanding is
  increased.
• Producing a formal specification forces a
  detailed systems analysis which reveals errors
  and inconsistencies in the informal
  specification.
• Formal specifications have not been widely used
  because the effort seemed to outweigh the
  advantages.
• However, studies show formal methods increase
  system quality and decrease development costs.
  

7
Approaches to Formal Methods

• European formal specification as a valued
  technique to increase understanding and improve
  specification not concerned with formal
  verification
• North American the value of formal
  specification lies in the fact that verification
  techniques can be applied to the spec (i.e.,
  proving specs correct and other verification
  oriented techniques)

8
Results

• In Europe,
• Formal specification is used in industry
• The UK is mandating formal specs for
  safety-critical defense systems
• The benefits are obvious and there is not a fear
  of formal methods

9
Results

• Most of the work has focused on verification
• Since verification is difficult and expensive
  (and impractical for all but very small systems),
  it has not been widely used.
• IBM's cleanroom approach is one exception, (a
  looser interpretation of verification).
• Most SE's see formal methods as a topic for
  research rather than a viable technique

10
Advantages

• Increased understanding of software requirements
  and design (reduces errors and omissions)
• Potential for program verification -- (e.g.,
  prove specs consistent and complete, or prove
  that spec matches reqts., "proving correct") --
  better to have ability to reason about the spec
• Specs can be automatically processed -- executed
  or animated to get prototype

11
More on Formal Methods

• Involve the specification of a system using
  languages based on mathematical logic
• Can accomplish the equivalent of exhaustive
  testing

12
Mathematical Logic

• Mathematical proof may be used to establish that
  an implementation meets the abstract properties
• The use of semi-automatic theorem provers can
  ensure correctness of a specification

13
Formal Specs Not Widely Used

• Difficult to show that high cost of developing a
  formal spec will really reduce the overall
  software development costs.
• Most SEs don't know formal spec techniques need
  to know discrete math and logic so formal specs
  appear difficult
• System procurers are unfamiliar with formal
  methods

14
Formal Specs Are Not Widely Used

• Some classes of systems are difficult to describe
  using formal specs (e.g., user interfaces,
  parallel systems, and interrupt-driven real time
  systems)
• Ignorance of formal methods -- several hundred
  large scale systems formally specified (mostly in
  Europe)
• Most research has been on notations and
  techniques and very little on tool support.

15
Formal Specs Are Not Widely Used

• Misunderstanding of the ramifications of
  practical adoption of formal methods -- belief
  that formal methods software engineering

16
OCL

• The Object Constraint Language
• A constraint is a restriction on one or more
  values of an object oriented model or system
• A constraint is an assertion
• The goal of OCL is to allow developers to
  describe models with more precision.

17
Assertions

• Invariants
• Preconditions
• Postconditions

18
Specification

• Describe what the objects of a class should
  accomplish
• In contrast, detailed design describe how the
  class will accomplish its purpose.

19
Formal Specification

• Descriptions that are more precise, complete,
  clear, and correct
• As specifications are refined, understanding is
  increased.
• Producing a formal specification forces a
  detailed systems analysis which reveals errors
  and inconsistencies in the informal specification.

20
Goals of Formal Specification

• Correctness
• Robustness

21
More on Formal Specifications

• Involve the specification of a system using
  languages based on mathematical logic
• Can accomplish the equivalent of exhaustive
  testing

22
Specification of an Operation

• The task performed by an operation is specified
  by two assertions associated with the operation
• A precondition
• A Postcondition

23
Precondition

• Expresses the constraint under which an operation
  will perform properly
• It applies to all invocations of the operation.
• In a correct program, no invocation is ever
  executed in a state in which the precondition of
  the operation is not satisfied

24
Postcondition

• Expresses conditions of the state resulting after
  execution of the operation
• Describes the semantics of the operation

25
Design by Contract

• An object is a provider or supplier of services
• Another object is a client if it requires
  services provided by another object

26
A Contract

• An object is responsible for executing services
  (obligations) if and only if certain stipulations
  (rights) are fulfilled
• A contract is the exact specification of a class.

27
Contents of a Contract

• The conditions under which services will be
  provided
• A specification of the result of the service
  provided that the conditions are fulfilled

28
Example of Contract

• If a stack is non-empty, the result of the pop
  operation returns the item retrieved from the top
  of the stack.
• Rights and obligations are stated precisely

29
Class Specification

• Advertises its services by listing its public
  methods, each with its name, signature, and
  return type
• Preconditions in every method
• Postconditions in every method
• Class invariants

30
Contract Details

• For each operation, the rights of the object that
  offers the contract are specified by its
  precondition
• The obligations are described by its postcondition

31
Assertions

• Invariants, conditions that must always be true
  in all instances of the class
• Preconditions
• Postconditions

32
Invariants

• A list of assertions that express general
  consistency constraints that apply to every
  instance of a class
• This is different from preconditions and
  postconditions, which characterize individual
  operations

33
Need for a Contract

• By forcing a clear definition of whose
  responsibilities to check every condition
  required for correct operation, the method
  emphasizes an approach that is
• Systematic
• Rigorous
• This helps guarantee development of correct
  programs.

34
Class Correctness

• A class is correct if and only if its
  implementation is consistent with its
  specification
• For every operation
• INV and precond op INV and postcond

35
OCL

• The Object Constraint Language
• A constraint is a restriction on one or more
  values of an object oriented model or system
• A constraint is an assertion
• The goal of OCL is to allow developers to
  describe models with more precision.

36
Exploiting Design Information

• Alloy and UML/OCL provide a means for expressing
  properties of designs
• Early design refinement saves time
• Ultimately, we want this effort to impact the
  quality of implementations
• How can we transition design information to the
  code?
• State information (multiplicities, invariants, )
• Operations info (pre, post, frame conditions, )

37
Definition

• A formal software specification is a
  specification expressed in a language whose
  vocabulary, syntax, and semantics are formally
  defined (i.e., based on mathematics)
• A language used to specify systems is known as a
  formal specification language

38
Specification

• Describe what the objects of a class should
  accomplish
• In contrast, detailed design describe how the
  class will accomplish its purpose.

39
Formal Specification

• Descriptions that are more precise, complete,
  clear, and correct
• As specifications are refined, understanding is
  increased.
• Producing a formal specification forces a
  detailed systems analysis which reveals errors
  and inconsistencies in the informal specification.

40
Goals of Formal Specification

• Correctness
• Robustness

41
More on Formal Specifications

• Involve the specification of a system using
  languages based on mathematical logic
• Can accomplish the equivalent of exhaustive
  testing

42
Specification of an Operation

• The task performed by an operation is specified
  by two assertions associated with the operation
• A precondition
• A Postcondition

43
Precondition

• Expresses the constraint under which an operation
  will perform properly
• It applies to all invocations of the operation.
• In a correct program, no invocation is ever
  executed in a state in which the precondition of
  the operation is not satisfied

44
Postcondition

• Expresses conditions of the state resulting after
  execution of the operation
• Describes the semantics of the operation

45
Design by Contract

• An object is a provider or supplier of services
• Another object is a client if it requires
  services provided by another object

46
A Contract

• An object is responsible for executing services
  (obligations) if and only if certain stipulations
  (rights) are fulfilled
• A contract is the exact specification of a class.

47
Contents of a Contract

• The conditions under which services will be
  provided
• A specification of the result of the service
  provided that the conditions are fulfilled

48
Example of Contract

• If a stack is non-empty, the result of the pop
  operation returns the item retrieved from the top
  of the stack.
• Rights and obligations are stated precisely

49
Class Specification

• Advertises its services by listing its public
  methods, each with its name, signature, and
  return type
• Preconditions in every method
• Postconditions in every method
• Class invariants

50
Contract Details

• For each operation, the rights of the object that
  offers the contract are specified by its
  precondition
• The obligations are described by its postcondition

51
Assertions

• Invariants, conditions that must always be true
  in all instances of the class
• Preconditions
• Postconditions

52
Invariants

• A list of assertions that express general
  consistency constraints that apply to every
  instance of a class
• This is different from preconditions and
  postconditions, which characterize individual
  operations

53
Need for a Contract

• By forcing a clear definition of whose
  responsibilities to check every condition
  required for correct operation, the method
  emphasizes an approach that is
• Systematic
• Rigorous
• This helps guarantee development of correct
  programs.

54
Class Correctness

• A class is correct if and only if its
  implementation is consistent with its
  specification
• For every operation
• INV and precond op INV and postcond

55
OCL

• The Object Constraint Language
• A constraint is a restriction on one or more
  values of an object oriented model or system
• A constraint is an assertion
• The goal of OCL is to allow developers to
  describe models with more precision.

56
Exploiting Design Information

• Alloy and UML/OCL provide a means for expressing
  properties of designs
• Early design refinement saves time
• Ultimately, we want this effort to impact the
  quality of implementations
• How can we transition design information to the
  code?
• State information (multiplicities, invariants, )
• Operations info (pre, post, frame conditions, )

57
Design By Contract...

• A method that emphasizes the precise description
  of interface semantics
• Not just syntax, e.g., signatures
• But behavior, e.g., effects of a method call
• It is supported by tools that
• allow semantic properties of the design to be
  propagated to the code
• support various forms of validation of those
• properties

58
Basic Idea

• Software is viewed as
• a system of communicating components
• all interaction is governed by contracts
• contracts are precise specifications of mutual
  obligation
• Note that contracts are bi-directional
• both parties are obligated by them

59
Specifications are Necessary

• But not sufficient for software quality
• The Law of Excluded Miracles
• Without a specification we have no hope of a
  system that works properly
• Content of specification varies
• Lightweight (partial)
• Complete behavioral specification
• Tool support varies
• Commercial/research, Static/dynamic checking

60
Contracts

• Two parties are involved in a contract
• The supplier performs a task
• The client requests that the task be performed
• Each party
• has obligations
• receives some benefits
• Contracts specify those obligations and
• benefits

61
Air Travel

• Supplier (Airline)
• Obligation
• take traveler to Boston
• Benefit
• dont need to wait for late travelers
• dont need to store
• arbitrary amounts of luggage
• money

• Client (Traveler)
• Obligation
• check in 10 minutes before boarding
• lt3 small carry-ons
• buy ticket
• Benefit
• reach Atlanta

62
More on Contracts

• Specify what should be done
• they are implementation independent
• n This same idea can be applied to software using
  the building blocks weve learned
• Pre-conditions
• Post-conditions
• Frame-conditions
• Invariants

63
Programming by Contract

• Reduce the risk of discrepancies between
  specifications and implementations
• Include specification elements within the
  implementations
• Include assertions in programming
• This increases the level of correctness and
  robustness of software

64
Preconditions and Postconditions

• A function (or method) may be specified by two
  assertions
• a precondition, which expresses the properties
  that must hold when the function is invoked
• a postcondition, which expresses the properties
  that must hold when the function completes

65
A Stack Class

• abstract class Stack
• private int nb_elements
• abstract public boolean empty() // is stack
  empty?
• abstract public boolean full()
• /
• remove the element from top of stack (TOS)
• _at_pre not empty()
• _at_post not full()
• _at_post nb_elements nb_elements_at_pre 1
• /
• public void pop()

66
Stack Class (2)

• /
• Get copy of the element at top of stack
• _at_pre not empty()
• /
• public T top()
• /
• Push a new element to TOS
• _at_pre not full()
• _at_post not empty()
• _at_post top() x
• _at_post nb_element nb_element_at_pre 1
• /
• public void push(T x) // push an item of type T

67
Explanation of Stack Specification

• Preconditions
• Push may not be invoked if the stack is full
• Pop and top may not be applied to an empty stack
• Postconditions
• After a push
• the stack may not be empty
• Its top element is the one just pushed
• The number of elements has been increased by one
• After a pop, the stack may not be full, and its
  number of elements has been decreased by one

68
Precondition is not Satisfied?

• If the clients part of the contract is not
  satisfied, i.e., if the call does not satisfy the
  precondition, the the class is not bound by the
  postcondition
• In this case the function can do anything.
• The advantage of this convention is that it
  considerably simplifies the programming style
• When writing the implementation of the function,
  you may assume that the constraints are
  satisfied, so there is no need to test them

69
Class Invariant

• The class invariant expresses the global
  properties of the instances of the class, which
  must be preserved by all member functions
• In class Stack, an important consistency
  requirement is that the attribute must satisfy at
  all times
• nb_elements 0 and nb_elements MAX

70
Program Correctness

• Using assertions in programming is the essence of
  programming by contract
• It enforces a clear definition of whose
  responsibility it is to check every condition
  required for correct operation
• The method emphasizes a systematic, rigorous
  approach to the construction of correct programs

71
Class Correctness

• A class is correct if and only if its
  implementation is consistent with its
  specification
• For every operation
• INV and precond op INV and postcond

72
Taking a flight

• Class Flight
• /
• _at_pre time lt this.takeoff 10
• _at_pre l.number lt 3
• _at_pre p in this.ticketed
• _at_post result this.destination
• /
• Destination takeFlight(Person p, Luggage l)