Lo stereotipo di classe è implicito in un diagramma di classe UML? Dovrebbe essere specificato?
Comunemente vedo diagrammi di classe in cui non c'è <<class>>
stereotipo. Altri dove c'è il comune <<interface>>
e altri con alcuni interessanti come <<shape>>
o <<computer>>
e così che per un diagramma di classe personalmente non vedo la necessità ma ok.
Sto creando un diagramma UML per un moderno progetto di algebra in C++, ma come sappiamo il linguaggio non dovrebbe essere così influente quando si lavora con UML. Per questo progetto ho riconosciuto gli <<interface>>
e gli <<abstract>>
stereotipi tutti bene fino a questo punto, ma ci sono strutture e classi, voglio fare le cose nel miglior modo possibile quindi sono arrivato a chiedermi quali sono <<class>>
gli <<struct>>
stereotipi validi?
Ringrazio gentilmente le vostre risposte o commenti.
Nota: penso che struct
dovrebbe essere valido perché specifica il tipo per una determinata implementazione.
Risposte
Non è necessario indicare per indicare le classi in modo esplicito in un diagramma di classe: si presume per impostazione predefinita, secondo UML:
Una classe viene mostrata utilizzando il simbolo del classificatore. Poiché Class è il classificatore più utilizzato, non è necessaria alcuna parola chiave per indicare che la metaclasse è Class.
Sei libero di definire i tuoi stereotipi in UML. Sono meglio documentati in un diagramma di profilo che mostra come si relazionano agli elementi UML standard.
UML è neutrale rispetto al linguaggio di implementazione. È molto tipico definire tipi di dati specifici della lingua (ad esempio float
, double
che non appartengono allo standard UML) e stereotipi (ad esempio class
e struct
). Vedi ad esempio qui un C# profile , per un linguaggio in cui classi e struct hanno semantiche diverse.
Tieni presente che non tutto ciò che è compreso tra « »
, che sembra uno stereotipo, è uno stereotipo. Può anche essere una parola chiave ben definita:
- interfaceè una parola chiave che si riferisce a qualcosa con un chiaro significato nel metamodello UML, condiviso tra diagrammi di classe e diagrammi di componenti.
- enumerationè una parola chiave che fa riferimento a un tipo speciale di tipo, che deve essere descritto in modo diverso rispetto ad altri tipi e classi di dati di base.
Due osservazioni molto importanti in aggiunta:
- L'introduzione di stereotipi specifici della lingua rende il modello di progettazione meno generale e comporta il rischio di ottenere modelli di implementazione dettagliati piuttosto che concentrarsi sulla progettazione astratta. Dovresti quindi pensare ai pro e ai contro. Se il tuo modello è neutrale rispetto alla lingua, potresti concentrarti su OOD e lasciare che venga riutilizzato per una porta java o C #, ad esempio. Se il tuo intento principale è creare un modello di implementazione, ovviamente non è un problema.
- In C++ a
struct
è aclass
con tutti i membri pubblici per impostazione predefinita. Questo è un principio fondamentale del linguaggio. La differenza riguarda solo il controllo degli accessi. Poiché in UML si documenta il controllo degli accessi a livello di membro, avere uno stereotipo« struct »
che richiede che tutti i membri siano pubblici sembra semplicemente ridondante. Consiglierei di utilizzare invece classi non stereotipate in UML e decidere nell'implementazione di utilizzare una struttura o una classe a seconda della visibilità dei membri.