Scribd
Upload
27 views20 pages

Week 3

Uploaded by

Muhammad usama
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
27 views20 pages

Week 3

Uploaded by

Muhammad usama
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 20

Formal Methods in Software Engineering

Formal Methods

 Formal Method (FM)


 Specification language
 Formal reasoning
 Body of techniques supported by
 Precise mathematics
 Powerful analysis tools
 Rigorous, effective mechanisms for system
 Modeling
 Synthesis
 Analysis
Motivation for Formal Specification
Motivation for Formal Specification
Formal Specification

 Requirements specification
 Notational statement of system services

 Software specification
 Formal abstract depiction of system services

 Architectural specification
 Graphical representation of system structure
 Formal abstract depiction of key system properties

 Module specification
 Formal module interface, behavior, interaction specifications
Formal methods in software development
Desirable properties of Formal Specification

 Unambiguous
 exactly one specific and (set) satisfies it
 e.g., “Component X has a single port on its top and bottom”
 Consistency
 a specificand exists that satisfies it
 e.g., interfaces of interacting components must match
 Completeness
 all aspects of specificand are specified
 e.g., interfaces of all components must be specified
 may be achieved incrementally
 Inference
 consequence relation used to prove properties about the specificands that satisfy a
specification
Formal Specification in software development

 Formal specifications based software development process is well-


defined.

 Orientation goes from customer to developer

 Formal specifications are expressed in languages with formally defined


syntax and semantics
 hierarchical decomposition
 mathematical foundation
 graphical presentation
 accompanied by informal description
Types of Formal Specifications

 Model-oriented specifications
 specify system behavior by constructing a model in terms of well-defined
mathematical constructs
 Property-oriented specifications
 specify system behavior in terms of properties that must be satisfied
 Visual specifications
 specify system structure and behavior by graphical depictions
 Executable specifications
 specify system behavior completely enough that specifications can run on
a computer
 this is not programming
Types of Formal Specifications
10

 Behavioral specifications describe constraints on the behavior of


specificand – e.g.,
–functionality
–safety
–security
–performance

 Structural specifications describe constraints on the internal


composition of specificand
–module interconnection
–uses and is-composed-of
–dependence relations
11 Basic Specification Language Types

 Abstract Model Specifications


–defines operations in terms of well-defined mathematical model
 Algebraic Specifications
–defines operations by a collection of equivalence relations
 State Transition Specifications
–defines operations in terms of states and transitions
 Axiomatic Specifications
–defines operations by logical assertions
Abstract Model Specifications
12
 Explicitly describes behavior in terms of a model using well-defined
types (sets, sequences, relations, functions) and defines operations by
showing effects on model
 Specification includes
–type: syntax of object being specified
–model: underlying structure
–invariant: properties of modeled object
–pre/post conditions: semantics of operations
 Pros and Cons
–state is made explicit in model
–suggests an implementation
–widely applicable because of modeling orientation
 Various notations: VDM, Z, RAISE
13 Algebraic Specifications

 Specification includes
–functionality: syntax and legal constructions
–relations: semantics by equivalence classes
 Pros and Cons
–only pure functions described (no side effects)
–supports extensibility of data abstractions
–often hard to comprehend and construct
–particularly applicable to abstract data types
 Various notations: OBJ, Larch, Clear, Anna
State Transition Specifications
14
 Explicitly describes system behaviour by a set of states and defines
operations as transitions between states or observations on state
 Specification includes
–states: possible values
–transitions: semantics by state transformations and observations
 Pros and Cons
–free of representational details (except augmentations)
–state explosion is common
–extensions to minimize states and modularize
–particularly applicable to control systems, languages, hardware
 Graphical as well as textual notations: StateCharts, ASLAN,
Paisley,InaJo, Special
Axiomatic Specifications
15
 Implicitly defines behavior in terms of [first-order] logic formulas
specifying input/output assertions (and possibly intermediate assertions)
 Specification includes
–operation interfaces: input/output parameters
–operation axioms: pre/post assertions on input/output
 Pros and Cons
–fairly easy to understand
–widely applicable (although hard to scale up)
–most widely used technique in proving (inductive assertion method)
–foundation of mathematics in software development
 Many languages support this type of specification:
–Extensions include various logics for specific application domains (e.g.,
temporal logic: RTIL, GIL)
–VDM, Anna
Integrating Formal Methods in Development

 Option 1: business as usual with after-the-fact verification

 formal specification constructed after system implementation

 implementation checked for consistency against the specification

 increases confidence in the system

 time- and money-consuming


Integrating Formal Methods in Development

 Option 2: verification in parallel


 two teams — development team and formal verification team
 requires constant communication between the two teams
 may degenerate into option 1 due to poor communication
 less time consuming but as expensive as option 1

 Option 3: integrated verification


 one team that does development and formal verification
 single integrated development process
 better, cheaper, and faster than options 1 and 2
Formal Specification

Intended to remedy the seven sins of the specifier


1. noise / redundancy
2. Silence -- missing
3. Over specification
4. contradiction
5. ambiguity
6. forward reference
7. wishful thinking
Thanks
References

 https://www.slideshare.net/erant/formal-modeling-with-z
 https://www.slideshare.net/Falguni_Roy/z-specification

You might also like