5.26. KobrA - Vending machine UML diagram
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.
14.1.34. Common Component Modelling
Structural view of the Cash Desk Line component
• This component is an embedded part of the system.
• Its task is to manage all the cash desks, including their hardwares, the collaboration of the cash desks and the connections among cash desks and connected devices.
• The main communication is realized by events sent on event channels.
• The next figure shows the structural overview of the CashDeskLine component.
• CashDeskLine component contains:
• More CashDesk instances,
• an EventBus component,
• and a Coordinator component.
14.1.35. Common Component Modelling
Figure 11. Structural view of the Cash Desk Line component.
14.1.36. Common Component Modelling
EventBus component This component manages the two instances of the EventChannel, those are common for all instances of CashDesk:
• cashDeskChannel
• Used by the CashDesk for the communication with the controllers of the connected devices
• CashDeskApplication, LightDisplayController, etc.
• Each controller is connected to one hardware device
• These form together a bridge between the hardware and the middleware.
• extCommChannel
• CashDeskApplication component writes the information about finished sales into the Inventory component via the extCommChannel.
• Both Coordinator (which manages express cash desk services) and CashDesk components are using this channel.
14.1.37. Common Component Modelling
CashDesk component details
• It can be seen in the previous figure that CashDesk components also handle messages.
• In the figure, half circles mark messages, those can be handled by the component, while circles mark messages, those are sent by the component to other components.
• Example: CardReaderController
• it handles the ExpressModeEnabledEvent event and
• sends the CreditCardScannedEvent and PINEnteredEvent events.
14.1.38. Common Component Modelling
Deployment view of the trading system It discusses, which tools can be used to realize the trading system.
• Each cash desk has an own PC and additional hardware devices connected to that PC.
• Barcode reader or credit card reader
• Controllers of devices are running on the PC and the PC communicates via an event channel with them.
• Each supermarket has a Store Server
• All the PCs in the supermarket are connected to this server
• The server component consists of four additional components: Coordinator, extCommChannel, Application and Data.
14.1.39. Common Component Modelling
Physical placement of the components (e.g. hardware)
Figure 12. Deployment view
14.1.40. Common Component Modelling
Behavioral model
• A more formal description of each use case by a modeling tool.
• In this case, using UML 2.0 sequence diagrams.
14.1.41. Common Component Modelling
Behavioral view of the trading system
• In this case the behavioral view of the system is given with the sequence diagrams of the use cases.
• The following notations are used on sequence diagrams:
• Filled headed arrow marks a synchronous method call,
• Non-filled headed arrow marks an asynchronously called method.
• The collaboration of the actors and components are described with sequence diagrams.
14.1.42. Common Component Modelling
Behavioral view of UC 1 use case The sequence diagram of use case Sale Process (UC 1) is shown in the following three figures.
• In the sequence diagram of the main process (sd UC 1: Process Sale) the followings are shown
• the cashier and additional
• software components
• CashBox
• CashBoxController
• CashDeskApplication
• PrinterController
• ScannerController
• CashDeskGUI
• Inventory
• BarCodeScanner
14.1.43. Common Component Modelling
Figure 13. Behavioral view of Process Sale (UC 1) use case.
14.1.44. Common Component Modelling
Main process: sd UC 1: Process Sale Activites of the main process:
• Cashier pushes the Start new sale button, and then
• the initialization of a new sale happens and
• the printer prints the header of the new sale onto the bill.
• The cashier uses the bar code reader to read the bar codes of each items, and based on this
• the Inventory component gives the proper data of the product to the CashDeskApplication and then the new item is added to invoice.
• This step is repeated until all the bought items are processed and the cashier pushes the Sale Finished button.
• Customer can pay with
• Cash
• Sd UC 1: ProcessSale:CashPayment
• Credit card
• Sd UC 1: ProcessCardPayment.
14.1.45. Common Component Modelling
Figure 14. UC 1 pay with cash.
14.1.46. Common Component Modelling
Figure 15. UC 1 pay with credit card.
14.1.47. Common Component Modelling
Behavioral view of UC 5 use case
• UC 5 Show Stock reports
• The manager of the supermarket can ask information about which items are low on stock.
• A manager can use the Reporting service of the GUI component to generate the list, by providing the identifier of the supermarket and pressing the CreateReport button.
• Then the getStockReport() service of the GUI::Reporting component gets the required information from the Data::Store component and generates the list, as can be seen in the next figure.
• The result is a ReportTO object, and it sends this object to the GUI::Reporting component, where the manager can see the result.
14.1.48. Common Component Modelling
Figure 16. UC 5 Show Stock reports.
14.1.48.1. 14.1.1.4 Implementation
14.1.49. Common Component Modelling
Implementation
• The trading system is implemented in Java language.
• Each component corresponds to a Java package.
• From outside, only the interfaces of the embedded components are public.
• Classes implementing the interfaces can be found in the impl subpackage.
14.1.50. Common Component Modelling
Figure 17. Implementation.
14.1.50.1. 14.1.1.5 System test
14.1.51. Common Component Modelling
System testing
• The test framework has two tasks:
• provides more information about some aspects of the system,
• teams modelling different system parts have the opportunity to automatically test their implementations.
• To reach the goal above, the JUnit test framework was used in the project and also during the test scenarios creation.
• The created test framework contains more layers, as can be seen in the next figure.
• A common test interface is used for testing, which is realized by test drivers.
• Test scenarios are realized through these interfaces.
• It is enough to create only the corresponding test driver to run the test on a newly created system part.
14.1.52. Common Component Modelling
Figure 18. Architecture of the testing framework.
14.1.53. Common Component Modelling
Test scenarios
• Test scenarios are based here on the use cases of the trading system.
• Test scenarios can be given in two ways
• in formal Java classes
• testing is automatic using JUnit,
• informally described
• testing is done manually, e.g. use case 5.
• The next tables contain the use case identifiers and the corresponding test case identifier, the type of testing and a short description.
• For formalized test cases, JUnit gives the test result based on the source code, while it gives "pass" or "fail" in informal cases.
14.1.54. Common Component Modelling
Table 1. Some more concrete test cases.
14.1.55. Common Component Modelling
Table 2. Some more concrete test cases.
14.1.56. Common Component Modelling
Table 3. Some more concrete test cases.
14.1.57. Common Component Modelling
Table 4. Some more concrete test cases.
14.1.58. 14.1.2 Literatures
14.1.59. Common Component Modelling
Recommended literatures
• Larman, C. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition). Prentice Hall PTR 2004.
• OMG, Object Management Group UML Profile for Schedulability, Performance and Time.
http://www.omg.org/cgi-bin/doc?formal/2005-01-02 2005.
• Sun Microsystems The Java Database Connectivity (JDBC).
http://java.sun.com/javase/technologies/database/index.jsp
• JBoss (Red Hat Middleware): Hibernate http://www.hibernate.org
14.1.60. Common Component Modelling
Recommended literatures
• Sun Microsystems Java Persistence API http://java.sun.com/javaee/technologies/persistence.jsp
• Sun Microsystems Java Message Service http://java.sun.com/products/jms/
• Apache The Apache Ant Project http://ant.apache.org
• JUnit JUnit http://www.junit.org