Order Processing

Requirements An employee takes orders from customers Each purchase may contain multiple products System maintains customer information System maintains product information System keeps track of purchase orders

Use Cases Add/delete/update/view customers Add/delete/update/view products Take purchase orders List/view purchase orders Delete purchase orders Update purchase orders

The Database - ERD Name Address Name Description Id Id Product Customer 1 1 Price Places Is_for PO Id N 1 N Purchase Order contains Line_Item Order_date Total_Amount Line# Quantity

The Database - Schema customer customer_id name address purchase_order po_id Customer_id order_date Total_amount line_item id po_id product_id quantity product product_id name description price

System Architecture Database Take purchase order Delete purchase order OrderManagement Take purchase order Delete purchase order Update purchase order View purchase order CustomerManagement ProductManagement Add customer Delete customer Update customer View customer Add product Delete product Update product View product Database

System Architecture Each package is responsible for CRUD on a set of tightly related business entities E.g., Customers, customer groups (VIP, etc), and customer credit card info as a package Use cases are allocated to packages and each package contains related use cases E.g., Add customer including his group and credit card info, update customer, delete customer, and query customer in CustomerManagemant Each package has a Manager which takes cares of the business logic of the use cases. E.g., OrderManager would check if an order contains more than the limit of the number of items or not. A Design Pattern called Service Layer may be used to package managers’ operations as one class – ServiceLayer OrderProcessing sample app employs this approach.

System Architecture Each use case is mapped to a Presenter which is responsible for the presentation logic of the use case. E.g., TakeOrderPresenter is responsible for creating a new purchase order and saving the order in the DB Each Presenter may employ multiple Views each of which is a UI. E.g., TakeOrderPresenter uses SelectCustomerView to select a customer for the order, SelectOrderItemsView to collect order items, finally ConfirmOrderView to display the order info to the user.

System Architecture Database entity OrderManagement Customer Product PuchaseOrder OrderItem OrderManagerUI.java takeOrder() viewOrder() updateOrder() db deleteOrder() CustomerDao ProductDao PuchaseOrderDao OrderItemDao MailOrderDatabase PurchaseOrderManager Depends on A B Database

Architecture – Service Layer OrderManagement CustomerManagement OrderManagerUI.java ProductManagement server ServiceLayer (Façade) PurchaseOrderManager CustomerManager ProductManager db CustomerDao PurchaseOrderDao OrderItemDao ProductDao MailOrderDatabase Database

Detailed Design: db & entity Customer Product Purchase Order Order Item Customer_id Name Address Product_id Name Description Price Po_id Customer_id Order_date Po_id Product_id Quantity CustomerDao ProductDao PurchaseOrderDao OrderItemDao Insert() Delete() Update() getCustomerById() getAllCustomers() Insert() Delete() Update() getProductById() getAllProducts() Insert() Delete() Update() getPOById() getAllPOs() Insert() Delete() Update() getItemByItemId() getItemsByOrderId() MailOrderDatabase getConnection() Close()

Detailed Design: Startup AppController Main() HomeView.instance().display() OrderManagement HomeView displayMenu() Take Order OrderManagerUI takeOrderUI() viewOrder() View Order CustomerManagement AppContext Static getInstance() getDbConnection() ProductManagement