1. Duminda WijesekeraSWSE 623: Introduction1 Introduction to Formal and Semi- formal Methods Based on A Specifier's Introduction to Formal Methods (J. Wing)

2. Duminda WijesekeraSWSE 623: Introduction2 Formal and Semi-formal Methods Formal = Have a well defined mathematical basis Can apply to any stage of the life cycle –Recast every thing in mathematics and prove relevant properties Can be used for: –Syntactic analysis –Semantic analysis –The issue here is of computational complexity

3. Duminda WijesekeraSWSE 623: Introduction3 Semi Formal Methods Semi-formal= Only partly mathematical Could mean –Only some aspects formalized –Only syntactic methods available

4. Duminda WijesekeraSWSE 623: Introduction4 Specification Languages Syntax, Semantics, Satisfaction, deduction system, soundness and consistency Examples: –First Order Logic –BNF Differences in specification languages –Syntactic –Semantic –Satisfaction

5. Duminda WijesekeraSWSE 623: Introduction5 Programming languages vs. Specification languages Programming languages are executable. –Have operational semantics. –Have denotational semantics also. Specification languages do not have to be executable. –Programming Language => Specification Language –Specification Languages =/=> Programming Language

6. Duminda WijesekeraSWSE 623: Introduction6 Programming languages vs. Specification languages – Cont. Why have more abstract specification Languages? –Specification languages are at a higher level –May want to specify non-computable facts –Separate specification from implementation One specification and many implementations in many languages and operational environments Specifications have a life independent of implementational optimizations

7. Duminda WijesekeraSWSE 623: Introduction7 Using a Programming Language as a Specification Language Cons: –Not able to verify before compiling –Low level, no logical derivations –Specification tied to one language Pros: –No gap between specification and code –Correctness is not an issue – NuPrl.

8. Duminda WijesekeraSWSE 623: Introduction8 Semantic Domains Programming language have operational and denotational semantics. Can use satisfaction relation as implementation. Semantic abstraction function –Divide semantic domain into equivalence classes. –Extend satisfaction relation into equivalence classes. Can have many semantic abstraction functions Can impose different constraints Can specify and verify different aspects

9. Duminda WijesekeraSWSE 623: Introduction9 Many Specification Languages for Same System Can specify and verify complementary properties Specification types –Structure of system –Behavior Semantic Domain Specification 1Specification 2

10. Duminda WijesekeraSWSE 623: Introduction10 Structural Specifications Constraints on internal composition –Class diagrams –Modula interconnection diagrams Captures –Hierarchies –Associations –Usage –Data and control dependencies

11. Duminda WijesekeraSWSE 623: Introduction11 Behavioral Specifications Constraints on observable behavior Example: –Input-output behavior of modules –Interactions between modules, message passing Captures –Fault tolerance –Safety, security, –Timing, resource consumption patterns –Quality of service

12. Duminda WijesekeraSWSE 623: Introduction12 Properties of Specifications Unamibiguity: Satisfaction relation maps each object in the syntactic domain to a unique object in the semantic domain Consistency: Satisfaction relation maps each object in the syntactic domain to a non-empty object in the semantic domain Completeness: If every sentence or its negation is implied by the specification. Difficult to get –Relative completeness –Over-specification Vs. Design freedom –Semantic Bias Vs. Implication Bias

13. Duminda WijesekeraSWSE 623: Introduction13 Specifications and Proofs Have a deduction system with proof rules and (possibly) assumptions. –Can be partially automated Can predict system behavior without execution –Increases confidence and assurance

14. Duminda WijesekeraSWSE 623: Introduction14 Refinement Divide and conquer –A higher level specification can be divided into a set of lower level specifications. –Prove components correct, combine them and prove larger specification correct –Breaks down a proof with a goal into sub-proofs with sub-goals Examples we discuss: –Predicate transformers Dijkstra –Hoare triples for weakest preconditions etc.

15. Duminda WijesekeraSWSE 623: Introduction15 Types of Formal Methods Model Oriented: Construct a model of the system behavior using mathematical objects like sets, sequences etc. –Statecharts, SCR, VDM, Z –Petri Nets, CCS, CSP, Automata theoretic models Property Oriented: Use a set of necessary properties to describe system behavior, such as axioms, rules etc. –Larch, Algebraic semantics –Temporal logic models.