Formal method for SE
Lecture 01
Software Engineering & Formal Methods
Every software engineering methodology is based on a
recommended development process
proceeding through several phases:
Requirements, Specification, Design, Coding, Unit Testing, Integration
and System Testing, Maintenance
Formal methods can
Be a foundation for designing safety critical systems
Be a foundation for describing complex systems
Provide support for program development
Complimentary approach to methodology
Testing: Static vs Dynamic Analysis
Static analysis of code -> Does not require execution of code
Lexical analysis of the program syntax and investigates and
checks the structure and usage of individual statements; often
automated
Dynamic Analysis of code -> Involves running the system (testing)
Program run formally under controlled conditions with specific
results expected Path and Branch Testing
What are Formal Methods
Tools and Techniques based on mathematics and forma logic
Can assume various forms and level of rigor
i.e Informal, Low, Medium and High
Least Rigorous Rigor Spectrum Most Rigorous
Occasional Mathematical Fully formed specification
Notations Embedded in language with precise
English specification semantics
Why need Formal Methods
• Systems are increasingly dependent on software components
• Complexity of systems with embedded software has increased
rapidly
• Maintaining reliability in software-intensive system is very difficult
Formal Methods Concepts
• Formal Specification Methods
Formal
Formal Model
Specification Abstraction
Proofs Checking
s
Types of Specifications I
Informal
Free form, natural language
Ambiguity and lack of organization can lead to incompleteness,
inconsistency, and misunderstandings
Formatted
Standardized Syntax
Basic consistency and completeness checks
Imprecise semantics implies other sources of error may still be
present
Types of Specifications II
Formal
Syntax and semantics rigorously defined
Precise form, perhaps mathematical
Eliminate imprecision and ambiguity
Provide basis for mathematically verifying equivalence between
specification and implementation
May be hard to read without training
Semantic distance?
Formal Specifications
The translation of non-mathematical description (diagrams, table,
natural language) into a formal specification language
Concise description of high-level behavior and properties of a
system
Well-defined language semantics support formal deduction about
the specification
More on Formal Specifications
Goal: Describe external behavior without describing or constraining
implementation
Formal Method has 2 parts:
Logical Theory
Structuring Theory
Formal Specification Types
Property Oriented: State desired properties in a purely declarative way
Algebraic: Data type viewed as an algebra, axioms state properties of data type’s
operations
Axiomatic: Uses first order predicate logic, pre and post conditions Operational
Specification: Describe desired behaviour by providing model of system
Model Oriented: Provide direct way of describing system behavior (sets,
sequences, tuples, maps) :
Abstract Model (in terms previously defined mathematical objects eg. sets, sequences,
functions, mappings)
State machines
Property Oriented – Algebraic Expression
Uses
Input-Output Assertions
Sets of operations
Axioms specifying behaviour of operations
Two parts to a specification
Syntax
axioms
Model-Oriented: Abstract Model Specification
Build an abstract model of required software behaviour using
mathematically defined types (sets, relations)
Define operations by showing effects of that operation on the model
Specification includes:
• Model Type
• Invariant properties of model
• For each operation
o Name, parameters, return values
• Pre- and Post- conditions
