UML Class Diagrams - Troppe associazioni?

Question

UML Class Diagrams - Troppe associazioni?

#1 da (3 voti)
#2 da (1 voti)

2

Ho recentemente iniziato un corso di sviluppo software e sto avendo un po 'di confusione sulla modellazione del mio sistema in un diagramma di classe. Il contesto del sistema è il seguente: L'utente desidera calcolare le prestazioni (consumo energetico e temperatura di uscita) di un'unità di condizionatore d'aria a una particolare temperatura di ingresso. Un pezzo di codice calcola ciò in base agli input forniti e alle proprietà dell'unità di coniazione. Questo calcolo (input, output, modello aircon) è registrato in un file.

Non sono sicuro di quante associazioni sono richieste per questo modello. Questo è quello che ho modellato finora:

design object-oriented-design uml

posta SimStil 06.06.2018 - 13:57

fonte

2 risposte

Leggi altre domande sui tag design object-oriented-design uml

Ottimizzazione delle applicazioni Web Come ti senti nei browser per entrare nelle complessità di basso livello?

score 3 · Answer 1

Non esiste un limite specifico al numero di associazioni, ma se tutto è collegato a tutto il resto, probabilmente c'è qualcosa di sbagliato nella progettazione e sarà terribile da implementare.

Man mano che il design si evolve, la maggior parte dei link dovrebbe finire unidirezionale, e la maggior parte dovrebbe finire per essere più specifica delle sole associazioni. I tipi comuni di collegamento sarebbero A "è a" B (eredità), A "ha a" B (contenimento) e A "utilizza" B (associazione semplice).

Una volta che la maggior parte dei collegamenti è stata resa unidirezionale, dovrebbe essere possibile ridisegnare il diagramma come una bella gerarchia, senza dipendenze circolari o frecce che vanno "nel modo sbagliato".

score 1 · Answer 2

Dovresti inserire nel diagramma delle classi tutte le classi e le associazioni di cui hai bisogno, indipendentemente da quante. Ma non di più.

Quindi lasciatemi sfidare il tuo diagramma:

Avrai davvero una classe PerformanceFile con proprietà e metodi? Oppure il file è solo un artefatto creato da un Calculator dopo l'invocazione di uno dei suoi metodi (ad esempio savePerformanceFile(filename) ?
Quali sono le differenze tra le condizioni di ingresso e di uscita? Sono questi lo stesso tipo di condizioni (ad esempio temperatura, umidità, pressione, ...) ma con una fonte diversa (ad esempio input e output)?
Esiste una relazione strutturale tra Calculator e le condizioni che utilizza per il calcolo? O semplicemente accede alle condizioni misurate dall'AirConditionner?

Con le ipotesi 1) No, 2) Diverso, 3) No, 1 calulatore per 1 unità, vedrei un diagramma con molto meno relazioni:

I

Hodettagliatoalcuneproprietàemetodi,soloperchiarirelaresponsabilitàdelleclassi.Masemantienilelezioniavraiundiagrammamoltopiùsemplice.

Notaimportante:selacalcolatricemisuralecondizioni,lecondizionisarannocollegatealcalcolatoreanzichéalcondizionatored'aria.Inquestocaso,selacalcolatricepotessecontrollarepiùunitàdicondizionamento,sarebbenecessariocollegarelecondizionisiaallacalcolatricecheall'unità: