5.26. KobrA - Vending machine UML diagram
13.1.24. MODULE prc - cont
13.1.25. Model checking
Result of SMV As SMV is performed on main and prc modules, we have the result that mutual exclusion is satisfied:
SPEC G !(s0 = critical s1 = critical) is true
and the system is guaranteed starvation-free:
SPEC G ((s0 = trying) F ((s0 = critical)) is true SPEC G ((s1 = trying) F ((s1 = critical)) is true
13.1.26. 13.1.8 A model of parallel computation 13.1.27. Model checking
A model of parallel computation
• The model of parallel computation
• A P = P || ... || P concurrent program consists of a finite number of parallel executed P ,..., P sequential processes.
• The synchronization of a P process is a state machine, which is represented by a directed graph.
• All edges of the graph are labeled with a B A synchronization statement, where B is a guard (condition) and A indicates an activity.
• Such systems can be described with temporal logic formulas.
• Computation Tree Logic* (CTL*) is a kind of it.
13.1.28. Model checking
Computation Tree Logic*
• Computation Tree Logic* is a propositional branching-time temporal logic.
• The specification input of model checkers are often given by CTL or CTL* formulas.
• CTL* is an extension of the Computation Tree Logic (CTL).
13.1.29. Model checking
Syntax of CTL*
• (S1) All atomic proposition is a state formula;
• (S2) if are state formulas, then , are state formulas;
• (S3) if is a path formula, then and are state formulas.
• (P1) All state formula is a path formula;
• (P2) if are path formulas, then , are path formulas;
• (P3) if are path formulas, then , are state formulas.
13.1.30. Model checking
Modalities
• Path quantifiers
• Intuitive meaning of : a maximal path exists where is satisfied.
• Intuitive meaning of : is satisfied for all paths.
• Linear-time modalities
• G (always)
• F (sometime or eventually)
• (strong nexttime): formula is satisfied in a state on a maximal path, if executing the next atomic activity of process, is satisfied in all state, which can be reached directly from state .
• Y (weak nexttime)
• formula is satisfied on a maximal path in a state, if such state exists on the maximal path so that is satisfied in and is satisfied in all states till , but is not necessary satisfied in .
13.1.31. Model checking
Semantic of CTL*
• Let , where
• is a finite set of states. Each state is a projection, which projects the set of atomic propositions to the set .
• is a binary relation, which defines the transitions of the sequentional process .
• Let .
• A is a sequence of states ( ), where .
• A is a maximal path. A fullpath is an infinite sequence ( ), except if an state exists, which does not have any (following) state, where .
13.1.32. Model checking
Notations
• is a full path, is a suffix.
• means: is true in structure in state .
• means: is true in structure on fullpath .
• means: is true in structure in states.
13.1.33. Model checking
Semantic - 1.
• if
• if and if not( )
• if such fullpath exists in structure that ; if
is true for all fullpath in structure .
13.1.34. Model checking
Semantic - 2.
• if
• if and if not( )
• if is defined and and if exists
so that and .
13.1.35. Model checking
Notations represents that is valid, so it is true in all states of all structures.
13.1.36. 13.1.9 Combination of model checkers and testing 13.1.37. Model checking
Combination of model checkers and testing
• It is important to check the correctness of our software as soon as possible.
• We can validate the use case models also with e.g. model checkers.
• In this case, we can construct based on the use case diagram
• the specification defines the required properties,
• Using temporal logic formulas.
• the high-level model of the system.
• In special modeling language.
• In our case, this tool is the NuSMV model checker. The specification is provided in CTL formulas, while the model of the system is given in the modeling language of NuSMV.
• In following, use case description of Purchase Item will be introduced and later the model and the specification will be defined for NuSMV.
13.1.38. 13.1.10 Example
13.1.39. Component-Based software development
Use Case description (1)
• Use Case 1: Purchase Item
• Goal in Context: Main scenario for purchasing an item from the vending machine.
• Actors: User.
• Trigger: User inserts coins into slot, or selects item on button panel.
• Preconditions: Vending machine is operational.
• Postconditions on Success: Item is provided.
• Postconditions on Failure: Item is not provided.
• Description Basic Course:
1. User inserts suficient amount of money.
2. User selects item on panel.
3. Selected item and return money are dispensed.
4. User takes item and returned money, if applicable.
13.1.40. Component-Based software development
Use Case description (2)
• Description Alternative Courses:
1. User selects item.
2. Vending machine displays price.
3. basic course
• Exceptions:
1. [insuficient amount] user inserts more cash, or aborts.
2. [selected item not available] user selects different item, or aborts.
• Non-functional Requirements:
1. Item should be dispensed not more than 3 seconds after selection.
2. After 3 sec of no user selection use case is aborted and inserted cash returned.
• Extensions: <left open>
• Concurrent Uses: <left open>
• Revisions: <left open>
13.1.41. The model and the specification in NuSMV
13.1.42. Model checking
Result of model checker
• Executing the NuSMV model checker, we get the result that the model is correct to the specification, so
• system can go from idle state to insertcoin state and
• from insertcoin state, system can go in finite time to takeitem state, or into abort state. From these states system should go always to the idle state.
• In this case, system is checked on a very high abstraction level. We did not answer the question that what situation can cause that system goes into takeitem or abort state. The matter at this level is that these kind of transitions can happen according to the user requirements.