Relazioni UML - linea tratteggiata contro la linea continua

Question

Qual è la differenza tra queste 2 relazioni?

Edit: Anche se si potrebbe fornire un semplice esempio di codice che illustra la differenza, che sarebbe davvero utile !.

Answer 1

Questa pagina web dice basta Penso: http://www.classdraw.com/help.htm Il seguente testo proviene da esso ma dovrebbe essere sufficiente per capire la differenza credo.

Quindi fondamentalmente la linea continua è un'associazione e la linea tratteggiata/punteggiata è una dipendenza.

associazioni possono anche essere unidirezionale, dove una classe conosce l'altra classe e la relazione, ma l'altra classe non lo fa. Tali associazioni richiedono una punta di freccia aperta per indicare la classe che è nota e solo la classe nota può avere un nome di ruolo e la molteplicità . Nell'esempio, la classe Customer è a conoscenza di qualsiasi numero di prodotti acquistato ma la classe Product non sa nulla di alcun cliente. La molteplicità "0 .. *" significa zero o più.

Una dipendenza è una relazione debole tra due classi ed è rappresentata da una linea tratteggiata. Nell'esempio, esiste una dipendenza tra Point e LineSegment, in quanto l'operazione draw() di LineSegment utilizza la classe Point. Indica che LineSegment deve conoscere il punto , anche se non ha attributi di quel tipo. Questo esempio anche illustra come vengono utilizzati i diagrammi delle classi per concentrarsi su ciò che è importante nel contesto, in quanto normalmente non si desidera mostrare tali dipendenze dettagliate di per tutte le operazioni di classe.

Dal momento che la mia reputazione è solo 8 non riesco a posizionare le immagini, ma possono ancora essere trovate nella pagina web che ho menzionato all'inizio.

[EDIT]

Non ho esempi di codice proprio qui, ma come io personalmente spiegarlo è semplice come una macchina e una porta.

Quando una macchina ha una porta (o più) è solo una macchina

Car --- has a --> Door 

Ma quando si dispone di una porta che può essere aperto la classe porta avrà una funzione come

public void openDoor(){ 
this.open(); 
} 

per utilizzare la funzione sopra la macchina dovrà creare un'istanza della porta

Class Car(){ 
Door door1 = new Door(); 

door1.open(); 
} 

In questo modo è stata creata una dipendenza.

Quindi la linea continua punta semplicemente un oggetto (1) su un altro oggetto (2), ma quando inizi a utilizzare l'oggetto (1) diventa una dipendenza.

Spero che questo farà;)

Answer 2

Va bene, dal momento che non ha accettato la prima risposta; fammi provare.

Arrow 1: un'associazione normale

UML ha diversi tipi di linee e frecce. Sopra è la semplice freccia di associazione, che significa che una classe può avere un collegamento con l'altra classe. Di seguito spiegherò ogni tipo con esempi di codice.

• Nel primo esempio, è possibile vedere che non è stato specificato chi sa chi (chi è il proprietario della relazione). Un animale può conoscere l'umano e l'umano può conoscere l'animale. Non è specificato e quindi non è veramente utile per il programmatore.
• Nel secondo esempio, l'artista PU have avere una chitarra. Perché c'è una freccia e non ce n'è una dall'altra parte, sappiamo che la chitarra non conosce l'artista. Una chitarra è un oggetto che può esistere totalmente da solo e non ha bisogno di nessuno.
• Nel terzo esempio, vedi un matrimonio. Davvero semplice; il marito conosce la moglie e la moglie conosce suo marito. Nella nostra situazione, il marito ha una sola moglie e viceversa.

Come eseguiamo questo UTENTE nel codice?

Poiché il marito ha SEMPRE bisogno di una moglie, mettiamo la relazione OBBLIGATORIA nel costruttore. Perché un artista può avere una chitarra, vorremmo lasciare il costruttore vuoto come questo:

class Artist{ 
    List<Guitar> guitars; 

    public Artist(){ 
    } 

    public AddGuitarToCollection(Guitar newGuitar){ 
     Guitars.Add(newGuitar); 
    } 
} 

Quindi, questo è il modo in cui realizziamo questo nel codice (la maggior parte del tempo!). Di solito non avrai bisogno di diversi tipi di linee e frecce se sei nuovo alla programmazione. Mantienilo semplice.

Arrow 2: Dipendenza

Okay, quindi sappiamo di associazioni normali che utilizzeremo la maggior parte del tempo. Ma quando useremo la freccia 'dipendenza'? Ebbene, consente di definire una dipendenza (wikipedia):

Dependency is a weaker form of bond which indicates that one class depends on 
another because it uses it at some point in time. One class depends on 
another if the independent class is a parameter variable or local variable of 
a method of the dependent class. This is different from an association, where 
an attribute of the dependent class is an instance of the independent class. 
Sometimes the relationship between two classes is very weak. They are not 
implemented with member variables at all. Rather they might be implemented as 
member function arguments. 

