INFORMATION SYSTEM
Content
COMP-533 Object-Oriented Software Development
Assignment 2
Supermarket - Inventory Control and Purchasing Subsystem
Operation Model and Protocol Model
(10% of final grade)
November 9, 2010
1
Problem Statement
The Supermarket System is a computerized system that automates purchases, sales, delivery, returns, monitoring, inventory control, marketing, payroll, accounting, and security for supermarkets (think Provigo, Loblaws, or Metro). You are to elaborate the Operation Model for the inventory control and purchasing subsystem (IC&P), which helps each store manager to keep track of the products in store, coordinates product deliveries from the common warehouse to the stores, and assists in purchasing products from suppliers.
2
2.1
Informal Description (unchanged)
Sales Subsystem (already developed)
Sales A customer queues at the checkout counter after completing his shopping. The customer places the items in the cart on the conveyor belt. The cashier then scans each item and places it in a bag. For each item, if the item is expired, the system should flash a warning. The cashier then discards the item. The customer can then decide to go get another item, or continue without it. If the barcode is missing on the item, the cashier keys in the product number. If the barcode reader recognizes the code, the price is displayed. For items sold by weight (e.g. fruits and vegetables), the items are placed on the scale and the cashier keys in the code for the product. The customer may have coupons (e.g., 4 for 1, 10% less, $1 off) for some products. The cashier keys in the coupon number, so that the appropriate amount is deducted from the bill. After all the items are scanned, the cashier relays the total to the customer and waits for the payment. The customer can pay by cash, credit or debit card. Problems can arise if the card does not have enough credit or if the debit card PIN is not recognized. Also, a customer can ask for cash-back if he pays by debit card. The cashier only has access to the cash register immediately after a sale has been made. At other times, the register is locked by the system. Delivery At the checkout counter, the customer can choose to have the purchases delivered. The delivery charge is then added to the total. Some discounts may be applicable (e.g. for students). The name of the client, his address and phone number are stored in the system. The purchases are then queued for delivery. On delivery, the customer needs to acknowledge receipt of the goods. Returns An item sold can be returned by a customer within 30 days from the date of purchase. Before accepting the return, it is verified whether the return deadline still holds and also whether the item is in proper condition. However, food products 1
are not accepted for return. The customer has to take the items to the customer service. The service agent then keys in or scans the item code to verify whether the item actually was bought from their store. The item is checked and approved for return. If the customer has the original receipt, he gets refunded in the same form than his original payment. Without receipt, the client receives a gift card.
2.2
Inventory Control and Purchasing Subsystem (what you need to develop)
Inventory Control Inventory control ensures that fresh items are regularly maintained in the store. For each item purchased, the expiry date should be recorded. For items sold by weight, the expiry date is assumed to be the same for all items when a delivery is received from a supplier. If the expiry date of an item equals the current date, the store personnel should be alerted. The employees then take action to remove the expired items from the shelves. If certain items in a store are going to expire soon, the store manager is alerted. The definition of “soon” would vary with the product, e.g. the alert for chocolates can be given a month before, whereas the alert for perishable items like fruits and vegetables can be given 7 days before. If a lot of stock is remaining, then the product can be put on sale (e.g. reduced price or “two-for-one” offers), so that the items are sold before they expire. Since items in the real world can be lost, are destroyed or stolen, there is a need to make sure that the inventory that the system has on file for each product actually corresponds to reality. The employees of the store should therefore investigate the stock periodically, and update the store inventory to reflect reality. Purchasing The supermarket chain has a warehouse in town that is used to store large quantities of the products that the individual stores sell. At the end of each day, the system looks at the inventory of each store. If the stock of a product in a store has fallen below a certain threshold, the warehouse is contacted in order to replenish the store’s stock. All requested products that the warehouse has in stock are shipped together in one shipment to the store that placed the request early next morning. If a product is not in stock, the request for that product is put on hold. The purchase subsystem also handles renewal of warehouse stock by purchasing products from suppliers. The suppliers create accounts with the system by calling the supermarket’s administration. Using a user name and a password, registered suppliers can log into the system at any time to set or update the list of products they offer and at what price. It is possible that some goods are offered by several suppliers. When the stock of a product in the warehouse falls below a certain threshold, the system determines the supplier that currently offers the best deal on the product, and contacts the supplier to place an order that replenishes the warehouse to the maximum capacity. Once the shipment arrives at the warehouse, the account of the supplier is credited with the appropriate amount. The merchandise is tagged with barcodes, if applicable, entered into the system, and any outstanding requests from stores for the received product are immediately fulfilled, if any. At any time, a supplier can withdraw money from the account in the supermarket system by requesting a money transfer to the supplier’s own bank account. Finally, a supplier who does not wish to continue providing products for the supermarket can unregister with the system, in which case all remaining funds are transferred to the supplier’s bank account, and the supplier’s records in the system are deleted.
2.3
Other Subsystems (just for information, i.e. not part of the assignment)
Security Subsystem The security subsystem aims to reduce thefts and other incidents in the stores. A security tag is attached to some products, which is demagnetized after purchase to prevent the security alarms from going on. Cameras are installed in various places in the store to aid in inspection of customer behavior. Marketing Subsystem The marketing subsystem maintains statistics of sales and returns. The goal is to maximize sales by studying customer behavior and psychology. For instance, the statistics gathered by the marketing system can be used to estimate how many items of a product are sold on average per day depending on various parameters (such as time of the year, etc...). This information can then be used to optimize purchasing strategies. 2
*
Supermarket Purchasing SellGoodsTo SupermarketChain
de>>
1 MaintainEnough ItemsInWarehouse
Supplier *
<<
in
<<inclu
clu
de
>>
<<i
>>
ncl
ude
>>
Warehouse Manager
<< in clu de
RegisterSupplier Administration Employee
UpdateSupplier Product
<<include>>
WithdrawSupplier Funds
e> >
UnregisterSupplier <<include>>
i <<
n
d clu
<<i
nclu
de>
>
MaintainEnough ItemsInStore
*
IdentifySupplier UpdateStore Inventory PutExpiringItems OnSale RemoveExpired Items
Warehouse Employee
*
*
*
Store Employee
Bank
StoreManager
Figure 1: Supermarket Purchasing Subsystem Use Case Diagram Payroll Subsystem The payroll subsystem keeps record of the employees, e.g. how many hours they work, and handles payments of salaries.
3
Requirements Elicitation Background Information (Partial) Use Case Model of the Purchasing Subsystem
The Use Case Model of the purchasing subsystem has already been established and is presented in Figure 1. Detailed textual use case templates of 4 selected user goal level use cases are also given below.
RegisterSupplier Use Case
Use Case: Register Supplier Scope: Supermarket Purchasing System Level: User Goal Intention in Context: The intention of the Supplier is to open an account with the supermarket purchasing system. To do this, the supplier contacts an Administrator by phone. Multiplicity: Many Suppliers may be registering at any one time. A Supplier only requests to register once at a given time. Primary Actor: Supplier Facilitator Actor: Administrator Main Success Scenario: Supplier calls Administrator on the phone, providing supplier information details . 1. Administrator instructs System to create a new supplier account, providing supplier information details . 3
2. System informs Administrator of successful creation of the supplier account, providing the username and password. Administrator communicates the username and password to the supplier over the phone. Extensions: 2a. System ascertains that the supplier already has an account with the system. 2a.1 System informs Administrator about situation; use case ends in failure.
Supplier information details include: name, email, bank information
UpdateSupplierProduct Use Case
Use Case: Update Supplier Product Scope: Supermarket Purchasing System Level: User Goal Intention in Context: The intention of the Supplier is to inform the system of a product that he is capable of supplying and the price that he is asking for it. Multiplicity: Many Suppliers may be updating their products simultaneously. A given Supplier updates his products one at the time. Primary Actor: Supplier Main Success Scenario: 1. Supplier identifies with System. 2. Supplier informs System of product he wishes to update, and of price. 3. System informs Supplier of successful update. Extensions: 2a. Identification failed. Use case ends in failure.
IdentifySupplier Use Case
Use Case: IdentifySupplier Scope: Supermarket Purchasing System Level: Subfunction Intention in Context: The intention of the Supplier is to identify him/herself to the System. Multiplicity: Multiple Suppliers can identify themselves simultaneously. Primary Actor: Supplier Main Success Scenario: 1. Supplier provides user name and password to System. 2. System validates username and password. 3. System informs Supplier of successful login. Extensions: 2a. System ascertains that the user name or password is unknown or wrong. 2a.1 System sends error message to Supplier. Use case continues at step 1. 2a.1a. System ascertains that Supplier entered a wrong password for the third time in a row. 2a.1a.1 System informs Supplier that his/her account is now blocked. Use case ends in failure. 2b. System ascertains that the supplier’s account is blocked. 2b.1 System informs Supplier of situation. Use case ends in failure.
MaintainEnoughItemsInWarehouse Use Case
Use Case: MaintainEnoughItemsInWarehouse Scope: Supermarket Purchasing System Level: User Goal Intention in Context: The intention of the WarehouseManager is to make sure that the warehouse has enough items in stock to fulfill potential orders from stores. Multiplicity: Only one instance of this time-triggered use case can execute at a given time. Primary Actor: WarehouseManager Secondary Actor: Supplier, WarehouseEmployee, WarehouseItemScanner Main Success Scenario: Step 1-7 are executed in parallel for each product p whose stock is below the threshold. 4
1. System orders from Supplier that currently offers the best price for product p as much quantity as possible, i.e. enough to fill the warehouse stock for product p to the maximum and to honor all the store orders. 2. Supplier ships product to warehouse. 3. WarehouseEmployee informs System that a shipment of product p (which is sold by-unit) has arrived. Steps 4-6 are repeated for each item of product p included in the shipment. 4. WarehouseEmployee glues a barcode sticker to the item and enters expiry date of item into WarehouseItemScanner. 5. WarehouseItemScanner informs System of barcode and expiry date of item. 6. WarehouseEmployee stocks item in the warehouse. 7. WarehouseEmployee informs System that unloading of the shipment of product p is completed. 8. System informs Supplier that shipment was received. Note: In case there are outstanding orders for product p by stores, the system does the necessary steps to fulfill them (see use case MaintainEnoughItemsInStore). Extensions: 1a. No supplier currently produces product p. 1a.1 System informs WarehouseManager of situation. Use case continues with next product at step 1. 3a. WarehouseEmployee informs System that a shipment of x kg of product p (which is sold by-weight) has arrived. 3a.1 WarehouseEmployee glues a barcode sticker on the container of the shipment and enters expiry date into scanner. 3a.2 WarehouseItemScanner informs System of barcode and expiry date for the entire shipment. Use case continues at step 8.
MaintainEnoughItemsInStore Use Case
Use Case: MaintainEnoughItemsInStore Scope: Supermarket Purchasing System Level: User Goal Intention in Context: The intention of the StoreManager is to make sure that the store has enough items in stock. To diminish the frequency of deliveries, the system should try to fill the store’s stock to the maximum capacity, if possible. Multiplicity: Only one instance of this time-triggered use case executes at a given time for each store. Primary Actor: StoreManager Secondary Actor: WarehouseEmployee, StoreEmployee Main Success Scenario: At the end of each day, the system checks the inventory of each store s. Step 1-2 are repeated for each product p whose stock is below the threshold. 1. System ascertains that the warehouse has enough of product p in stock to max out the store’s stock. 2. System sends WarehouseEmployee a list of items that need to be delivered to store s. 3. The next morning, all requested items are shipped together by truck to store s. Step 4 is repeated for each product in the delivery truck. 4. StoreEmployee informs System that warehouse delivery for product p has arrived. Extensions: 1a. System determines that there is not enough stock in the warehouse to maximize the store’s stock. 1a.1. Order is put on hold, and system awaits next shipment to arrive at warehouse. Use case continues with next product at step 1.
Environment Model
Based on the Use Case Model shown above, an Environment Model for the Supermarket Purchasing System that can handle RegisterSupplier, SupplierUpdateProduct, ReplenishStore and ReplenishWarehouse (including all their extensions and inclusions) has been established. It is shown in Figure 2. The messages and their parameters are described below: Input Messages • RegisterSupplier(name: String, email: String, accInfo: form of a string that allows the system to contact a bank) • Login(username: String, password: EncryptedString) 5 String) (accInfo is some data structure in
0..* login supplierSetProductPrice withdraw logout unregister * 0..* :Supplier loginAck withdrawAck updateAck requestShipment shipmentReceived
* * 0..*
:Bank depositAck deposit
inventoryItem
:InventoryScanner
: Supermarket
expiredItem productToPutOnSale 0..* receivedDelivery startInventoryByUnit updateInventoryByWeight doneInventoryByUnit deliverToStore noSupplierForProduct
*
<<time-triggered>> checkExpiredItems replenishStore replenishWarehouse newItem
:StoreTerminal
* 0..*
registerSupplier
0..1
1
:AdminTerminal
registrationAck
0..*
*
startReceivingProductByUnit doneReceivingProductByUnit :WarehouseTerminal receivedProductByWeight
:WarehouseItemScanner
Figure 2: Supermarket Purchasing Subsystem Environment Model • SetSupplierProduct(p: • Withdraw(amount: • Logout() • UnregisterSupplier() • DepositAck(s: Supplier) Product, s: Date) Supplier) (the assumption is that one product is unloaded • StartReceivingProductByUnit(p: at a time) • NewItem(b: Barcode, expiresOn: Product, price: Integer)
Integer)
• DoneReceivingProductByUnit() • ReceivedProductByWeight(p: • ReceivedDelivery(p: • InventoryItem(b: • StartInventoryByUnit(p: • DoneInventoryByUnit(p: Product, s: Supplier, w: Weight, b: Barcode, expiresOn: Date) Product) Product)
Barcode) Product) Barcode, w: Weight)
• UpdateInventoryByWeight(b:
6
Time-Triggered Events • CheckExpiredItems() • ReplenishStore() • ReplenishWarehouse() Output Messages type RegistrationOutcome is enum {ok, accountAlreadyExists} type LoginOutcome is enum {ok, notLoggedIn, wrongUsernameOrPassword, accountBlocked} • RegistrationAck(outcome: • LoginAck(result: • WithdrawAck() • UpdateAck() • RequestShipment(p: • ShipmentReceived(p: • Deposit(acc: • ExpiredItem(i: Product, numberOfItemsOrWeight: Product, numberOfItemsOrWeight: Integer) Integer) Integer, amountCredited: Integer) RegistrationOutcome, username: String, password: String)
LoginOutcome)
AccountDetails, amount: Item)
• ProductToPutOnSale(p: • DeliverToStore(s: • NoSupplierForProduct(p:
Product, numberOfExpiringItemsOrWeight: Set(Item))
Integer)
Store, items: Product)
Concept Model
The Concept Model for the Supermarket Purchasing Subsystem is shown in Figure 3.
Task 1: Operation Model for the Purchasing Subsystem
Develop a (partial) Operation Model for the Supermarket Purchasing System that covers the use cases RegisterSupplier, UpdateSupplierProduct, MaintainEnoughItemsInWarehouse and MaintainEnoughItemsInStore (i.e, you don’t have to handle WithdrawSupplierFunds, UnregisterSupplier, UpdateStoreInventory, PutExpiringItemsOnSale, RemoveExpiredItems). This involves writing operation schemas for the following operations: RegisterSupplier, Login, SetSupplierProduct, StartReceivingProductByUnit, NewItem, DoneReceivingProductByUn ReceivedProductByWeight, ReceivedDelivery, CheckExpiredItems, ReplenishStore, ReplenishWarehouse These operations should generate the following output messages: RegistrationAck, LoginAck, UpdateAck, RequestShipment, ShipmentReceived, DeliverToStore, NoSupplierForProdu ExpiredItem You can use the following assumptions: • UpdateSupplierProduct: a supplier will never try to register a price for a product that your supermarket chain does not sell • MaintainEnoughItemsInWarehouse: Shipments requested from a supplier always eventually arrive at the warehouse. However, the received shipments from the supplier might not contain the total quantity of product requested. Shipments from the same supplier arrive in the same order as they were requested (in particular if they are shipments of the same product). 7
*
0..*
*
Store ItemScanners
0..*
Store Terminals
<<system>> Supermarket Purchasing System * 1 0..* Bank BankAccount Details accInfo: String amountToDeposit: Integer
myAcc 1 owner 1
{ordered} 0..* oustandingDelivery
StoreDelivery {ordered} 0..* StoreCatalogue Store dest quantity: Integer address: String 1 expectedDelivery stThreshold: Integer onHold: boolean stMaxStock: Integer soldAt 0..* 0..1 location
at 1
0..* scannedItems
shipmentProduct 1 category 1
from 1 currentShipment 0..*0..* shippedIn {ordered} Warehouse 0..1 SupplierShipment unloading quantity: Integer
scannedItems expiry: Date 0..*
Item
0..* itemsInStore
SupplierAccount name: String email: String * <<id>> username: String password: String balance: Integer Supplier loggedIn: Boolean nbOfAttempts: Integer
SupplierCatalogue price: Integer
0..* sells 0..*
Inventory
0..* of 1 0..1 productOrdered 1
0..1 deliveredIn
suppliedBy 0..*
Product name: String myProducts price: Integer 0..* whMaxStock: Integer whThreshold: Integer
myCode: Barcode
0..* transportedItems
price: Integer requestedOn: Date
0..*
Calendar 1 today: Date * 1 *
Warehouse ItemScanner
Warehouse Terminal
Admin Terminal
Product name : String price : Integer
Item expiry : Date priceSold: Integer
ProductByWeight unitWeight : Integer
ProductByUnit
ItemByWeight weight : Integer
ItemByUnit
Figure 3: Supermarket Purchasing Subsystem Concept Model
8
• MaintainEnoughItemsInStore: In case the warehouse does not have enough items to completely replenish the store’s stock, the delivery is put on hold. Deliveries leaving the warehouse always eventually arrive at the store. No items are lost or broken during transport. Deliveries for the same product arrive in the same order as they were requested.
Hand-In
Please hand in a paper copy of your solution until Tuesday November 9th. Remember that you are allowed to work in groups of 2, but not with a person you worked with for a previous assignment. If you work with someone, please hand in a single copy signed by both of you.
9
Assignment 2
Supermarket - Inventory Control and Purchasing Subsystem
Operation Model and Protocol Model
(10% of final grade)
November 9, 2010
1
Problem Statement
The Supermarket System is a computerized system that automates purchases, sales, delivery, returns, monitoring, inventory control, marketing, payroll, accounting, and security for supermarkets (think Provigo, Loblaws, or Metro). You are to elaborate the Operation Model for the inventory control and purchasing subsystem (IC&P), which helps each store manager to keep track of the products in store, coordinates product deliveries from the common warehouse to the stores, and assists in purchasing products from suppliers.
2
2.1
Informal Description (unchanged)
Sales Subsystem (already developed)
Sales A customer queues at the checkout counter after completing his shopping. The customer places the items in the cart on the conveyor belt. The cashier then scans each item and places it in a bag. For each item, if the item is expired, the system should flash a warning. The cashier then discards the item. The customer can then decide to go get another item, or continue without it. If the barcode is missing on the item, the cashier keys in the product number. If the barcode reader recognizes the code, the price is displayed. For items sold by weight (e.g. fruits and vegetables), the items are placed on the scale and the cashier keys in the code for the product. The customer may have coupons (e.g., 4 for 1, 10% less, $1 off) for some products. The cashier keys in the coupon number, so that the appropriate amount is deducted from the bill. After all the items are scanned, the cashier relays the total to the customer and waits for the payment. The customer can pay by cash, credit or debit card. Problems can arise if the card does not have enough credit or if the debit card PIN is not recognized. Also, a customer can ask for cash-back if he pays by debit card. The cashier only has access to the cash register immediately after a sale has been made. At other times, the register is locked by the system. Delivery At the checkout counter, the customer can choose to have the purchases delivered. The delivery charge is then added to the total. Some discounts may be applicable (e.g. for students). The name of the client, his address and phone number are stored in the system. The purchases are then queued for delivery. On delivery, the customer needs to acknowledge receipt of the goods. Returns An item sold can be returned by a customer within 30 days from the date of purchase. Before accepting the return, it is verified whether the return deadline still holds and also whether the item is in proper condition. However, food products 1
are not accepted for return. The customer has to take the items to the customer service. The service agent then keys in or scans the item code to verify whether the item actually was bought from their store. The item is checked and approved for return. If the customer has the original receipt, he gets refunded in the same form than his original payment. Without receipt, the client receives a gift card.
2.2
Inventory Control and Purchasing Subsystem (what you need to develop)
Inventory Control Inventory control ensures that fresh items are regularly maintained in the store. For each item purchased, the expiry date should be recorded. For items sold by weight, the expiry date is assumed to be the same for all items when a delivery is received from a supplier. If the expiry date of an item equals the current date, the store personnel should be alerted. The employees then take action to remove the expired items from the shelves. If certain items in a store are going to expire soon, the store manager is alerted. The definition of “soon” would vary with the product, e.g. the alert for chocolates can be given a month before, whereas the alert for perishable items like fruits and vegetables can be given 7 days before. If a lot of stock is remaining, then the product can be put on sale (e.g. reduced price or “two-for-one” offers), so that the items are sold before they expire. Since items in the real world can be lost, are destroyed or stolen, there is a need to make sure that the inventory that the system has on file for each product actually corresponds to reality. The employees of the store should therefore investigate the stock periodically, and update the store inventory to reflect reality. Purchasing The supermarket chain has a warehouse in town that is used to store large quantities of the products that the individual stores sell. At the end of each day, the system looks at the inventory of each store. If the stock of a product in a store has fallen below a certain threshold, the warehouse is contacted in order to replenish the store’s stock. All requested products that the warehouse has in stock are shipped together in one shipment to the store that placed the request early next morning. If a product is not in stock, the request for that product is put on hold. The purchase subsystem also handles renewal of warehouse stock by purchasing products from suppliers. The suppliers create accounts with the system by calling the supermarket’s administration. Using a user name and a password, registered suppliers can log into the system at any time to set or update the list of products they offer and at what price. It is possible that some goods are offered by several suppliers. When the stock of a product in the warehouse falls below a certain threshold, the system determines the supplier that currently offers the best deal on the product, and contacts the supplier to place an order that replenishes the warehouse to the maximum capacity. Once the shipment arrives at the warehouse, the account of the supplier is credited with the appropriate amount. The merchandise is tagged with barcodes, if applicable, entered into the system, and any outstanding requests from stores for the received product are immediately fulfilled, if any. At any time, a supplier can withdraw money from the account in the supermarket system by requesting a money transfer to the supplier’s own bank account. Finally, a supplier who does not wish to continue providing products for the supermarket can unregister with the system, in which case all remaining funds are transferred to the supplier’s bank account, and the supplier’s records in the system are deleted.
2.3
Other Subsystems (just for information, i.e. not part of the assignment)
Security Subsystem The security subsystem aims to reduce thefts and other incidents in the stores. A security tag is attached to some products, which is demagnetized after purchase to prevent the security alarms from going on. Cameras are installed in various places in the store to aid in inspection of customer behavior. Marketing Subsystem The marketing subsystem maintains statistics of sales and returns. The goal is to maximize sales by studying customer behavior and psychology. For instance, the statistics gathered by the marketing system can be used to estimate how many items of a product are sold on average per day depending on various parameters (such as time of the year, etc...). This information can then be used to optimize purchasing strategies. 2
*
Supermarket Purchasing SellGoodsTo SupermarketChain
de>>
1 MaintainEnough ItemsInWarehouse
Supplier *
<<
in
<<inclu
clu
de
>>
<<i
>>
ncl
ude
>>
Warehouse Manager
<< in clu de
RegisterSupplier Administration Employee
UpdateSupplier Product
<<include>>
WithdrawSupplier Funds
e> >
UnregisterSupplier <<include>>
i <<
n
d clu
<<i
nclu
de>
>
MaintainEnough ItemsInStore
*
IdentifySupplier UpdateStore Inventory PutExpiringItems OnSale RemoveExpired Items
Warehouse Employee
*
*
*
Store Employee
Bank
StoreManager
Figure 1: Supermarket Purchasing Subsystem Use Case Diagram Payroll Subsystem The payroll subsystem keeps record of the employees, e.g. how many hours they work, and handles payments of salaries.
3
Requirements Elicitation Background Information (Partial) Use Case Model of the Purchasing Subsystem
The Use Case Model of the purchasing subsystem has already been established and is presented in Figure 1. Detailed textual use case templates of 4 selected user goal level use cases are also given below.
RegisterSupplier Use Case
Use Case: Register Supplier Scope: Supermarket Purchasing System Level: User Goal Intention in Context: The intention of the Supplier is to open an account with the supermarket purchasing system. To do this, the supplier contacts an Administrator by phone. Multiplicity: Many Suppliers may be registering at any one time. A Supplier only requests to register once at a given time. Primary Actor: Supplier Facilitator Actor: Administrator Main Success Scenario: Supplier calls Administrator on the phone, providing supplier information details . 1. Administrator instructs System to create a new supplier account, providing supplier information details . 3
2. System informs Administrator of successful creation of the supplier account, providing the username and password. Administrator communicates the username and password to the supplier over the phone. Extensions: 2a. System ascertains that the supplier already has an account with the system. 2a.1 System informs Administrator about situation; use case ends in failure.
Supplier information details include: name, email, bank information
UpdateSupplierProduct Use Case
Use Case: Update Supplier Product Scope: Supermarket Purchasing System Level: User Goal Intention in Context: The intention of the Supplier is to inform the system of a product that he is capable of supplying and the price that he is asking for it. Multiplicity: Many Suppliers may be updating their products simultaneously. A given Supplier updates his products one at the time. Primary Actor: Supplier Main Success Scenario: 1. Supplier identifies with System. 2. Supplier informs System of product he wishes to update, and of price. 3. System informs Supplier of successful update. Extensions: 2a. Identification failed. Use case ends in failure.
IdentifySupplier Use Case
Use Case: IdentifySupplier Scope: Supermarket Purchasing System Level: Subfunction Intention in Context: The intention of the Supplier is to identify him/herself to the System. Multiplicity: Multiple Suppliers can identify themselves simultaneously. Primary Actor: Supplier Main Success Scenario: 1. Supplier provides user name and password to System. 2. System validates username and password. 3. System informs Supplier of successful login. Extensions: 2a. System ascertains that the user name or password is unknown or wrong. 2a.1 System sends error message to Supplier. Use case continues at step 1. 2a.1a. System ascertains that Supplier entered a wrong password for the third time in a row. 2a.1a.1 System informs Supplier that his/her account is now blocked. Use case ends in failure. 2b. System ascertains that the supplier’s account is blocked. 2b.1 System informs Supplier of situation. Use case ends in failure.
MaintainEnoughItemsInWarehouse Use Case
Use Case: MaintainEnoughItemsInWarehouse Scope: Supermarket Purchasing System Level: User Goal Intention in Context: The intention of the WarehouseManager is to make sure that the warehouse has enough items in stock to fulfill potential orders from stores. Multiplicity: Only one instance of this time-triggered use case can execute at a given time. Primary Actor: WarehouseManager Secondary Actor: Supplier, WarehouseEmployee, WarehouseItemScanner Main Success Scenario: Step 1-7 are executed in parallel for each product p whose stock is below the threshold. 4
1. System orders from Supplier that currently offers the best price for product p as much quantity as possible, i.e. enough to fill the warehouse stock for product p to the maximum and to honor all the store orders. 2. Supplier ships product to warehouse. 3. WarehouseEmployee informs System that a shipment of product p (which is sold by-unit) has arrived. Steps 4-6 are repeated for each item of product p included in the shipment. 4. WarehouseEmployee glues a barcode sticker to the item and enters expiry date of item into WarehouseItemScanner. 5. WarehouseItemScanner informs System of barcode and expiry date of item. 6. WarehouseEmployee stocks item in the warehouse. 7. WarehouseEmployee informs System that unloading of the shipment of product p is completed. 8. System informs Supplier that shipment was received. Note: In case there are outstanding orders for product p by stores, the system does the necessary steps to fulfill them (see use case MaintainEnoughItemsInStore). Extensions: 1a. No supplier currently produces product p. 1a.1 System informs WarehouseManager of situation. Use case continues with next product at step 1. 3a. WarehouseEmployee informs System that a shipment of x kg of product p (which is sold by-weight) has arrived. 3a.1 WarehouseEmployee glues a barcode sticker on the container of the shipment and enters expiry date into scanner. 3a.2 WarehouseItemScanner informs System of barcode and expiry date for the entire shipment. Use case continues at step 8.
MaintainEnoughItemsInStore Use Case
Use Case: MaintainEnoughItemsInStore Scope: Supermarket Purchasing System Level: User Goal Intention in Context: The intention of the StoreManager is to make sure that the store has enough items in stock. To diminish the frequency of deliveries, the system should try to fill the store’s stock to the maximum capacity, if possible. Multiplicity: Only one instance of this time-triggered use case executes at a given time for each store. Primary Actor: StoreManager Secondary Actor: WarehouseEmployee, StoreEmployee Main Success Scenario: At the end of each day, the system checks the inventory of each store s. Step 1-2 are repeated for each product p whose stock is below the threshold. 1. System ascertains that the warehouse has enough of product p in stock to max out the store’s stock. 2. System sends WarehouseEmployee a list of items that need to be delivered to store s. 3. The next morning, all requested items are shipped together by truck to store s. Step 4 is repeated for each product in the delivery truck. 4. StoreEmployee informs System that warehouse delivery for product p has arrived. Extensions: 1a. System determines that there is not enough stock in the warehouse to maximize the store’s stock. 1a.1. Order is put on hold, and system awaits next shipment to arrive at warehouse. Use case continues with next product at step 1.
Environment Model
Based on the Use Case Model shown above, an Environment Model for the Supermarket Purchasing System that can handle RegisterSupplier, SupplierUpdateProduct, ReplenishStore and ReplenishWarehouse (including all their extensions and inclusions) has been established. It is shown in Figure 2. The messages and their parameters are described below: Input Messages • RegisterSupplier(name: String, email: String, accInfo: form of a string that allows the system to contact a bank) • Login(username: String, password: EncryptedString) 5 String) (accInfo is some data structure in
0..* login supplierSetProductPrice withdraw logout unregister * 0..* :Supplier loginAck withdrawAck updateAck requestShipment shipmentReceived
* * 0..*
:Bank depositAck deposit
inventoryItem
:InventoryScanner
: Supermarket
expiredItem productToPutOnSale 0..* receivedDelivery startInventoryByUnit updateInventoryByWeight doneInventoryByUnit deliverToStore noSupplierForProduct
*
<<time-triggered>> checkExpiredItems replenishStore replenishWarehouse newItem
:StoreTerminal
* 0..*
registerSupplier
0..1
1
:AdminTerminal
registrationAck
0..*
*
startReceivingProductByUnit doneReceivingProductByUnit :WarehouseTerminal receivedProductByWeight
:WarehouseItemScanner
Figure 2: Supermarket Purchasing Subsystem Environment Model • SetSupplierProduct(p: • Withdraw(amount: • Logout() • UnregisterSupplier() • DepositAck(s: Supplier) Product, s: Date) Supplier) (the assumption is that one product is unloaded • StartReceivingProductByUnit(p: at a time) • NewItem(b: Barcode, expiresOn: Product, price: Integer)
Integer)
• DoneReceivingProductByUnit() • ReceivedProductByWeight(p: • ReceivedDelivery(p: • InventoryItem(b: • StartInventoryByUnit(p: • DoneInventoryByUnit(p: Product, s: Supplier, w: Weight, b: Barcode, expiresOn: Date) Product) Product)
Barcode) Product) Barcode, w: Weight)
• UpdateInventoryByWeight(b:
6
Time-Triggered Events • CheckExpiredItems() • ReplenishStore() • ReplenishWarehouse() Output Messages type RegistrationOutcome is enum {ok, accountAlreadyExists} type LoginOutcome is enum {ok, notLoggedIn, wrongUsernameOrPassword, accountBlocked} • RegistrationAck(outcome: • LoginAck(result: • WithdrawAck() • UpdateAck() • RequestShipment(p: • ShipmentReceived(p: • Deposit(acc: • ExpiredItem(i: Product, numberOfItemsOrWeight: Product, numberOfItemsOrWeight: Integer) Integer) Integer, amountCredited: Integer) RegistrationOutcome, username: String, password: String)
LoginOutcome)
AccountDetails, amount: Item)
• ProductToPutOnSale(p: • DeliverToStore(s: • NoSupplierForProduct(p:
Product, numberOfExpiringItemsOrWeight: Set(Item))
Integer)
Store, items: Product)
Concept Model
The Concept Model for the Supermarket Purchasing Subsystem is shown in Figure 3.
Task 1: Operation Model for the Purchasing Subsystem
Develop a (partial) Operation Model for the Supermarket Purchasing System that covers the use cases RegisterSupplier, UpdateSupplierProduct, MaintainEnoughItemsInWarehouse and MaintainEnoughItemsInStore (i.e, you don’t have to handle WithdrawSupplierFunds, UnregisterSupplier, UpdateStoreInventory, PutExpiringItemsOnSale, RemoveExpiredItems). This involves writing operation schemas for the following operations: RegisterSupplier, Login, SetSupplierProduct, StartReceivingProductByUnit, NewItem, DoneReceivingProductByUn ReceivedProductByWeight, ReceivedDelivery, CheckExpiredItems, ReplenishStore, ReplenishWarehouse These operations should generate the following output messages: RegistrationAck, LoginAck, UpdateAck, RequestShipment, ShipmentReceived, DeliverToStore, NoSupplierForProdu ExpiredItem You can use the following assumptions: • UpdateSupplierProduct: a supplier will never try to register a price for a product that your supermarket chain does not sell • MaintainEnoughItemsInWarehouse: Shipments requested from a supplier always eventually arrive at the warehouse. However, the received shipments from the supplier might not contain the total quantity of product requested. Shipments from the same supplier arrive in the same order as they were requested (in particular if they are shipments of the same product). 7
*
0..*
*
Store ItemScanners
0..*
Store Terminals
<<system>> Supermarket Purchasing System * 1 0..* Bank BankAccount Details accInfo: String amountToDeposit: Integer
myAcc 1 owner 1
{ordered} 0..* oustandingDelivery
StoreDelivery {ordered} 0..* StoreCatalogue Store dest quantity: Integer address: String 1 expectedDelivery stThreshold: Integer onHold: boolean stMaxStock: Integer soldAt 0..* 0..1 location
at 1
0..* scannedItems
shipmentProduct 1 category 1
from 1 currentShipment 0..*0..* shippedIn {ordered} Warehouse 0..1 SupplierShipment unloading quantity: Integer
scannedItems expiry: Date 0..*
Item
0..* itemsInStore
SupplierAccount name: String email: String * <<id>> username: String password: String balance: Integer Supplier loggedIn: Boolean nbOfAttempts: Integer
SupplierCatalogue price: Integer
0..* sells 0..*
Inventory
0..* of 1 0..1 productOrdered 1
0..1 deliveredIn
suppliedBy 0..*
Product name: String myProducts price: Integer 0..* whMaxStock: Integer whThreshold: Integer
myCode: Barcode
0..* transportedItems
price: Integer requestedOn: Date
0..*
Calendar 1 today: Date * 1 *
Warehouse ItemScanner
Warehouse Terminal
Admin Terminal
Product name : String price : Integer
Item expiry : Date priceSold: Integer
ProductByWeight unitWeight : Integer
ProductByUnit
ItemByWeight weight : Integer
ItemByUnit
Figure 3: Supermarket Purchasing Subsystem Concept Model
8
• MaintainEnoughItemsInStore: In case the warehouse does not have enough items to completely replenish the store’s stock, the delivery is put on hold. Deliveries leaving the warehouse always eventually arrive at the store. No items are lost or broken during transport. Deliveries for the same product arrive in the same order as they were requested.
Hand-In
Please hand in a paper copy of your solution until Tuesday November 9th. Remember that you are allowed to work in groups of 2, but not with a person you worked with for a previous assignment. If you work with someone, please hand in a single copy signed by both of you.
9
