Class diagram for an online shopping system
This class diagram models the core of an online shopping system: customers placing orders, orders made of items that point to products, and payments made through a shared interface. It suits students learning UML class notation and developers sketching an e-commerce domain model.
Example: Class diagram for online shopping system: click to open it in the editor and change it.
Classes, enum and interface
| Element | Kind | Attributes / methods |
|---|---|---|
| Customer | class | id: UUID, email: String; placeOrder(cart: Cart): Order |
| Order | class | id: UUID, status: OrderStatus, total: Money; pay(p: Payment): boolean, cancel(): void |
| OrderItem | class | qty: int, price: Money |
| Product | class | sku: String, name: String, price: Money |
| OrderStatus | enum | PLACED, PAID, SHIPPED, DELIVERED, CANCELLED |
| Payment | interface | charge(amount: Money): boolean |
| UpiPayment | class | vpa: String; charge(amount: Money): boolean |
| CardPayment | class | last4: String; charge(amount: Money): boolean |
Attributes marked - are private and methods marked + are public. Cart and Money appear only as types, not as classes in this diagram.
Relationships and multiplicity
- Customer to Order: association, 1 to 0..*. A customer can have zero or many orders, and each order belongs to one customer.
- Order to OrderItem: composition, 1 to 1..*. An order holds at least one item, and items do not exist without their order.
- OrderItem to Product: directed association, each item refers to exactly 1 product. The item stores its own price, so later product price changes do not alter past orders.
- Order depends on OrderStatus for its status value and on Payment through pay(p: Payment).
- UpiPayment and CardPayment realize the Payment interface, each with its own charge() method.
How to adapt it for your project
- Add a Cart class with its own items if you want to model shopping before checkout.
- Add another payment class, such as a wallet, that realizes Payment. Order stays unchanged.
- Extend OrderStatus with values like RETURNED or REFUNDED if your flow needs them.
- Add an Address or Shipment class linked to Order for delivery details.
Tip: Keep Order depending on the Payment interface, not on concrete classes. This shows the open/closed principle well, which examiners and code reviewers like to see.
Frequently asked questions
What are the main classes in a class diagram for online shopping?
This diagram has the classes Customer, Order, OrderItem, Product, UpiPayment and CardPayment, plus the OrderStatus enum and the Payment interface.
Why is Order to OrderItem a composition?
Order items belong to one order and have no meaning without it. When an order is deleted, its items go too, which is exactly what the filled diamond (composition) shows.
How are different payment methods shown in the class diagram?
Payment is an interface with a charge(amount: Money) method. UpiPayment and CardPayment realize it, so Order.pay() can accept either one without knowing which type it is.
Make your own class diagram with AI →