Introduction to Formal Methods

of 26 /26
Introduction to Formal Methods Based on Jeannette M. Wing. A Specifier's Introduction to Formal Methods. IEEE Computer, 23(9):8-24, September, 1990. 1

Embed Size (px)


Introduction to Formal Methods. Based on Jeannette M. Wing. A Specifier's Introduction to Formal Methods. IEEE Computer, 23(9):8-24, September, 1990. Outline. Definition of formal methods and specification languages Pragmatics of formal specifications - PowerPoint PPT Presentation

Transcript of Introduction to Formal Methods

Page 1: Introduction to Formal Methods

Introduction to Formal Methods

Based on

Jeannette M. Wing. A Specifier's Introduction to Formal Methods. IEEE Computer, 23(9):8-24, September, 1990.


Page 2: Introduction to Formal Methods


• Definition of formal methods and specification languages• Pragmatics of formal specifications• Examples: Z, VDM, Larch, temporal logic, CSP,

transition axioms


Page 3: Introduction to Formal Methods

In-class: Read page 8 (10 mins)

• Q: What are formal methods• At what stages of system development can formal

methods be used?• Some advantages of formal specifications?


Page 4: Introduction to Formal Methods

Formal Methods

• Definition: Formal Methods Mathematically based techniques that describe system properties, from which, people can systematically specify, develop, and verify systems.

• The mathematical foundation allows for a concise and unambiguous definition of notions such as:–Consistency–Completeness–Specification–Implementation–Correctness

• Because the semantics are formally defined, they are amenable to machine analysis and manipulation.


Page 5: Introduction to Formal Methods

Formal Methods

• Can be used to specify:– behavioral properties– structural properties– pragmatic considerations, e.g. response time

• Applicable at all phases of the software lifecycle.– Requirements analysis– Design– V & V– Documentation– Analysis and evaluation


Page 6: Introduction to Formal Methods

In-class: Read pages 10-11

• Q1: Three elements of formal specification languages?• Q2: Example semantic domains?• Q3: Why an “abstract satisfies relation” on top of the

“satisfies” relation?


Page 7: Introduction to Formal Methods

Formal Specification Language

• Triple, <Syn, Sem, Sat>– Syn: language’s syntactic domain, a set– Sem: language’s semantic, a set– Sat: a satisfies relation between Syn and Sem, a subset of Syn X Sem

• Given <Syn, Sem, Sat>– If Sat(syn, sem), syn is a specification of sem and sem is a specificand of syn.

• Given <Syn, Sem, Sat>– The specificand set of all specifications syn in Syn is the set of all specificands

sem in Sem such that Sat(syn, sem).– I.e., Sat doesn’t have to be a function; but why?– Q: Any other properties of Sat?


Page 8: Introduction to Formal Methods

Syntactic Domains

• Defined as a set of symbols and grammatical rules– Symbols can be constants, variables, and logical connectives– Grammatical rules define how to combine the symbols into well formed

sentences– E.g., x.P(x) Q(x)

• A syntactic domain need not be restricted to text– Symbols can include boxes, circles, lines, arrows, etc.– A possible rule could be that “an arrow must be connected at both ends to a box”

• Essentially, the syntactic domain is the set of all possible well formed specifications that can be expressed using the symbols, whether textual or graphical.


Page 9: Introduction to Formal Methods

Semantic Domains

• Semantic domain – Set of objects in the universe of what the language can describe;

i.e., meanings or interpretations.

• Examples– ADTs languages: Algebras, theories, programs

– Concurrent/Distributed: State sequences, event sequences, state and transition sequences, streams, synchronization trees, partial orders, state machines

– Programming languages: Functions from input to output, computations, predicate transformers, machine instructions

• If semantic domain is over programs:– Implements for satisfies– implementation for specificand


Page 10: Introduction to Formal Methods

Satisfies Relation

• Often need to specify different aspects of a single specificand (various abstractions), e.g.,

– Functional behavior of a collection of program modules– Structural relationships between the modules

• Abstraction function for different views– A semantic abstraction function maps elements of the semantic domain into

equivalence classes– A partition of the semantic domains

• Abstract satisfies relation between specs and equivalence classes of semantic domains


Page 11: Introduction to Formal Methods

Abstract Satisfies Relation

Java Methods

all methods that sort arrays

all methods that use the set class 11

Page 12: Introduction to Formal Methods

Abstract Satisfies Relation

