5.26. KobrA - Vending machine UML diagram
12.2.1. Counter-example
Table 1. A counter-example for a small interlocking.
12.2.2. Counter-example
Figure 1. A small track layout.
12.2.3. Counter-example
Table 2. A small signal control table.
12.2.4. Counter-example
Figure 2. An example of track segments for track 8B.
12.2.5. Counter-example
Table 3. Template of the interpreted output of a counter-example.
12.2.6. Counter-example
L. van den Berg et al. Electronic Notes in Theoretical Computer Science 174 (2007) 19-35
Table 4. Template of the interpreted output in which a point is set incorrectly.
12.2.7. Counter-example
Table 5. Template of the interpreted output in which a point moves while the train is in-route.
12.2.8. Counter-example
Table 6. Example of the output produced when a point is set incorrectly.
12.2.9. Counter-example
Table 7. Example of the output produced when a point moves while the train is in-route.
12.2.10. Counter-example
Table 8. Template of the interpreted output for the opplock counter-example.
12.2.11. Counter-example
Table 9. Example of the interpreted output for the opplock counter-example.
12.2.12. Counter-example
Table 10. Template of the interpreted output for the diffpath counter-example.
12.2.13. Counter-example
Table 11. Example of the interpreted output for the diffpath counter-example.
12.2.14. Counter-example
Table 12. Template of the interpreted output for the somepath counter-example.
12.2.15. Counter-example
Table 13. Example of the interpreted output for the somepath counter-example.
12.2.16. Counter-example
Table 14. Results of evaluation
13. 13 Model checkers
13.1. 13.1 Model checkers
13.1.1. 13.1.1 Component-based software technology 13.1.2. Model checkers
Component-based software technology
• Main goals:
• Reusability
• Evolution
• Reliability
• Required preconditions:
• Component-library
• Component-model
• CORBA (CCM)
• Microsoft (COM+/.NET)
• Java (EJB)
• Software-architecture
13.1.3. 13.1.2 Component-based software development 13.1.4. Model checkers
Component-based Software Development (CBSD)
• In ideal case, CBSD is not more than composing a system from components.
• The problem is that the development platform of a component is usually not the same as the platform of the system where the component will be used. We have to do an integration check on the created system.
13.1.5. 13.1.3 Contracts 13.1.6. Model checkers
Contracts
• A possible solution, if the validation information is built in the component and exists not till the end of the development, but all the time.
• Contracts are used here to fix the rights and obligations in a client-server structure.
• Component can check, whether it can work together with its new "colleagues", while the environment can also check whether it accepts or not the "newcomer".
13.1.7. Model checkers
Type of contracts
• Basic contracts, syntactic contracts.
• Behavioral contracts - describe the global functionality of a component
• Synchronization contracts
• Quantitative contracts or quality-of-service contracts
• ...
13.1.8. Model checkers
Built-in contracts
• We can build the contracts into the components so they can be turned on/activated whenever the component is reusaged.
• We test the component in the new environment with the current contracts.
• If test shows that our component works fine in the new environment then we can turn of contracts to improve the efficiency.
• If efficiency criterias let it so, then contracts may be left turned on for the whole life-cycle of the component.
• Further details of the contract's usage are beyond our topic.
13.1.9. Model checkers
Figure 1. The static model of a framework.
13.1.10. 13.1.4 Verified components 13.1.11. Verified components
Verification procedures
• Correctness proof, behavioral analysis
• Program synthesis
• Model checking
• Testing
13.1.12. A component, that realizes mutual exclusion
Let the structure of the two concurrent processes the following:
13.1.13. 13.1.5 Peterson's method
13.1.14. Peterson's method (1981) - First process
Use flag1, flag2 and turn shared variables
13.1.15. Peterson's method - Second process
13.1.16. 13.1.6 Correctness 13.1.17. Model checking
Correctness
• Doing behavioral analysis on the component, which consists of two processes and realizes the mutual exclusion, we can find that the component satisfies both safetyness and liveness properties.
• Problem: The corresponding formal methods required by the proof are missing. Because of the large amount of possible execution paths, behavioral analysis is less useful.
13.1.18. Model checking
Model checking
• A completely automatic method to check the correctness of finite state systems.
• Using a given model checking tool, user should provide
• The specification, which describes the required properties
• with temporal logic formulas
• A higher level model of the system being designed
• in a special modeling language
• Model checker analyses all state transitions of the model for all inputs.
• It returns true, if the analysed model satisfies the required properties.
• If the answer is false, then it gives the execution sequence, which violates a required properties.
13.1.19. Model checking
Model checking
• In some cases, non-finite state system can be checked also, but it requires several abstraction and inductive assumptions.
• Temporal logics used for specification can guarantee that we can also analyse the behaviors of concurrent systems.
• The most problematic is the "explosion" of the state space when we use model checkers, but several methods are existing to solve this problem.
• Binary decision trees (BDT)
• Symbolic model checking
• Partial ordering based reduction
• Open incremental model checking
13.1.20. 13.1.7 Symbolic Model Verifier 13.1.21. Model checking
Symbolic Model Verifier (SMV)
• A kind of tool, that can be used to decide that a finite state system satisfies its specification given in language
• CTL (Computational Tree Logic) or
• LTL (Linear Temporal Logic)
• From now G means the Always operator and F means the Eventually operator in LTL formulas.
• Language elements used to describe and create a model of a finite state system:
• Modules
• Synchronous and overlapped compositions
• Non deterministic transitions
• Transition-relations
13.1.22. Model checking
Global specification
13.1.23. MODULE prc(state0, state1, turn, turn0)
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.
13.1.43. Fair and violating behaviour (1)
13.1.44. Model checking
Modification of specification
• Modify the specification of the system in the following way. Prescribe that system should go everytime into takeitem state from insertcoin state.
• partial formula and as an output we also get a counter-example shown in the next figure.
13.1.45. Fair and violating behaviour (2)
13.1.46. Model checking
Using counter-examples
• The model checkers generated counter-examples can be used to define test cases for testing and we can also obtain useful information how to generate test data.
13.1.47. 13.1.11 References 13.1.48. CBSD - Model checkers
References
• Bass, L., Clements, P., Kazmar., R. Software Architecture in Practice (Second Edition). Addison Wesley 2003.
• Clarke, E. M., Jr., Grumberg, O., Peled, D. A. Model Checking. The MIT Press, Cambridge 2000.
• Haus-Gerhard Gross. Component-Based Software Testing with UML. Springer-Verlag Berlin Heidelberg, 2005.
13.1.49. CBSD - Model checkers
References
• McMillan, K. L. Symbolic Model Checking: An Approach to the State Explosion Problem . Kluwer Academic, 1993.
• NuSMV Model Checker. http://nusmv.irst.itc.it
14. 14 Common Component Modeling
14.1. 14.1 Common Component Modelling
CoCoMe Common Component Modelling Example Sebastian Herold and co. Germany: Italy: TU Clausthal, University Karlsruhe, Technische Universitat München; Politechnico di Milano
14.1.1. 14.1.1 Modelling of a trading system 14.1.2. Common Component Modelling
Modelling of a trading system
• A supermarket chain is given, which forms a company
• More supermarkets belong to the company
• In a supermarket, customer can pay at the cash desk for the selected items
• There are more cash desks at a supermarket
• Customers can pay with cash or credit card
• Cashiers are using barcode readers
• Cash registers are connecting to the server of the supermarket and to the bank through it.
14.1.3. Common Component Modelling
Figure 1. Overview
14.1.3.1. 14.1.1.1 Functional Requirements, Use Case Analysis
Functional Requirements and Use Case Analysis
14.1.4. Common Component Modelling
Figure 2. Use cases
14.1.5. Common Component Modelling
Content of the use case template
• Use case template
• Brief Description
• Involved Actors
• Precondition
• Trigger
• Postcondition
• Standard Process
• Alternative or Exceptional Processes
14.1.6. Common Component Modelling
Use case: Sale process (UC 1)
• Brief description
• Sum the cost of products selected by the customer and then customer pays with credit card or cash.
• Involved actors
• Customer, Cashier, Bank, Printer, Card reader, Cash register, Barcode reader, Display
• Precondition
• The cash desk and the cashier are ready to process a new sale.
• Trigger
• A customer arrives to the cash desk and wants to pay for the selected items.
• Postcondition
• The customer paid, got the receipt and selling is registered in the inventory.
14.1.7. Common Component Modelling
Standard Process (UC 1)
1. The Customer arrives at the Cash Desk with goods to purchase. [arr1]
2. The Cashier starts a new sale by pressing the button Start New Sale at the Cash Box. [t12-1]
3. The Cashier enters the item identifier. This can be done manually by using the keyboard of the Cash Box.
[p13-1, t13-1] or by using the Bar Code Scanner. [p13-2, t13-2]
4. Using the item identifier the System presents the corresponding product description, price, and running total.
[t14-1]
The steps 3-4 are repeated until all items are registered.
14.1.8. Common Component Modelling
Standard Process - 2 (UC 1)
1. Denoting the end of entering items the Cashier presses the button Sale Finished at the Cash Box.
a. To initiate cash payment the Cashier presses the button Cash Payment at the Cash Box.
i. The Customer hands over the money for payment.
ii. The Cashier enters the received cash using the Cash Box and confirms this by pressing Enter.
iii. The Cash Box opens.
iv. The received money and the change amount are displayed and the Cashier hands over the change.
v. The Cashier closes the Cash Box.
14.1.9. Common Component Modelling
Standard Process - 3 (UC 1)
1.
a. In order to initiate card payment the Cashier presses the button Card Payment at the Cash Box
i. The Cashier receives the credit card from the Customer and pulls it through the Card Reader.
ii. The customer enters his PIN using the keyboard of the card reader and waits for validation. The step 5.b.ii is repeated until a successful validation or the Cashier presses the button for cash payment.
14.1.10. Common Component Modelling
Standard Process - 4 (UC 1)
1. Completed sales are logged by the Trading System and sale information are sent to the Inventory in order to update the stock.
2. The Printer writes the receipt and the Cashier hands it out to the Customer.
3. The customer leaves the Cash Desk with receipt and goods.
14.1.11. Common Component Modelling
Alternative or Exceptional Process (UC 1) In step 3: Invalid item identifier if the system cannot find it in the Inventory.
1. The System signals error and rejects this entry.
2. The Cashier can respond to the error as follows:
a. It exists a human-readable item identifier:
i. The Cashier manually enters the item identifier.
ii. The System displays the description and price.
b. Otherwise the product item is rejected.
14.1.12. Common Component Modelling
Alternative or Exceptional Process - 2 (UC 1) In step 5.b: Card validation fails.
1. The Cashier and the Customer try again and again.
2. Otherwise the Cashier requires the Customer to pay cash.
In step 6: Inventory not available.
1. The System caches each sale and writes them into the Inventory as soon as it is available again.
14.1.13. Common Component Modelling
Additional use cases Additional use cases can be described similar to the UC1 use cases.
• UC 2 Manage Express Checkout
• If such conditions are met, then cash desk switches automatically to express mode.
• It this case each customer can purchase at most 8 items and must pay with cash.
• ...
• Note: take a look at the usage of Extending Use Cases and Extension point (UC 1 use case is extended with the services of the UC 2 use case).
• UC 3 Order Products
• UC 4 Receive Ordered Products
14.1.14. Common Component Modelling
UC 5 Show Stock Reports
• Brief description
• Store manager may ask to create statistical report about the products in the given store.
• Involved actors
• Store Manager
• Precondition
• The report creator GUI and the Store Client are working
• Trigger
• The Store Manager wants to see the statistical information of the store.
• Postcondition
• Report was created and displayed
• Standard process
1. The Store Manager enters the identifier of the store and presses the Create Report button.
2. The full list of products in the store's inventory is shown.
14.1.15. Common Component Modelling
Additional use cases - 2.
• UC 6 Show Delivery Reports
• The Trading System provides the opportunity to calculate the mean times a delivery from each supplier to a considered enterprise takes.
• UC 7 Change Price
• The Trading System provides the opportunity to change the sales price for a product.
• UC 8 Product Exchange (on low stock) Among Stores
• If a store runs out of a certain product, it is possible to start a query whether those products are available at other Stores of the Enterprise. After a successful query the critical product can be shipped from one to other Stores. defining those places in the concrete use case templates, where the given property is significant.
• These properties serve as a guideline, when our system is analysed considering several quality aspects.
• Some properties:
• Timing
• Reliability
• Usage profile related information.
• The next slide shows a part of such table according to the UC 1 use case. For the other use cases, newer and newer functional properties can be introduced.
• The authors used the language found in OMG UML Profile for Schedulability, Performance, and Time material to describe the tables.
14.1.17. Common Component Modelling
A part of such extra-functional properties table
• UC 1 Process Sale
• arr1: Customer arrival rate per store: given value
• t12-1: Time for pressing buttom "Start New Sale": given value
• t13-1: Time for scanning an item: given by histogram
• t13-2: Time for manual entry: given value
• t14-1: Time for showing the product description, price, and running total: given value
• p13-1: Probability of using the bar code scanner per item: 0.99
• pt13-2: Probability of manual entry per item: 0.01
• ...
• The complete table contains 37 items to the UC 1 use case.
• Tables to the other use cases can be constructed similarly.
14.1.17.1. 14.1.1.3 Trading System's architecture
The architecture of the Trading System
14.1.18. Common Component Modelling
The structure of the Trading System
• Next figure shows the TradingSystem supercomponent, which consists of the following two components:
• Inventory
• component represents the information system,
• CashDeskLine
• represents the embedded system.
14.1.19. Common Component Modelling
Inventory Information System - with partial structure Cash Desk Line Embedded systems on a bus architecture
Figure 3. TradingSystem
14.1.20. Common Component Modelling
The Trading System super component
• The TradingSystem supercomponent consists of one instance of each above components, and this fact is noted with number 1 in the left top corner of the components.
• Communications among the two components are handled by the following two interfaces
• CashDeskConnectorIf
• defines a method, with we can obtain information about the product by its identifier: description, price;
• SaleRegisteredEvent
• The event interface in this case registers a beginning of a new sale on an asynchronous channel.
• The event interface in this case registers a beginning of a new sale on an asynchronous channel.