Class diagram's entity attributes inquiry

Question

I have a scenario about a customer purchasing a stock from a company and calculating branch sales. So I made a class diagram of customer, purchase and branch sales but I am not sure what to put in the branch sales entity as this branch sales should indicate total sales done for each branch. Here my diagram:

Should the branch sales includes purch_totalprice, purch_stock, and purch_stockquantity too, like in purchase entity?

Answer 1

The diagram looks more like an entity/relationship diagram for database tables than like an UML class diagram:

• In an UML class diagram, you would not use a dotted line to separate the unique identifier form the other properties, but you would use a separator to show operations (i.e. methods or functions).
• In an ER diagram, this practice is less unusual althoug not common either.

This being said, whatever the modelling language, this diagram:

• doesn't show what the Customer is purchasing. stock is too ambiguous: is it a material that you have in an inventory? Is this a stock-exchange stock (a share in a company)? Whatever the answer, it would be nice to show this as an own class/entity (I'll use Product hereafter).

• doesn't show any class/entity that is identified with a branch_id. I'd suggest to add an entity called Branch

• doesn't show the associations/relations. You should have at least Customer--Purchase, Purchase--Product, and Purchase---Branch, nor their multiplicity/cardinality.

If you have all these information in your model, the "branch sales" are in fact a data extract of Purchase and not a distinct entity: the purchase of the customer being the sales for the branch. For your diagram:

• If you're on a class model, you'd add a getSalesDetails() function: this function would return the list of all the relevant Purchase objects for that branch. You could also add a getTotalSales() that would make do a total of the relevant sales. Perhap's taking into account a date of the purchase?
• If you're in an ER model, you would know how to find this data thanks to the association between branch and purchase (you can make it clear by labelling the relation Branch--Purchase as makes sales. But you could also show a separate table with the relevant data duplicated, if you want to document your physical model and intend to implement this in your database (either with redundant data ,not recommended, or with a view)

Last important remark regarding classes:

• If your diagram should be an UML class diagram, but you want to show the details of your database model, you may put «table» above every entity.

• But if you do not intend to document classes, i.e. the classes would stay without operations (i.e. class behavior) there's really something missing - it's like an anemic domain model (not forbident, but far from ideal).