• Two broad classes of abstraction functions:– Those that abstract preserving behavior– Those that abstract preserving structure

• Behavioral specifications– Constraints on observed behavior– Functionality such as a mapping from inputs to outputs (Cleanroom)– Other aspects such as fault tolerance, safety, security, response time, and space


• Structural specifications– Constraints on the internal composition of specificands– Capture hierarchical and uses relations– Denoted by call graphs, data dependency diagrams, etc.


Page 13: Introduction to Formal Methods

Properties of Specifications

• Unambiguous– Given <Syn, Sem, Sat>, a spec. syn is unambiguous if Sat maps syn to exactly

one specificand set.

• Consistent– Given <Syn, Sem, Sat>, a spec. syn is consistent if Sat maps syn to a non-empty

specificand set.

• Complete vs. incomplete (or loose specifications)– More complete: implementation bias and less freedom– Less complete: more freedom to programmer and less restrictive


Page 14: Introduction to Formal Methods

Proving properties of Specificands

• Most formal methods include a language that has a well-defined logical inference engine.

• When you prove a specification inferable from the the set of facts (other specs), you prove a property that a specificand satisfying the facts (other specs) will have.– Soundness vs. completeness

• If users are able to prove a surprising result, then perhaps the base specifications are wrong.


Page 15: Introduction to Formal Methods


• Users– Writers– Readers

• Use• Characteristics


Page 16: Introduction to Formal Methods

Use of Formal Methods

• Formal methods can be applied to all phases of system development, e.g., throughout development lifecycle

• Requirements– Clarify customer’s stated requirements– Crystallize vague ideas– Aid communication between engineer and client, e.g., English to spec / spec to

English tools

• Design– Aids in decomposition, e.g., by formally specify interfaces between modules – Aids in refinement, e.g., by ensuring that different levels of abstractions all

satisfy a parent specification


Page 17: Introduction to Formal Methods

Use of Formal Methods

• Verification and validation– Guide the building of test cases, e.g., black-box testing– Verify the critical sections of implementation

• Documentation– More precise and concise than natural language

• Analysis and evaluation– Serve as reference point between what the customer wanted and what was

implemented– Can be used to find bugs in existing systems that weren’t developed using formal



Page 18: Introduction to Formal Methods

Characteristics of FMs

• Model-oriented– Define a system’s behavior directly by constructing a model– Model in terms of mathematical structures such as sets, functions, relations, and

sequences– Use model to show correctness with respect to specifications– E.g., Sequential and ADT: Z, VDM

Concurrent and distributed: Petri net, CCS, CSP

• Property-oriented– Define a system behavior indirectly by stating a set of properties that the system

must satisfy– Properties in the form of axioms– E.g., Larch, OBJ, Clear, ACT ONE


Page 19: Introduction to Formal Methods

Characteristics of FMs

• Visual languages– HIPO, Structured design, Software Requirements Engineering


• Executable– OBJ, Prolog– Q: Should a formal specification language be executable?

• Tool-supported– Model-checking tools: EMC– Proof-checking tools: Boyer-Moore Theorem Prover, FDM,HDM,



Page 20: Introduction to Formal Methods

Language Examples(Symbol Table in Z and VDM)


Page 21: Introduction to Formal Methods

Symbol Table – Larch




Page 22: Introduction to Formal Methods

Concurrency - Temporal Logic


Based on temporal operators such as: P: In all future state P: in some future state

– OP: in the next state

Q: Meanings of (1)-(4)?

Notation: <c!m> event of placing message m on channel c.

Page 23: Introduction to Formal Methods

Temporal Logic• (1) Any message transmitted to the right channel must have been

previously placed on the left channel• (2) Messages are transmitted first in, first out• (3) All messages are unique• (4) Each incoming message will eventually be transmitted


Page 24: Introduction to Formal Methods

Concurrency – Communicating Sequential Process (CSP)

Based on a model of traces or event sequences, and assumes processes communicate by sending messages.


prefix refusal set: refuse to communicate


Page 25: Introduction to Formal Methods

Concurrency – Transition Axiom


Axioms for operations

Temporal logic for properties

Page 26: Introduction to Formal Methods


• Differences among formal methods– notation, semantic domain, definition of the

satisfies relation

• But, same purpose – Let system developers couch their ideas

precisely – I.e., provide a way to specify and verify

programs in order to provide a deeper understanding of a system for clients, designers, implementers, and testers.