Organic Presentation
Organic Presentation
Model
NT) ING
NO
checking
approach SPECIFICATION
• A model-checking tool accepts system requirements or design (called models ) and a property
(called specification ) that the final system is expected to satisfy. The tool then outputs yes if the given
model satisfies given specifications and generates a counterexample otherwise.
• The counterexample details why the model doesn’t satisfy the specification. By studying the
counterexample, you can pinpoint the source of the error in the model, correct the model, and try again.
The idea is that by ensuring that the model satisfies enough system properties, we increase our
confidence in the correctness of the model. The system requirements are called models because they
represent requirements or design.
argument. Consider the following statement: If a food is a
fruit, then it is an apple. Now, consider this statement:
Mango is a food. It is a fruit, but it is not an apple. Therefore,
the mango is the counterexample , thereby making the first
statement invalid.
• Counterexamples are used in math to contradict a
statement.
Counterexamples are used to prove the limitations of possible
theorems.
• Consider a simple pumping control system that
transfers water from a source tank A into another
sink tank B using a pump P.
• Each tank has two level-meters: one to detect
whether its level is empty and the other to detect
whether its level is full.
• The tank level is ok if it’s neither empty nor full; in
other words, if it’s above the empty mark but below
the full mark.
• Initially, both tanks are empty. The pump is to be
switched on as soon as the water level in tank A
reaches ok (from empty), provided that tank B is
not full.
• The pump remains on as long as tank A is not empty and as long as tank B is not full.
• The pump is to be switched off as soon as either tank A becomes empty or tank B
becomes full.
• The system should not attempt to switch the pump off (on) if it’s already off (on).
5
MODEL CHECKING EXAMPLE
• Consider a ATM system in which we have to design a
function for withdrawal of money say withdraw().
• This function, following requirements need to be satisfies-
1.The user must have a positive balance in their account in
order to withdraw money.
2.The user cannot withdraw more money than they have in
their account.
3.The user’s balance must be updated after each
withdrawal.
• Before actually executing the code, we can use model
checking technique to verify that the withdraw() function,
• We must specify the above requirements as properties of
that model. The model checker would explore all possible
• For instance-if there is a negative balance, then
there must not be a path to ‘withdraw amount’
state.
• Similarly if the balance amount greater than the
withdrawal amount then only there should be
path to amount greater than the withdrawal
amount then only there should be a path to
‘withdraw amount’ state.
• If the model checker finds a state in which the
function does not update the user’s balance after
a withdrawal then it should report a bug.
• By identifying this issue in our model, we can
7
locate the corresponding code in our software and