software engineering 2 -prakash shrestha. chapter 25 formal modeling and verification methods
TRANSCRIPT
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