L'UML standard specifica come una variante (ovvero unione con tag, unione discriminata, tipo di somma, ecc.) dovrebbe essere rappresentata in un diagramma di classe?
Il linguaggio di modellazione unificato non sta tanto unificando i paradigmi di programmazione. È drammaticamente focalizzato sulla programmazione orientata agli oggetti (quindi, ad esempio, il suo diagramma più popolare è il diagramma class ). Al contrario, i tipi di somma sono in genere una caratteristica dei linguaggi funzionali (come F #, Haskell, ecc.).
Ho paura di informarti che UML non è probabilmente una buona scelta per modellare programmi che saranno sviluppati con un linguaggio funzionale. Sfortunatamente una grande borsa delle loro caratteristiche non ha corrispondenze dirette in UML. Le funzionalità che formano il pane e burro di FP, come le funzioni di prima classe, i costruttori di tipi, ecc., Sono fastidiose da rappresentare in UML, o completamente estranee.
Se è necessario rappresentare i tipi di somma, è possibile modellare una rappresentazione vicina alla loro implementazione in Scala, dove si definisce effettivamente una classe base / tratto / interfaccia e si derivano i singoli tipi di somma. Qualcosa di simile (semplificato):
sealed trait Option[+A]
case object None extends Option[Nothing]
case class Some(value : T) extends Option[T]
Naturalmente, non riuscirai a modellarlo in molti aspetti (trait? case class? covariance? sealed?), ma questa è la mia esperienza generale quando provi a modellare le caratteristiche non OOP in UML.
Un classificatore in UML può comprendere più sottoclassificatori che formano qualcosa che chiamano un "set di generalizzazione" che può essere un partizionamento completo delle istanze di una superclasse. C'è una notazione grafica per questo nei diagrammi delle classi. Quindi, puoi avere un classificatore C che ha sottoclassi P Q R ... con la proprietà che qualsiasi l'istanza di C deve essere un'istanza di esattamente una tra P Q R ... Quella che è la più vicina Sono stato in grado di venire a una visualizzazione UML dell'unione. Le persone OOP sembrano pensare alla superclasse "venendo prima" e poi derivano le sottoclassi, che non è proprio la stessa "sensazione" della prospettiva sindacale che riguarda la definizione di C in termini di P Q R . Ma se si pensa al diagramma di classe UML come a descrivere possibili grafici di oggetti run-time piuttosto che a rappresentare il codice sorgente, l'insieme di generalizzazione con una superclasse che non ha attributi o operazioni potrebbe essere vicino a ciò che si desidera.
I diagrammi delle classi UML sono davvero inadeguati per rappresentare visivamente le relazioni logiche di base come la disgiunzione, ecc.
Probabilmente si potrebbe usare Composition per indicare i sindacati con tag in un diagramma di classe UML. La composizione è la relazione "ha una" e un'unione con tag ha un tag e un valore. Puoi utilizzare la molteplicità, i nomi dei ruoli o gli indicatori di proprietà.
Tuttavia, qualcosa da considerare è che i diagrammi di classe sono tipicamente orientati a rappresentare le relazioni di classe in un linguaggio orientato agli oggetti. Altri tipi di diagrammi possono essere meno specifici per l'orientamento agli oggetti, come diagrammi di distribuzione o diagrammi dei componenti. Puoi prendere in considerazione altre notazioni che vanno oltre l'utilizzo di UML e enfatizzare chiaramente la comunicazione di un disegno rispetto a uno standard.
Leggi altre domande sui tag functional-programming algebraic-data-type uml