Domanda

Di solito mi confondo così tanto con UML e questa situazione non è diversa. Diciamo che ho un'interfaccia IAnimal, classe Food and Cat:

interface IAnimal {
    void Feed(Food food);
}

class Cat : IAnimal {
    void Feed(Food food) {
        //code
    }
}

Ho 3 domande sul disegno del diagramma di classe UML per questi 3 elementi:

  • Presumo che dovrei usare l'associazione tra IAnimal e Food o Cat and Food. Dovrebbe esserci una freccia su un lato della linea di associazione, se sì, quindi su quale lato e perché lì?

  • se scrivo Feed come metodo IAnimal sul diagramma, dovrei scrivere un metodo Feed all'interno della classe Cat o devo scrivere solo altri metodi Cat?

  • il più importante: l'associazione dovrebbe essere tra IAnimal e Food, Cat and Food o entrambi?

È stato utile?

Soluzione

UML definisce un certo numero di relazioni tipi.

Le relazioni hanno un numero di notazioni diverse:

  • Le relazioni di associazione hanno una notazione di base di un percorso solido
  • Le relazioni di dipendenza hanno una notazione di base di una freccia tratteggiata
  • Le relazioni di generalizzazione hanno una notazione di base di un percorso solido con una freccia triangolare
  • Le relazioni di realizzazione hanno una notazione di base di una freccia tratteggiata con una punta di freccia triangolare (un mix di dipendenza e generalizzazione)

Pittoricamente

+---------------------------+
|       <<interface>>       |
|           IAnimal         |
+---------------------------+                        +--------+
| + Feed(food: Food) : void |- - - - <<use>> - - - ->|  Food  |
+---------------------------+                        +--------+
              ^
             /_\
              |

              |

              |
        +-----------+
        |    Cat    |
        +-----------+

Cioè:

  • La relazione tra IAnimal e Food è una relazione utilizzo . Questo è mostrato come una dipendenza con lo stereotipo «usa»
  • La relazione tra IAnimal e Cat è una realizzazione .

Le relazioni di associazione vengono utilizzate per indicare connessioni tra due o più classificatori. Ciò implica che almeno una delle classi ha un attributo dell'altro tipo (o una raccolta). In effetti, gli attributi e le estremità dell'associazione contengono le stesse informazioni e possono essere scambiate.

Quindi, IMHO, le relazioni che descrivi non dovrebbero essere modellate come associazioni.

Altri suggerimenti

Supponendo un diagramma di classe, dovresti avere un " usa " l'associazione tra IAnimal e Food e un " è un " associazione tra Cat e IAnimal e Dog e IAnimal:

    IAnimal ----> Food
     ^   ^
    //   \\
   //     \\
 Cat      Dog

Quanto sei esigente riguardo a questo tipo di cose dipende in gran parte da ciò che stai usando UML per primo.

Se hai una specie di traduttore da UML a codice sfrenato, allora devi essere pignolo (ma sembra che tu sia più a tuo agio con il codice che con le caselle e le linee - quindi perché dovresti usare un tale strumento? )

Se stai semplicemente usando UML per comunicare con altre persone, puoi permetterti di essere un po 'meno esigente.

Craig Larman " Applicazione di UML e Pattern " sottolinea questo punto, includendo diagrammi che sembrano disegnati su una lavagna. Una linea continua che lo standard UML dice che dovrebbe essere punteggiata va bene in quel tipo di diagramma. Quindi con punte di freccia e così via.

Mi è chiaro che la linea dovrebbe andare da IAnimal a Food .

Se la punta della freccia aggiunge chiarezza (per i lettori umani) è una questione di scelta, ma indica una relazione unidirezionale:

Da questo pezzo introduttivo:

  

" In un'associazione unidirezionale, due   le classi sono correlate, ma solo una   la classe sa che la relazione   esiste ".

Direi che IAnimal avrebbe HAVE-A Food, dal momento che è metabolizzato, ma se vuoi davvero denotare HAS-A penso che dovrebbe essere un simbolo di aggregazione (diamante aperto) o composizione (diamante riempito), a seconda delle caratteristiche di eliminazione a cascata.

Ci sono due scuole di pensiero con UML, secondo Martin Fowler. Ci sono gli "sketcher" che usano la notazione su lavagne e pezzi di carta dispari per comunicare abbastanza idee ai colleghi sviluppatori.

Poi ci sono quelli che vedono UML come disegni tecnici, in cui ogni dettaglio di un disegno deve essere catturato.

Sono fermamente nel vecchio campo. Come ex ingegnere, posso dirti per esperienza personale che UML non ha il potere di veri e propri disegni tecnici di catturare completamente un progetto software.

Se ti capita di credere in quest'ultimo caso, esegui una progettazione dell'interfaccia utente Web o desktop completa utilizzando UML e pubblicalo qui.

1) Nessuna associazione deve essere scritta tra l'interfaccia IAnimal e il tipo Food. Le associazioni vengono utilizzate solo per connettere tipi con proprietà all'interno delle classi. Per esempio

class Animal
{
   Food foodEaten;
}

class Food
{
 //Implementation code
}

quindi dovresti scrivere un'associazione che indichi la connessione tra questi due tipi.

Ciò che dovresti disegnare è invece una dipendenza che indica che l'interfaccia IAnimal dipende dal tipo di cibo. La dipendenza è disegnata come l'associazione nella figura sopra, basta cambiare la linea retta in una tratteggiata.

2) No, non scrivere questi metodi e non scrivere le dipendenze. Lascia tutte le notazioni solo sull'Interfaccia IAnimal

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top