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