Formal Methods of Specification

1
Formal Methods of Specification

• Specifications written in natural language may be
  ambiguous and it may be difficult to trace code
  back to them to verify that the resulting
  software satisfies requirements.
• Formal methods arose as a technique based upon
  mathematical syntax to write specifications.
• The concept of formal specification involves
  translating requirements into a technical
  language which does not suffer from the problems
  associated with natural languages.
  Gregory Jones, 1992

2

• Goals of formal specifications - From Jones
  (1992)
• Making sure that data representations and
  operations are correct
• Provides a way to formally prove that program
  specifications are correct mathematically. They
  allow you to reason about the validity of a
  specification or whether certain requirements are
  mutually exclusive.
• Allow automatic translation from specification to
  implementation with CASE tools.

3

• What are formal methods?
• System specifications are usually presented in a
  mixture of natural language, graphical notations,
  and pseudocode. A formal specification, by
  contrast, uses a precisely defined mathematical
  language to describe the system properties. This
  leaves less room for ambiguity in the
  requirements, and also opens the way for
  automatic checking for errors and inconsistencies
  in requirements. From Larsen, Fitzgerald, and
  Brookes, 1996.

4

• Difficulties with formal methods
• They are difficult to read, understand and
  construct. This is due in part to their textual
  rather than visual nature. It usually takes
  about one week to teach a programmer the syntax
  of a formal method. Proving correctness with
  formal methods requires advanced math training.
• There are many formal methods. It is hard to
  know which method to use. If you pick the wrong
  method for a given project, the benefits of
  formal methods may vanish.

5

• Formal specification techniques concentrate
  primarily on functional descriptions of software.
  They do not provide for the description of
  non-functional requirements. Thus, they do not
  help express things like speed and reliability.
  They also do not help much with specifying user
  interfaces, where attributes that are not easy to
  specify in mathematical and logical fashion come
  into play.

6

• Formal methods intertwine specification, design,
  and testing. Specification has usually been
  limited to the expression of what the system
  did, not how it did it. Formal methods tend to
  force the consideration of data entities and
  design details associated with behavior. Formal
  methods specifications tend to become a part of
  the design phase documentation.
• Major types of formal methods
• Vienna Development Method (VDM) - Each
  specification can be viewed as a set of state
  descriptions.
• Z Specification notation - Closely aligned with
  set theory.

7
(No Transcript)
8
(No Transcript)
9
Further points about formal specifications

• Formal methods do not guarantee that software is
  perfect. A proof is a demonstration that one
  thing follows from another. Real world
  situations often cannot be modeled exactly by
  mathematical models. Also, you can make mistakes
  in writing specifications with formal methods,
  just as you can make mistakes writing programs.
  But mistakes are easier to spot when done in
  formal specifications.

10

• It has been found that inspections of formal
  specifications reveal more errors than those of
  informal specifications. It is more effective to
  inspect designs or programs against formal
  specifications than against other kinds of design
  documentation. With formal methods more errors
  are removed prior to coding.
• Formal methods are useful whenever the cost of
  failure is high. This includes in particular
  safety- or security-critical systems. It also
  includes systems fixed into hardware and systems
  dependent upon quality for commercial reasons.

11

• Formal methods are not excessively hard to learn.
  It has been reported it takes about one - two
  weeks for a programmer to learn how to write
  specifications in a formal language. Doing
  proofs, as may be desired with safety-critical
  software, does require mathematical background.
• Formal methods can complement other approaches.
  Techniques like showing specifications using
  visual methods (i.e. data flow diagrams) and
  making a rapid prototype can be used in
  conjunction with formal methods. Hall (1990)
  reports building rapid prototypes to explore
  requirements issues relating to the user
  interface and then using formal methods for the
  systems actual functions.

12

• The effects of formal methods on project
  schedules is unclear. They do seem to shift more
  of the effort to the specification/design phases.
  Software estimation techniques based upon
  historical data from non-formal methods projects
  may not apply.
• Formal methods are usually only applied to the
  most critical portions of a software project. In
  many projects where formal methods are used it is
  only applied to about one tenth of the entire
  system.

13
Results of Applying Formal Methods in Industry

• Larsen, Fitzgerald, and Brookes (1996) reported
  on a study done at British Aerospace Systems and
  Equipment Ltd.
• Two parallel groups worked on a security
  sensitive project. One group used traditional
  structured analysis with CASE tool support. The
  other used the same design process, but
  supplemented it with formal methods wherever they
  felt it was appropriate. They focused upon how
  adding formal methods affected the cost and
  quality of the designs produced. Formal methods
  were only used for system modeling, not for doing
  formal proofs.

14

• They looked at a log of queries to track how well
  the two teams tackled the problems of misstated,
  incomplete, or ambiguous requirements. The
  engineer on the conventional path submitted
  approximately 40 questions the engineer on the
  formal path submitted approximately 60. The
  queries were classified and it was found that the
  team using formal methods focused more on the
  understanding the data and data structure and on
  determining what the system had to do under
  exceptional circumstances.

15

• This was seen as useful because in the message
  passing system they were designing these were
  traditional sources of error. The authors
  believed this happened because the formal method
  they chose emphasized data description. This
  highlighted how important it was to select the
  right formal method from among the many out
  there. Different specification languages are
  suitable for different applications.

16

• In the implementation phase, the program was
  written in pseudocode and then coded in C. Each
  path drew up test cases and software from both
  paths underwent all the test cases. Upon testing
  it was found that the conventional path failed
  several of the test cases drawn up by the formal
  methods path. The formal methods group had
  earlier caught a requirements omission on how the
  system should react under a particular
  combination of conditions.

17

• This fault was never detected by the conventional
  path. It would have gone undetected until the
  product entered service. A significant portion
  of the software development effort would have had
  to have been repeated. They estimated this would
  have increased overall development costs 20 to 30
  percent. Remember - Errors detected late in the
  development process are expensive to correct.

18

• Overview - The overall development effort for the
  formal methods path was slightly less than that
  of conventional development, but not
  significantly so. Formal specification adds to
  costs in the early stages of the development
  process, when engineers analyze system
  requirements, but this additional effort is
  recovered in the later stages.