1. Requirements Engineering Methods for Requirements Engineering Lecture-31

2. Recap  No ideal requirements method  System models can be considerably enriched by combining different techniques  Data-flow model is based on the notion that systems can be modelled as a set of interacting functions  The object-oriented approach is based on the notion that systems can be modelled as a set of interacting objects  Formal methods are based on mathematical principles and are intended to achieve a high degree of confidence that a system will conform to its specifications

3. Library Management System Using Structured Method 3

4. Library Management System using Object Oriented Method 4

5. Library Management System using Formal Method 5

6. Today’s lecture 6  Formal methods for requirement engineering

7. Why we need formal methods?  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

8. Formal methods  Formal methods are mathematically based.  They are an attempt to deal with contradictions, ambiguities, vagueness, incomplete statements, and mixed levels of abstraction.  They are most valuable for systems which have:  safety concerns (e.g., airplane systems, medical devices)  security concerns

9. Formal Methods Concepts Formal Specification Methods Formal specification Formal Proofs Model checking Abstraction

10. Formal Specification  The translation of non-mathematical description (diagrams, table, natural language) into a formal specification language  It represents a concise description of high-level behavior and properties of a system  Well-defined language semantics support formal deduction about the specification

11. Type of Formal Specifications  Model Oriented: Construct a model of the system behavior using mathematical objects like sets, sequences etc.  State charts, Z  Petri Nets, Automata theoretic models  Property Oriented: Use a set of necessary properties to describe system behavior, such as axioms, rules etc.  Algebraic semantics  Temporal logic models.

12. Formal Proofs  Proof is an essential part of specification  Proofs are constructed as a series of small steps, each of which is justified using a small set of rules  Proofs can be done manually, but usually constructed with some automated assistance

13. Model Checking  A technique relies on building a finite model of a system and checking that a desired property holds in that model  Two general approaches  temporal model checking  automaton model checking  Use model checkers  SMV

14. Abstraction  Representation of the program using a smaller model  Allows you to focus on the most important central properties and characteristics  Getting the right level of abstraction is very important in a specification.

15. Formal methods  Formal methods can be used to:  Mathematically PROVE correctness of a system  Reduce faults  Formal methods can provide:  program specification: define program is supposed to do  program verification: PROVE program does what the specification says it will do  automated theorem proving  model checking: exhaustively check all possible “states” of the model that has been developed

16. "Ten Commandments" of formal methods  Choose the appropriate notation  Formalize but don't over-formalize  Estimate costs  Have a formal methods "guru" on call  Do not abandon traditional development methods  Document sufficiently  Don't compromise quality standards  Do not be dogmatic  Test, test, test, ….  Reuse

17. Some definitions  State: A state is the stored data that a system accesses and alter.  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.

18. Some definitions (cont…)  Operation is defined as action that takes place in a system and reads or writes data to a state  It is associated with two type of conditions  Precondition defines whether the operation is valid or not  Postcondition defines what happens when an operation has completed its action

19. 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.

20. 20 “Block Handler” 1 3 4 6 9 2 5 7 8 10 11 12 25 8 117 Unused (free) blocks Queued for entry into Unused Blocks released to queue when files deleted Used blocks

21.  Can we identify the states?  What are the data invariants?  What are the operations?

22. States  The collection of used blocks  The collection of free blocks  The queue of returned blocks

23. Data invariants  No block will be marked as both unused and used  All the sets of blocks held in the queue will be subsets of the collection of currently used blocks  No elements of the queue will contain the same block umbers  The collection of used blocks and blocks that are unused will be the total collection of blocks that make up files  The collection of unused blocks will have no duplicate block numbers  The collection of used blocks will have no duplication block numbers

24. Operations  Adding  Removing

25. 25 Z specification: -------BlockHandler---------------------- used,free:  BLOCKS BlockQueue: seq P BLOCKS ----------------------------------------------- used  free =   used  free = AllBlocks   i: dom BlockQueue. BlockQueue i  used   i,j : dom BlockQueue. i  j  BlockQueue i  BlockQueue j =  set contained in and implies “then” in intersection for all empty set intersection union sequence 1 3 4 6 9 2 5 7 8 10 11 12 25 8 117

26. 26 ---------RemoveBlock--------------------------  BlockHandler ----------------------------------------------------- #BlockQueue > 0, used’ = used \ head BlockQueue  free’ = free  head BlockQueue  BlockQueue’ = tail BlockQueue ------------------------------------------------------ ---------AddBlock-------------------------------  BlockHandler Ablocks? : BLOCKS ----------------------------------------------------- Ablocks?  used, used’ = used  free’ = free  BlockQueue’ = BlockQueue ^ (Ablocks?) ------------------------------------------------------ 1 3 4 6 9 2 5 7 8 10 11 12 25 8 117