1. Software Engineering 2
-Prakash Shrestha

2. Chapter 25 Formal Modeling and Verification Methods

3. 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)

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

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

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

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

8. Cleanroom SE - contd.. Formal Design: Correctness Verification:
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).

9. 2. Formal Methods Data invariant: State: Operation:
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

10. An Example: Block Handler
Filing Subsystem Block handler.
Unused Blocks
1, 3, 4, 6, 9
Used blocks
2, 5, 7, 8, 10, 11, 12
Queued for entry into Unused Blocks
Blocks are released to queue when files are deleted 2
5, 8, 11 7
File 1
File 3
File 2

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

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

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

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

15. Formal Specification Languages
OCL (Object Constraint Language): operated in objects like in object-oriented programming.
Z-Specification Language

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