Lo stereotipo di classe è implicito in un diagramma di classe UML? Dovrebbe essere specificato?

Aug 15 2020

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 structdovrebbe essere valido perché specifica il tipo per una determinata implementazione.

Risposte

4 Christophe Aug 15 2020 at 13:00

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, doubleche non appartengono allo standard UML) e stereotipi (ad esempio classe 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è a classcon 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.