Confusione sulle associazioni nel diagramma delle classi UML

2
---------------------    ----------------------
|       FLIGHT      |    |       STEWARD      |
---------------------    ----------------------
| Arrival time      |    |  Steward ID        |
| Departure time    |    |  Name              |
| Flight ID         |    ----------------------
---------------------    | Call()             |
| Board()           |    | HelpPassenger()    |
| Depart()          |    ----------------------
---------------------

Oggi è stata la mia prima lezione su UML nei diagrammi delle classi. La mia insegnante mi ha chiesto di modellare questo diagramma di classe. Ho molte confusioni su quale associazione dovrei usare. Ho una certa esperienza in ERD e OOP.

  1. Dubito di ciò che dovrei chiamare la mia associazione. Dovrebbe essere "un volo ha * stewards"? O dovrebbe essere "un steward funziona su molti voli"?

  2. Devo specificare la molteplicità (1 .. * ecc.) su entrambi i lati?

  3. Il mio insegnante non ha ancora trattato composizioni e aggregazioni, ma temo che se uso solo associazioni regolari potrei fare qualcosa di sbagliato. Puoi fare un diagramma di classe con le sole associazioni? Considereresti un diagramma di classe più complesso sbagliato se non usa composizioni / aggregazioni?

  4. Ho letto che non c'è consenso su quali aggregazioni precisamente si intende. Quindi, perché dovremmo usare qualcosa se non esiste una definizione formale?
posta user1534664 11.12.2014 - 22:39
fonte

2 risposte

5
  1. I am doubting what I should name my association. Should it be "a flight has * stewards"? Or should it be "a steward works on many flights"?

Di solito, più specifica è la tua associazione, meglio è, perché un nome più specifico trasmette più informazioni.

D'altro canto, se stai usando un'associazione direzionale (hai messo una punta di freccia su un'estremità), allora il nome deve avere senso quando vai nella direzione della freccia.
Ad esempio, se hai Flight --> Steward , non puoi assegnare il nome a quell'associazione "funziona", perché non ha senso dire "Flight X funziona su Steward Y".
Se hai un'associazione non direzionale (nessuna punta di freccia, puoi seguirla in entrambe le direzioni), ma il tuo nome ha senso solo quando viene letto in una particolare direzione, puoi opzionalmente indicarlo mettendo una piccola freccia / triangolo inclinato accanto al nome, in questo modo:

+--------+                +---------+
| Flight |   < Works On   | Steward |
|        |----------------|         |
+--------+                +---------+

Questo significa che l'associazione dovrebbe essere letta come "Steward Y funziona su Flight X".

  1. Should I specify the multiplicity (1..* etc) at both sides?

Se la molteplicità può essere dedotta dal contesto, puoi lasciarla fuori.
Ma come principiante, potrebbe essere meglio essere espliciti sulla tua molteplicità intesa.
Scrivi il numero di molteplicità su entrambi i lati dell'associazione, in questo modo:

+--------+                  +---------+
| Flight |2..4 < Works On  1| Steward |
|        |------------------|         |
+--------+                  +---------+

Questo significa che ogni volo ha esattamente 1 Steward e ciascun Steward funziona tra 2 e 4 voli (né più né meno).
Un limite superiore sconosciuto a un intervallo può essere indicato con un * , come 2..* per "due o più". Come abbreviazione, solo * rappresenta 0..* .

  1. My teacher hasn't covered compositions and aggregations yet, but I'm afraid if I only use regular associations I might be doing something wrong. Can you make a class diagram with just associations? Would you consider a more complex class diagram wrong if it doesn't use compositions/aggregations?

No, non prenderei in considerazione un diagramma di classe senza composizioni / aggregazioni errate. Il rischio maggiore che si corre quando si utilizza un tipo di associazione inappropriato è che non si trasmette il significato desiderato o che è necessaria documentazione aggiuntiva per trasmetterlo.

Per gli esercizi in classe, non mi preoccuperei della necessità di concetti che non sono stati ancora discussi in classe. O non sono necessari per completare l'esercizio ad uno standard elevato, o ci sarà un esercizio successivo per perfezionare il tuo diagramma attuale con i nuovi concetti quando saranno discussi.

  1. I read that there's no consensus on what aggregations precisely means. So why would we use something if there's no formal definition?

Semplice associazione, aggregazione e composizione si riferiscono ciascuna a un diverso punto di forza della relazione tra due classi. Tutti concordano sul fatto che una semplice associazione indica il tipo più debole di relazione, la composizione il più strong e quella aggregazione è da qualche parte nel mezzo.
Qual è il disaccordo su quanto sia strong una relazione quando viene indicata con l'aggregazione (dove si trova nel mezzo della scala della forza) e come tale relazione dovrebbe essere implementata nelle varie lingue.

Il motivo per cui è ancora usato è perché spesso è utile avere più di due livelli per indicare la forza di una relazione tra due classi.

    
risposta data 12.12.2014 - 12:45
fonte
1

Ai miei occhi non esiste una relazione da molti a molti. C'è un concetto cruciale che si perde nella mescolanza quando ci si basa su una relazione molte a molte.

Diamo un'occhiata a un diagramma che ho realizzato per il tuo scenario

Qui ho modellato il tuo dominio usando la modellazione basata sul colore. Un piano (persona / luogo / cosa) ha 0 o più voli (intervallo dei momenti). Ogni volo ha più incarichi per il personale che possono essere uno stipendio o un pilota (ruoli), c'è un incarico personale per ogni pilota o comandante in un volo. Quindi è da 1 a molti da Flight to Assignment e Many to one da Assignment a Steward o Pilot.

Nota che ho modellato la relazione tra l'Assegnazione allo Steward / Pilot come aggregazioni. Lo Steward e il Pilota esistono al di fuori del regno dell'Assegnazione. Tutti gli altri che ho rappresentato come composizioni. IE a Flight esiste solo nel contesto di un aereo (non c'è un volo senza un aereo), nello stesso senso non c'è nessun incarico senza un volo. Questa è la differenza tra composizione e aggregazione.

In alternativa, puoi scegliere di modellare FlightAssignment come PlaneStaffAssignment (ad esempio, questo è l'equipaggio che lavora sull'aereo in questo momento). Dovresti quindi attraversare la relazione per vedere chi è stato assegnato all'aereo per quale volo. Tutto dipende da cosa è più importante per te.

    
risposta data 12.12.2014 - 00:53
fonte

Leggi altre domande sui tag