Is this Class Diagram Correct?

Question

I need some help to confirm I am on the right track with this. I did a use case diagram and class diagram for the popular online shopping scenario.

Please look through it and criticize constructively, let me have your views on it as I am still learning UML.

The story behind the modeling is shown below:

The name of the company is X-company and they are into the sales of paints. X-company has a website that sells these paints online to two types of customers - retailers and wholesalers. X-Company has a few paints currently which vary in color, size, cost each paint-type obviously varying in these characteristics. Retailers can log into the site and purchase paints in single digits (like 1 or 2 paints) at a time while wholesalers buy paints in large quantities at discounts of 10% for 10 paints and above, 20% for 20 paints and above, 30% for 30 paints and above.

The website has been made to be easy as possible. Customers get to the site, selects the type of paint and is shown the characteristics of the paint. If the customer accesspts to purchase they select the quanitity they need. If the customer is ok with the price they then confirm their order. on confirmation, the website checks for the stock of paints to see if there are enough paints available. If there are not available, the customer is notified and asked to select another type. If they are available, the customer provides payment card details such as address, card number, card pin. The payment is done through an external integration. On payment, the customers order is sent to the customer except if the customer requests a cancellation or the order through the website administrator.

The website-organizer or administrator is responsible for adding new paints to the website and taking out old paints when there is a new stock of paints.

The class diagram I have drawn is shown below:

Answer 1

• Give the classes singular names. Order, not Orders. Discount, not Discounts. If you have a class that is a collection\\list of Orders, however, then "Orders" would be fine.

• A User cannot buy more than one kind of paint at a time! The Order class should have a collection of Paint, not a single Paint instance.

• Paint, PaintType design does not seem logical. I don't see why there should be more than one class. Combine into a Paint class.

• I think there should be a PaintStock class. The methods in the Administrator class seem to be things that are done to PaintStock, so move them over. The Administrator class needs a PaintStock reference so it can call PaintStock.Add, etc.

• Payment class should be called CreditCardPayment given what's in it. I suspect that credit card is not the only way make payments. I'd make a Payment base class so we can easily expand the ways to pay later on.

• Add/Remove paint functions are inappropriate for the Administrator class. Put these methods in a PaintStock class.

• Rename BulkBuyer to Wholesaler

• Consider one User class. Get rid of Retailer and Wholesaler. I don't see a difference worth different classes. Make a BuyerType field in the User class to differentiate. If your business rules dictate purchase limits based on retailer vs wholesaler, that simple rule difference can easily live in one class.

• As a general rule - and it's a good one - do not store calculation results. So Order.TotalCost should be a method not a field.

• Order needs a Cancel method. NOT the Administrator class. The Administrator class needs an Order reference so it can call Order.Cancel.