Se esiste una connessione, rapporto, ecc associazione che richiede di essere presenti, al classA lavorare; è una dipendenza. Esempio: il marito HA BISOGNO che la Moglie esista. Una macchina ha bisogno di una ruota per essere un'auto (e guidare). Una fabbrica di automobili HA BISOGNO di una classe di macchina per fare un oggetto da essa. La tua classe RSSNewsItem HA BISOGNO di una classe XMLReader per fare qualsiasi cosa.

Quando utilizzare quale?

Bene, questa è l'unica domanda valida ai miei occhi; dal momento che Google mostra un sacco di risposte valide alla tua domanda. Cerca di non usare mai una dipendenza in un diagramma di classe perché di solito significa che non sei abbastanza specifico. Cerca sempre le associazioni, le realizzazioni ecc. Usa solo le realizzazioni (secondo me) se c'è bisogno di usare un'altra classe senza mantenere una relazione. Esempio; Classi di utilità (come XMLReader).

Se avete domande dopo aver letto questa spiegazione completa, sentitevi liberi di chiedere. :-)

Answer 3

attrezzi medi tratteggiate (un'interfaccia) mezzi solidi estende (una classe base)

Answer 4

sto cercando di dare semplici esempi dei due tipi di linee.

Nel primo diagramma, la linea continua indica un'associazione:

Se le classi sono stati dichiarati in Java, questo sarebbe come ClassA memorizzare un riferimento a ClassB come attributo (potrebbe essere passato al costruttore, creato, ecc.). Quindi, si potrebbe vedere qualcosa di simile:

public class ClassA { 
    ClassB theClassB = ... 
    ... 
} 

Nel secondo schema, mostra una dipendenza:

Una dipendenza è molto più debole di un'associazione. Per citare da UML Distilled:

Con le classi esistono dipendenze per vari motivi: una classe invia un messaggio a un altro; una classe ha un'altra come parte dei suoi dati; una classe menziona un'altra come parametro per un'operazione. [...] Usi le dipendenze ogni volta che vuoi mostrare come le modifiche in un elemento possono alterare altri elementi.

Anche in questo caso, l'utilizzo di Java, un paio di esempi esistono: un argomento di tipo ClassB viene passato a un metodo, o un metodo dichiara una variabile locale di tipo ClassB:

public class ClassA { 
    ... 
    public void someMethod(ClassB arg1) {...} 
    ... 
    public void someOtherMethod() { 
     ClassB localReferenceToClassB = ... 
    } 
    ... 
} 

Altri modi ClassA poteva dipendono su ClassB senza avere un'associazione (non esaustivo):

• ClassB ha un metodo statico che ClassA chiama
• ClassA catture eccezioni di tipo ClassB
• Ogniqualvolta ClassB viene modificato, ClassA deve anche essere modificati (per esempio, una certa logica è condivisa)

Answer 5

linea tratteggiata indica dipendenza (nella direzione della freccia). Supponendo che abbiate assemblato il vostro codice sorgente ordinatamente in file separati e intestazioni per ogni classe - il give away è semplicemente che il codice include la riga #include ClassB.h.

TUTTAVIA Il fatto è che tutte le relazioni di classe (generalizzazione, realizzazione, composizione, aggregazione, associazione ecc.) Ereditano la relazione di dipendenza. Per questo motivo non utilizzo mai frecce tratteggiate durante la documentazione del codice. Ove possibile, mirerei a documentare la relazione in termini più specifici, ad es. diamanti, triangoli ecc.Se non conosco la relazione esatta il mio punto di partenza è una linea continua con frecce (un'associazione, con dipendenza (implicita)).

Nonostante ciò, la notazione a freccia tratteggiata può essere utile in altri aspetti della modellazione UML, ad es. ad esempio, mostra le dipendenze dai requisiti in Use Case analysis. NOTA La Polizia di Pensiero vorrebbe che riducessimo le dipendenze tra le classi usando le interfacce (classi virtuali pure) per quanto possibile.

Mentre le classi virtuali pure offrono la prospettiva di ereditarietà multipla e l'accoppiamento più stretto tra tutte le classi possibile. Le classi di interfacce hanno il vantaggio di essere interamente realizzate in materia oscura e quindi totalmente invisibili alla polizia. Con questo in mente è possibile scrivere codice C++ con accoppiamento apparentemente nullo tra le classi, che amano perché non hanno mai veramente capito tutti quei simboli dall'aspetto divertente.

Answer 6

La tua domanda mi ha dato una buona occasione per imparare me stesso, ecco cosa ho trovato -

Associazione: La proprietà di un altro tipo (ad esempio 'A' possiede una 'B')

//@assoc The Player(A) has some Dice(B) 
class Player { 
    Dice myDice; 
} 

Dipendenza: l'uso di un altro tipo (ad esempio 'C' utilizza un 'D')

//@dep The Player(C) uses some Dice(D) when playing a game 
class Player { 
    rollYahtzee(Dice someDice); 
} 

Ecco un ref croccante che ho trovato - Association vs. Dependency