Department of Computer Science Department of Computer ScienceThis document brings together the various bits of modelling we have done of the Scanner, fills in some of the gaps and provides some additional examples of object-oriented modelling and the use of UML. We aim to get to the stage where we can write some class interfaces in an OO language (such as Delphi's Object Pascal).
Use Cases
We consider three use cases:
Other Use Cases not considered here are UnScan Item and Return Scanner To Panel, and possible superuser operations (Transfer the contents of one Scanner to another, Reset a Scanner, etc.)
Initialise Scanner UseCase
Comment We assume that there is one card reader per Panel, and that the Panel is responsible for getting the Customer information from the Card, contacting the Database to log/retrieve the Customer's details, choosing, and releasing a Scanner, etc. All of this is outside the boundary of our system, which just consists of the Scanner itself.
We probably also need a TimeOut mechanism, so that the Panel resecures the Scanner if it is not removed.
Actors
Panel
Description
Panel chooses Scanner.
Panel writes Customer details from Card to chosen Scanner.
Panel lights Scanner Available indicator.
Panel releases Scanner.
Scan Item Use Case
Comment There are three cases:
1. valid barcode and ProductSpecification with Promotion
Actors
2. valid barcode and ProductSpecification without Promotion.
3. invalid BarCode.
Customer
DBInterface (this is a fudge because Rational Rose won't let us have the Database as a class in one diagram and an Actor in another).Description
Customer points Scanner at Product and presses Scan button.
The barcode is decoded and the database interrogated for Product information.
If the BarCode is valid, the bill total is updated, and displayed along with the Product information (including the Promotion, if any).
If the BarCode is invalid, Scanner informs Customer to seek help if they need it.===========================================
Upload UseCase
Comment This covers what happens at the Checkout. We consider the updating of the Database for stock levels and Customer profile, the printing of the Customer's Bill, the handling of payments etc. to be ouside the scope of this system. Once the Checkout has extracted the information stored in the Scanner, the Scanner can be returned to the Panel.
===========================================Actors
CheckoutDescription
Scanner is connected to Checkout.
Checkout requests and uploads Customer information from Scanner.
Checkout requests and uploads Bill total from Scanner.
Until Inventory is empty,
Checkout requests and uploads next item from Inventory.
Given the classes identified in our initial attempt at the Concept Model, we can produce a Collaboration Diagram for each Use Case. We use the restricted form of the syntax for messages supported by Rose.
Initialise Scanner Collaboration Diagram
One difference introduced here is the distinction between Customer and CustomerCard. Customer is the Actor, external to the system and modelling the real person using the Scanner. CustomerCard is the class corresponding to the information stored in the Scanner about a Customer, obtained from the Card. This requires a change to the Concept Model (shown later).
===========================================
Scan Item Collaboration Diagram
The diagram shows the case where the bar code is valid. It is assumed that if the Product is on Promotion, the Promotion details are retrieved from the Database as part of the ProductSpecification. This suggests two new operations on a ProductSpecification, to test for this and, if appropriate, extract the Promotion:
hasPromotion: Boolean
getPromotion : Promotion
We also have to make decisions here about the relationship between the Scanner and its components (Display and Inventory) and how the Display works. We have decided that Display is a simple device which just displays strings; this means that we need an operation to convert a ProductSpecification to a string. In addition, Inventory is a simple data store, and doesn't know about the Display. This makes Scanner responsible for control of this sequence of operations.
===========================================
Upload Collaboration Diagram
Reset here synchronises retrieval of the Inventory contents. isEmpty and getItem are called repeatedly from Checkout.
================================
Identifying Operations
We can now use the Collaboration Diagrams to identify operations on the classes in the Concept Model. The target class of a message will provide an operation to implement the message, with the same signature. So we can make a list of the operations on a class by inspecting the different diagrams.
| Class | Operation | Source |
| Scanner | setCustomer (c : CustomerCard) | Initialise Scanner |
| getCustomer : CustomerCard | Upload | |
| getTotal : Money | Upload | |
| startScan | Scan Item | |
| updateTotal | Scan Item | |
| Display | show (s : String) | Scan Item |
| Inventory | addItem (p : ProductSpecification) | Scan Item |
| reset | Upload | |
| isEmpty : Boolean | Upload | |
| getItem : ProductSpecification | Upload | |
| Product | scanCode : BarCode | Scan Item |
| ProductSpecification | toString : String | Scan Item |
| hasPromotion : Boolean | Scan Item Collaboration Diagram comments | |
| getPromotion : Promotion | Scan Item Collaboration Diagram comments | |
| Database | isValid (c : BarCode) : Boolean | Scan Item |
| getProduct (c: BarCode) : ProductSpecification |
Scan Item | |
In addition, operations to read the values of attributes may be necessary. This depends on the programming language; some (e.g. Eiffel) allow read access to the attributes of a class, others do not. In Object Pascal, classes have private and public parts: it is usual to declare attributes in the private part, and provide a Set procedure and a Get function in the public part (although there are other possibilities).
We will adopt this approach, and so check that each attribute is accompanied by this pair of operations. Doing this reveals that there is no way of attaching a Promotion to a ProductSpecification; this oversight occurs because creating objects of these classes is not the business of our system.
Additional operations are likely to be needed for those classes used in other systems, notably the Database. Our class for this models only the very limited access to it which the Scanner requires. Operations to maintain the contents of the database would be needed in practice.
We will also need constructor operations for each class, special routines executed when a new object is created.
Last Updated: 14/01/99 by M.Wood@herts.ac.uk
© University of Hertfordshire Higher Education Corporation (1999)
