Question

This is my sample class diagram

cls_Invoice = {InvoiceID:int, InvoiceDate:Date, InvoiceProduct:cls_Products};

cls_Products = { ProductID:int, StockQuantity:double , Price:double};

DB tables

Invoice = { InvoiceID, InvoiceDate}; Products = { ProductID, StockQuantity, Price};

1 Invoice has Many Products 1 Products can be in Many Invoices so eventually there will be a linking in ER design as shown below

Invoice_Products = {InvoiceID, ProductID, Qty, Price}

but now there are another two properties Qty and Price which I have no idea on drawing the class diagram please advice ?

Was it helpful?

Solution

In a UML class diagram, you'd have two classes: Invoice and Product. Invoice has two attributes: InvoiceID and InvoiceDate, Product has three attributes: ProductID, StockQuantity, and Price. Between the two classes you need an association, with a multiplicity of 1..* on both ends.

OTHER TIPS

Although I am not very familiar with shopping applications, but when I think about it, these points come to my mind:

There should be another concept for sold item/product than item/product. Because, the "concept of product" should be independent of "what may be done to product". For example, selling a product is not the same concept as the product itself. Therefore, you may have another class, like orderItem.

class product {
    Long productId
    String productName
    ...
} 

class orderItem{
      Product soldProduct;
      Invoice itsInvoice;

      public Invoice getItsInvoice();

}

class Invoice {
    Long invoiceNumber;
    List<OrderItem> orderItem;

}

If you do this, then, each order item belongs only to one invoice, while an invoice may have many order items. Hence, there is a one-to-many relationship between ivoice and order item, and one-to-one relationship between oreritem and product.

Even, if you still do it with only two entities, invoice and product, which implies that you combine the concepts of "product" and "selling product" in one entity, still the relationship between invoice and product is one-to-many not many-to-many. Because, the relationship between the two is through "selling of the product". In which case, a "sold product" belongs only to one invoice.

But, the first approach seems better to me.

This is a one to many scenario and not a many to many scenario.The same product cannot be a part of many invoices.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top