Requirements Engineering Methods for Requirements Engineering Lecture-31

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

Library Management System Using Structured Method 3

Library Management System using Object Oriented Method 4

Library Management System using Formal Method 5

Today’s lecture 6  Formal methods for requirement engineering

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

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

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

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

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.

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

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

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.

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

"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

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.

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

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 “Block Handler” Unused (free) blocks Queued for entry into Unused Blocks released to queue when files deleted Used blocks

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

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

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

Operations  Adding  Removing

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

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?)