5.26. KobrA - Vending machine UML diagram
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 CashDeskLine component is connected the bank via the BankIf interface, which's task is to handle the credit card payment mode. The component keeps the connection with the bank via a port.
14.1.21. Common Component Modelling
Figure 4. TradingSystem Inventory component architecture
14.1.22. Common Component Modelling
The structure of the Inventory component
• The previous figure shows the internal architecture of the Inventory component, which represents the information system of the trading system.
• The architecture is built from the following layers:
• GUI,
• Application,
• Data,
• Database.
• For each Inventory component instance, only one Database instance exists.
• The Data layer is a classic three layered architecture, and its details will be discussed later.
• The communication between the Database and Data layers managed by JDBC.
• The Data component connects via three interfaces to the Application layer (EnterpriseQueryIf, StoreQueryIf, PersistenceIf).
14.1.23. Common Component Modelling
Figure 5. TradingSystem Inventory component architecture
14.1.24. Common Component Modelling
The structure of the Inventory component
• EnterpriseQueryIf interface contains queries about the company operation.
• StoreQueryIf defines methods for the supermarkets
• to change item prices,
• to manage the Inventory
• etc.
• PersistenceIf
• provides a method to query persistent relations.
14.1.25. Common Component Modelling
The structure of the Inventory component
• The Application component contains the application logic.
• It uses the interfaces of the Data component to send queries and modification to the Database.
• It defines the StoreIf and ReportingIf interfaces for the GUI component, so the application layer can send the database query results through them to the GUI layer.
• Between the application and GUI layers (components) data are sent using Transfer Objects (TO) instead of passing references.
14.1.26. Common Component Modelling
Data layer
• The following figure shows the Data layer, which consists of three subcomponents:
• Enterprise,
• Persistence,
• Store.
• The task of these components is to realize the EnterpriseIf, StoreQueryIf and PersistenceIf interfaces.
• The data model of the trading system gives a detailed overview about the data model, which is extended with attributes and navigation paths.
14.1.27. Common Component Modelling
Figure 6. Internal structure of the Inventory component's data layer.
14.1.28. Common Component Modelling
Figure 7. Data model of the Trading System.
14.1.29. Common Component Modelling
Application layer
• The application layer consists of three components:
• Reporting,
• Store,
• ProductDispatcher.
• The Reporting component realizes the ReportingIf interface.
• The Store component realizes the CashDeskConnectorIf and StoreIf interfaces.
• The required interfaces of the Store component are SaleRegisteredEvent and ProductDispatcherIf.
• ProductDispatcher defines a method for the Enterprise Server, which searches products in other supermarkets.
• The communication between the Data and the Application is realized so that Data passes references of persistent objects to the Application component.
• The Application layer uses Transfer Objects (TO) to pass information to GUI and CashDeskLine components.
14.1.30. Common Component Modelling
Figure 8. Internal structure of the application layer of the Inventory component.
14.1.31. Common Component Modelling
Figure 9. Transfer Objects realizing data exchanges between the application and GUI layers.
14.1.32. Common Component Modelling
Application layer
• The internal structure of the GUI layer of the Inventory component is shown on the next figure.
• Reporting
• This component realizes the visualization of the reports. The data for the visualization is taken through the ReportingIf interface.
• Store
• This component provides user interface for the Store Manager, so itcan manage ordering products or changing the sale prices, etc. tasks.
14.1.33. Common Component Modelling
Figure 10. Internal structure of the GUI layer of the Inventory component.
Figure 10. Internal structure of the GUI layer of the Inventory component.