A class diagram for an online ordering system captures the static structure of the classes that represent the business: customers who browse a menu, build carts, place orders, pay, and track deliveries; restaurants or stores that receive orders; and riders who fulfill them. In the last 3 years I have built and reviewed dozens of BSIT capstone versions of this exact system, and the pattern is consistent. Panels in 2026 expect 10-14 classes, correct composition versus aggregation, and current-year features like GCash payment integration and real-time GPS tracking. This guide walks through the class diagram with defense-ready detail.
Quick 2026 verdict
A defensible online ordering class diagram has 10-14 classes: Customer, Restaurant or Store, MenuItem, Category, Cart, CartItem, Order, OrderItem, Payment, DeliveryAddress, Rider, RiderLocation, Rating, User. Composition (filled diamond) between Cart-CartItem and Order-OrderItem. Association between Customer-Order and Rider-Order. Add GCash payment method and RiderLocation for GPS to look current-year.
Why a strong class diagram matters here
By the way, I have seen way too many capstones with online-ordering systems that get flagged at defense because the class diagram is thin. The classic mistake is one big Order class with everything inside it. Panels see that and know the student did not decompose properly. A proper class diagram with 10-14 focused classes and correct relationships proves you understand object-oriented design and gives you a direct blueprint for the database.
Want to customize this class diagram for your capstone?
Open the Online Ordering System template in CapstoneUML. Drag, rename, add relationships, then export as PNG, SVG, PowerPoint, or PDF for your Chapter 3 documentation.
For a capstone that is food ordering, grocery ordering, medicine ordering, or any store-to-customer flow, the class shape is nearly identical. Adapt the class names to your domain (MenuItem for food, Product for grocery, Medicine for pharmacy) and the design carries over cleanly.
Core classes for an online ordering system
Customer ------------ - customerId : String - fullName : String - email : String - phone : String - deliveryAddresses : List<DeliveryAddress> - loyaltyPoints : Integer ------------ + addDeliveryAddress(address : DeliveryAddress) : Void + placeOrder(cart : Cart, paymentMethod : PaymentMethod) : Order + redeemPoints(amount : Integer) : Boolean
Restaurant (or Store) ------------ - restaurantId : String - name : String - address : String - coordinates : GeoPoint - openHours : String - rating : Decimal - menu : List<MenuItem> ------------ + getMenuByCategory(cat : Category) : List<MenuItem> + isOpenNow() : Boolean + acceptsOrder(cart : Cart) : Boolean
MenuItem ------------ - itemId : String - name : String - description : String - category : Category - price : Decimal - image : String - isAvailable : Boolean - preparationTime : Integer // in minutes ------------ + toggleAvailability() : Void
Cart ------------ - cartId : String - customer : Customer - items : List<CartItem> [composition, filled diamond] - restaurant : Restaurant - createdAt : DateTime ------------ + addItem(menuItem : MenuItem, qty : Integer) : Void + removeItem(cartItemId : String) : Void + computeSubtotal() : Decimal + clear() : Void
CartItem ------------ - cartItemId : String - menuItem : MenuItem - quantity : Integer - specialInstructions : String ------------ + computeLineTotal() : Decimal
Order ------------ - orderId : String - customer : Customer - restaurant : Restaurant - items : List<OrderItem> [composition, filled diamond] - deliveryAddress : DeliveryAddress - status : Enum(PLACED, ACCEPTED, PREPARING, READY, PICKED_UP, DELIVERED, CANCELLED) - subtotal : Decimal - deliveryFee : Decimal - totalAmount : Decimal - placedAt : DateTime - deliveredAt : DateTime (nullable) - rider : Rider (nullable, assigned when picked up) ------------ + updateStatus(newStatus : Enum) : Void + assignRider(rider : Rider) : Void + cancel(reason : String) : Boolean + getEstimatedDelivery() : DateTime
OrderItem ------------ - orderItemId : String - menuItem : MenuItem - quantity : Integer - unitPrice : Decimal // snapshot at order time - specialInstructions : String ------------ + computeLineTotal() : Decimal
Payment ------------ - paymentId : String - order : Order - method : Enum(CASH_ON_DELIVERY, GCASH, MAYA, CREDIT_CARD) - amount : Decimal - status : Enum(PENDING, APPROVED, DECLINED, REFUNDED) - transactionRef : String - paidAt : DateTime (nullable) ------------ + process() : Boolean + refund() : Boolean
DeliveryAddress ------------ - addressId : String - customer : Customer - label : String // "Home", "Office" - streetLine : String - barangay : String - city : String - province : String - coordinates : GeoPoint - landmark : String ------------ + getFullAddress() : String
Rider ------------ - riderId : String - fullName : String - phone : String - vehicleType : Enum(MOTORCYCLE, BICYCLE, CAR) - plateNumber : String - isAvailable : Boolean - currentLocation : GeoPoint - rating : Decimal ------------ + acceptOrder(order : Order) : Void + updateLocation(loc : GeoPoint) : Void + markPickedUp(order : Order) : Void + markDelivered(order : Order) : Void
Rating ------------ - ratingId : String - order : Order - customer : Customer - targetType : Enum(RESTAURANT, RIDER, ITEM) - targetId : String - score : Integer // 1 to 5 - comment : String - createdAt : DateTime
Relationships with correct multiplicities
- Customer 1 — 0..* Order (a customer places zero-to-many orders)
- Customer 1 — 0..* DeliveryAddress (many saved addresses per customer)
- Restaurant 1 — 0..* MenuItem (many menu items per restaurant)
- Restaurant 1 — 0..* Order (restaurant receives many orders)
- Cart 1 — 1..* CartItem (COMPOSITION, filled diamond): cart items cannot exist without the cart
- Order 1 — 1..* OrderItem (COMPOSITION, filled diamond): order lines cannot exist without the order
- Order 1 — 1 Payment (one payment per order for the capstone; extend to 1..* if you support split payment)
- Order 0..* — 0..1 Rider (rider assigned per order; nullable while unassigned)
- Order 1 — 1 DeliveryAddress (snapshot at order time)
- Order 1 — 0..* Rating (customer rates restaurant, rider, and items separately)
2026 features every ordering class diagram should include
- GCash and Maya payment methods. Include them as enum options in Payment.method. Cash-only payment looks 5 years old for a Philippine capstone in 2026.
- Real-time GPS rider location. Rider class has currentLocation : GeoPoint. Add a RiderLocation class if you want a full history of movement points.
- Loyalty points. Customer.loyaltyPoints tracks accumulated points; Customer.redeemPoints() spends them at checkout.
- Ratings for restaurant, rider, and menu items separately. Single Rating class with targetType enum handles all three. Panels appreciate the single-abstraction design.
- Special instructions. CartItem and OrderItem both have specialInstructions field. Reviewers ask about “no onions” or “extra rice” scenarios.
- Price snapshot on Order. OrderItem.unitPrice captures price at order time. If restaurant changes menu price later, the old order still uses the old price. Panels test this.
- Order status enum with 6-8 states. The status enum is a common panel entry point. Have a clear list of statuses and be ready to explain transitions.
Common panel deductions on ordering class diagrams
- Cart and Order collapsed into one class (a cart becomes an order at checkout, they are different states of data)
- OrderItem missing (Order stores items as a JSON blob in a description field, which reviewers flag as poor design)
- Order.status shown as free-text String instead of Enum
- Payment merged into Order (Payment should be its own class because it has its own lifecycle: pending, approved, refunded)
- DeliveryAddress not snapshotted (Customer changes their address, and the old order suddenly shows the new address; that is a bug)
- Rider missing entirely, so the diagram shows food teleporting to customer
- All relationships shown as association without multiplicity labels
- Composition and aggregation swapped or both drawn as association
Comparing this to an inventory class diagram
| Aspect | Inventory system | Online ordering system |
|---|---|---|
| Core entity | Stock movement between warehouses | Order from customer to restaurant to rider |
| Composition example | PurchaseOrder-PurchaseOrderLine | Order-OrderItem, Cart-CartItem |
| External actor | Supplier | Payment gateway |
| Real-time element | Stock level sync | Rider GPS tracking |
Frequently Asked Questions
Do I need to include Rider if my capstone is pickup-only?
No. Remove Rider and RiderLocation classes. Order.status enum then does not need PICKED_UP; goes directly from READY to PICKED_UP_BY_CUSTOMER to COMPLETED. Keep the class diagram lean; do not include entities for features you did not implement.
Why snapshot the unit price on OrderItem?
Restaurant might raise the menu price after the customer already placed the order. Panels ask this exact question. If OrderItem.unitPrice references MenuItem.price live, the receipt total changes retroactively, which is a bug. Snapshot at order time.
Should I model Order.status as separate classes (State pattern)?
Not for BSIT capstone. Enum is sufficient and much simpler. State pattern is over-engineering for this scale. If your paper claims State pattern usage, you need to justify it; otherwise the enum is the correct choice.
How do I show payment gateway integration in the class diagram?
Add a PaymentGateway interface class or an external system reference. Payment.process() calls PaymentGateway.charge(). Panels ask about GCash or Maya specifically in 2026, so name the gateway concretely if you can.
Does DeliveryAddress belong to Customer or to Order?
Both. Customer has a list of saved DeliveryAddresses; Order stores a snapshot copy of the delivery address at order time (or a reference to the frozen version). This preserves history when the customer later edits their saved address.
Should Rating be one class or three (RestaurantRating, RiderRating, ItemRating)?
One class with a targetType enum handles all three. Simpler design, single table in the database, unified rating UI. Panels appreciate the single-abstraction approach. Three separate classes are over-engineering for capstone scale.
Related UML tutorials
- Class Diagram for Inventory Management System
- DFD for E-commerce Website (Levels 0, 1, 2)
- Sequence Diagram for Library Management System
- Activity Diagram for E-learning System
Official documentation
Official documentation
Joken E. Villanueva
Founder & Lead Developer at PIES IT Solution
Founder of PIES Information Technology Solutions, a software company building production-grade applications for institutions across the Philippines. Over 8 years of hands-on full-stack development experience, currently leading the development of ClinicAI, an AI-powered clinic management platform.
Expertise: PHP, MySQL, JavaScript, AI Integration, SaaS Architecture, VB.NET, Database Design, Capstone Documentation, Java · View all posts by Joken E. Villanueva →
Skip the redraw: grab the Online Ordering System template
Class, Use Case, ER, DFD, Activity, and Sequence diagrams already filled in with capstone-ready entities and flows. Free preview, no card required.