UML混淆了很多场景

Question

这是我的示例类图

cls_Invoice = {InvoiceID：int，InvoiceDate：Date，InvoiceProduct：cls_Products};

cls_Products = {ProductID：int，StockQuantity：double，Price：double};

数据库表

Invoice = {InvoiceID，InvoiceDate};产品= {ProductID，StockQuantity，Price};

1发票有很多产品1产品可以在许多发票中，因此最终在ER设计中会有一个链接，如下所示

Invoice_Products = {InvoiceID，ProductID，Qty，Price}

但现在还有另外两个属性数量和价格，我不知道绘制类图请咨询？

Answer 1

在UML类图中，您有两个类：Invoice和Product。 Invoice有两个属性：InvoiceID和InvoiceDate，Product有三个属性：ProductID，StockQuantity和Price。在这两个类之间，您需要一个关联，两端的多重性为1 .. *。

Answer 2

虽然我对购物应用程序不是很熟悉，但是当我想到它时，我想到了这些要点：

销售商品/产品应该有另一个概念，而不是商品/产品。因为，“产品概念”应该独立于“可以对产品做什么”。例如，销售产品与产品本身的概念不同。因此，您可能有另一个类，如orderItem。

class product {
    Long productId
    String productName
    ...
} 

class orderItem{
      Product soldProduct;
      Invoice itsInvoice;

      public Invoice getItsInvoice();

}

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

}

如果您这样做，则每个订单商品仅属于一个发票，而发票可能包含许多订单商品。因此，ivoice和订单商品之间存在一对多的关系，以及oreritem和product之间的一对一关系。

即使如果你仍然只用两个实体，发票和产品来做，这意味着你将“产品”和“销售产品”的概念结合在一个实体中，发票和产品之间的关系仍然是一对多的许多到很多。因为，两者之间的关系是通过“销售产品”。在这种情况下，“销售产品”仅属于一张发票。

但是，第一种方法对我来说似乎更好。

Answer 3

这是一对多场景，而不是多对多场景。同一产品不能成为许多发票的一部分。