1. Formal Methods in SE Software Verification Using Formal Methods By: Qaisar Javaid, Assistant Professor Formal Methods1

2. 2 Formal Methods in Block Handler

3. Concept  Current methods of software development involves only combination of diagrams, text, tables etc.  No methods are used to test the correctness of the end result in each of stages of software development for e.g. requirement specification, design etc.  This may lead to contradictions, ambiguities, incompleteness, vagueness etc.  This may not be a good option for safety-critical or mission critical systems,where failure may have high price

4. Concept  Formal methods allow a software engineer to create a specification that is more consistent and unambiguous  Set theory and logic notations are used to create a clear statement of facts (requirements) which can then be analyzed to prove correctness and consistency  Since specification is created using mathematical notation, it is inherently less ambiguous than informal modes of representation.

5. Definitions  Data Invariant A data invariant is a condition that is true throughout the execution of the system that contains a collection of data. E.g. maximum number elements in any system, duplication not allowed in a system.  State A state is the stored data that a system accesses and alter.

6. Definitions  Operation It is defined as action that takes place in a system and reads or writes data to a state It is associated with 2 conditions 1) Precondition 2) Postcondition Precondition defines whether the operation is valid or not and Postcondition defines what happens when an operation has completed its action

7. Example Block Handler  A common part of any operating system which handles the memory blocks  Provides free blocks of memory to new created files and regains blocks when file is removed.  It keeps tracks of free blocks or the unused blocks and the used blocks  Whenever a block is freed, it is added to the queue of unused blocks and similarly whenever a block is needed first block from the queue of unused bock is given for use.

8. Block Handler  Mathematical Definition of state, data invariant and operation for such system will be as follows: 1. State Collection of free blocks, collection of used blocks, and the queue of returned blocks. Mathematically they are defined as used: P Blocks free: P BLOCKS BlockQueue: seq P BLOCKS

9. Block Handler  Data Invariant 1 No block will be marked as both unused and used used П free = 0 2. The collection of used blocks and blocks that are unused will be the total collection of blocks that make up the files used U free = ALLBLOCKS

10. BLOCK Handler  Operations Operation for removing block from the queue  Precondition #BLOCKQUEUE > 0  Postcondition used = used + BLOCKQUEUE blocks(used) free = free – BLOCKQUEUE blocks(used)

11. Selection criteria  Factors that should be taken into consideration while using formal methods are as follows 1. Estimate Cost Formal methods have high start up cost. Training staff, acquisition of support tools and use of contract consultants results in high first time cost 2. Use formalization and not over formalization It is not necessary to apply formal methods to every aspects of a major system. Components that are safety critical should only be built using formal methods

12. Selection criteria 3. Integration It is possible to integrate and in many cases desirable, to integrate formal methods with conventional or object oriented methods. A combination, if properly applied, can produce excellent results 4. Should maintain quality standards SQA activities must continue to be applied as systems are developed

13. Selection criteria 5. One should not be dogmatic Formal methods are not a guarantee of correctness. It is possible that the final system, even when developed using formal methods, may have small omissions, minor bugs, and other attributes that do not meet expectations 6. Test, Test and Test again Formal methods do not absolve the software engineer from the need to conduct well planned, thorough tests

14. Formal Methods14 Formal Clean Room SE

15.  The name is derived from the 'Cleanroom' process in semiconductor fabrication. The philosophy is defect avoidance rather than defect removal.  This software development process is based on:  Incremental development;  Formal specification;  Static verification using correctness arguments;  Statistical testing to determine program reliability. Cleanroom software development

16. The Cleanroom process

17. Cleanroom process characteristics  Formal specification using a state transition model.  Incremental development where the customer prioritises increments.  Structured programming - limited control and abstraction constructs are used in the program.  Static verification using rigorous inspections.  Statistical testing of the system

18. Formal specification and inspections  The state based model is a system specification and the inspection process checks the program against this mode.l  The programming approach is defined so that the correspondence between the model and the system is clear.  Mathematical arguments (not proofs) are used to increase confidence in the inspection process.

19.  Specification team. Responsible for developing and maintaining the system specification.  Development team. Responsible for developing and verifying the software. The software is NOT executed or even compiled during this process.  Certification team. Responsible for developing a set of statistical tests to exercise the software after development. Reliability growth models used to determine when reliability is acceptable. Cleanroom process teams

20.  The results of using the Cleanroom process have been very impressive with few discovered faults in delivered systems.  Independent assessment shows that the process is no more expensive than other approaches.  There were fewer errors than in a 'traditional' development process.  However, the process is not widely used. It is not clear how this approach can be transferred to an environment with less skilled or less motivated software engineers. Cleanroom process evaluation

21. Formal Methods Thanks 21