UML - Class Diagrams Order - Prodotti

La relazione uno-a-molti tra Order e Product si traduce in un elenco di Products . Ad esempio in Java Order avrebbe un membro di tipo List<Product> .

Tuttavia, ti suggerisco di avere una classe OrderDetail perché scoprirai presto che devi avere e quantità o quantità del prodotto, e non appartiene né all'ordine né al prodotto.

EDIT:

In UML Order avrebbe una "composizione" che è una linea con una forma a rombo nero sul lato Order e una ">" (non un triangolo) sul lato OrderDetail .

Se decidi di utilizzare Product anziché OrderDetail , dovresti avere una "aggregazione" con una forma a rombo bianco.

La differenza è che una composizione significa OrderDetail non ha significato al di fuori di Order considerando che l'aggregazione significa che Products può esistere da solo al di fuori di Order .

Normalmente, hai due classi nel tuo diagramma: Order e Product .

Dato che un ordine di solito significa che il cliente ha ordinato 1 o più prodotti ( 1..* ), lo si modella creando un'associazione dalla classe Order alla classe Product .

Questo coincide con l'aggiunta di una raccolta di istanze di Product alle tue istanze di Order , cioè la maggior parte dei generatori di codice ti fornirà un metodo Order.getProducts() o qualcosa di simile. Di fatto, è possibile aggiungere esplicitamente tale associazione come attributo alla classe Order . Alcuni strumenti nascondono questo fatto, altri ti permettono di vedere chiaramente questa distinzione (ad es. Papiro ) .

I do not know how it would handle the Products

Supponendo che si stia modellando questo per generare tabelle RDBMS, generalmente si usano 2 classi separate. La classe "child" avrebbe gli attributi Product e Product_Id come "foreign key". L'altra classe è la tua classe di ordine.

Il diagramma nella risposta di @Esther Fan - MSFT in UML-frecce-puntatori-spiegazione mostra più di quello che vuoi in effetti, tuttavia, a livello di classe è ciò che desideri. Sostituisci la parola "Order_Item" con la parola "Product" nel diagramma delle classi e ignora le altre classi non correlate al tuo caso.

Il link MSDN fornito all'interno di questa risposta potrebbe essere utile anche per te.

Una regola aziendale importante da tenere in considerazione è se l'occorrenza di un ordine sia significativa senza Prodotti o meno. Il diagramma nel link sopra presuppone una associazione di composizione tra Ordine e Prodotto (Black diamond), questo può o non può essere il tuo caso, quindi per favore controlla.

È anche comune avere una classe per un'entità richiedente e un'entità di riferimento del prodotto mostrata ma non le hai chieste. Ad esempio, dai un'occhiata a: Diagramma classi semplice .

I couldn't have ProductID because that would mean that each item in this class would have to have a separate instance for each product (E.g. someone ordered 100 products, but only placed 1 order).

La situazione di cui sopra non è un problema. Ciascuno dei prodotti userebbe la colonna FK (Order_Id). Il valore in quella colonna sarebbe lo stesso per i 100 prodotti.

Could I have an Product object in class Order?

Sì, ma questo non sostituirà il modello 1-M esistente qui. Guarda un esempio di rappresentazione UML qui: Classe interna interna .

Si noti che nei casi, è necessario programmare strutture di dati per rappresentare raccolte di dati nel codice diverso dalla struttura dati utilizzata per rappresentare le stesse informazioni nel database se si utilizza RDBMS da un'applicazione OO.