software engineering 2 -prakash shrestha. chapter 25 formal modeling and verification methods

Software Engineering 2

-Prakash Shrestha

Chapter 25

Formal Modeling and Verification Methods

What is Formal Modeling?• Mathematical Approach to model the program

and verify that the model is correct.• Used where there are vague and ambiguous

requirements, which are hard to state or model.• Uses Mathematical Verification of Correctness

(Cleanroom SE) and set theory and logic notation to state requirements (Formal Methods)

Why Formal Modeling?• Because Conventional Modeling & Specification

(Which generally are in plain English Language and/or Modeled in UML Diagrams) have:– contradictions– ambiguities– vagueness– imcompleteness– mixed levels of abstraction

Why Formal Modeling? Contd..• “Do it right the first time”: Less effort, Less

rework.• Less Mistakes: saves time and cost. V&V in each

steps requires normally a lot of time and cost.• Dramatically Reduce the bugs from the scratch.

Two Formal Modeling Methods• Cleanroom Software Engineering– Requires insurance of the correctness of the software as it is being

developed.– Instead of classic SDLC, it uses specialized version of Incremental

Model.– Uses Box Structure to describe/model the requirements.

• Formal Methods– Mathematical (Set Notations) to describe the system properties

(Requirements).– Mathematical Notations are consistent, complete and almost

non-ambiguous.

1. Cleanroom Software Engineering

• Pipeline Incremental Model involving:– Increment Planning• Plan to adopt Incremental Strategy.

– Requirements Gathering• Conventional Requirements Collection Techniques.

– Box Structure Specification• Makes Use of Box Structures:

– Black Box : specifies the behaviour– State Box: encapsulates state data & operations.– Clear Box: defines the transition functions.

Cleanroom SE - contd..• Formal Design:– Design/Model using box structure approach, with boxes

iteratively refined (as increments).

• Correctness Verification:– Verification conducted in every box structures, that of all

increments.

• Code Generation, Inspection and Verification• Statistical Test Planning/Testing• Certification: – Every increments, after verification and Testing, certified as

ready for integration. (No need to validate: save time & Cost).

2. Formal Methods• Data invariant:– a condition that is true throughout the execution of the system that

contains a collection of data

• State:– the stored data which a system accesses and alters

• Operation:– an action that takes place in a system and reads or writes data to a

state

• precondition defines the circumstances in which a particular operation is valid

• postcondition defines what happens when an operation has completed its action

An Example: Block Handler• Filing Subsystem Block handler.

1, 3, 4, 6, 9

2, 5, 7, 8, 10, 11, 12

2 5, 8, 11 7

Unused Blocks

Used blocks

Queued for entry into Unused BlocksBlocks are released to queue when files are deleted

File 1 File 2 File 3

Data Invariant• No block will be marked as both unused and used.• All sets of blocks held in the queue are subsets of the

collection of currently used blocks.• No elements of the queue will contain the same block

numbers.• The collection of used and unused blocks is the total

collection of the blocks that make up files.• The collection of unused blocks will have no duplicate

block numbers.• The collection of used blocks will have no duplicate

block numbers.

Operations• Add(): add to the queue• Remove(): from the queue and place in unused.• Check(): whether the queue of blocks is empty

Pre-condition and Post-condition• Add():– Precondition: All the blocks to be added must be in

the collection of used blocks.– Postcondition: The blocks are now found at the end

of queue. (LIFO).• Remove():– Precondition: queue must have at least one item.– Postcondition: must be added to the unused blocks.

• check():– No Precondition– Postcondition: true if queue empty, false otherwise.

Mathematical Notations• sets and constructive set specification• set operators• logic operators– e.g., i, j: • i > j i2 => j2

– which states that, for every pair of values in the set of natural numbers, if i is greater than j, then i2 is greater than j2.

• sequences

Formal Specification Languages

• OCL (Object Constraint Language): operated in objects like in object-oriented programming.

• Z-Specification Language

The Z Language

• organized into schemas– defines variables– establishes relationships between

variables– the analog for a “module” in

conventional languages• notation described in Table 25.1,

SEPA, 5/e