nome Ruolo nel rapporto di associazione

Question

come ho letto attraverso UML bibbia sul ruolo

ruoli: un nome di ruolo spiega come un oggetto partecipa alla relazione.

"Ogni oggetto deve mantenere un riferimento all'oggetto o oggetti associati. Si tiene il riferimento in un valore di attributo all'interno object.When c'è solo un'associazione allora c'è solo un attributo possesso di un riferimento."

1) cosa significa la frase citata?

2) Mi chiedo se ci sia qualche esempio per spiegarlo un po '?

Answer 1

Roles:A role name explains how an object participates in the relationship.

si hanno due classi, Professor e Book e si sono associati come nel seguente schema:

Il ruolo fornisce una descrizione dell'associazione tra Professore e Libro. In questo caso il Professore è lo scrittore del libro associato.

Each object needs to hold a reference to the associated object or objects. The reference is held in an attribute value within the object.

Per questo userà un altro esempio di uno a uno molteplicità.

Il diagramma mostra che Query builder ha una query (e viceversa). Come viene rappresentata questa associazione nel codice?

Si dispone di una classe QueryBuilder che ha un attributo di tipo Query denominato query. In Codice:

class QueryBuilder { 
    Query query; 
} 

E si dispone di una query classe che ha un attributo di tipo QueryBuilder nome qbuilder

in codice:

class Query { 
    QueryBuilder qbuilder; 
} 

L'attributo (query per la classe QueryBuilder e QBuilder per la classe Domanda) è il reference to the associated object

When there is only one association then there is only one attribute holding a reference

Nell'esempio precedente, c'era un'associazione, quindi avevamo un attributo (campo) nella classe per mantenere il riferimento dell'oggetto associato.

Nello schema seguente Acount ha due associazioni con BookItem.

Così, Account classe avremo due campi, un campo per ogni associazione.

class Account { 
    BookItem[] borrowed; 
    BookItem[] reserved; 
} 

Si noti che queste associazioni sono uno a molti, in modo che i campi che abbiamo per le associazioni sono matrici che possono tenere più di un BookItems.

Here è possibile trovare un buon articolo in cui ho preso in prestito la maggior parte degli esempi per questa risposta.

EDIT: Spiegazione dell'associazione tra Author e Book.

La linea che collega Author e Book nel diagramma è la visualizzazione dell'associazione. Questa è un'associazione bidirezionale, il che significa che Author uno o più oggetti Book (i libri scritti dall'autore) ma anche Book ha uno o più oggetti Author (perché il libro può avere più di un autore). Un'associazione con la molteplicità molti (uno o più) viene solitamente implementata con una raccolta o una matrice. La classe Author ha un campo che può essere una raccolta o un array di Book. Il diagramma non fornisce il nome di questi campi.

Il primo diagramma che associa Professor con Book fornisce anche i nomi di questi campi. Professor ha un campo con il nome textbook per mantenere gli oggetti Book. Book ha un campo con il nome author per mantenere gli oggetti Author. Il tipo di questi campi non è fornito dal diagramma. Il campo textbook potrebbe essere dichiarato come qualcosa dal seguente:

Book[] textbook; 

o

Set<Book> textbook; 

o

List<Book> textbook; 

o

Collection<Book> textbook; 

Anche la visibilità dei campi è no t fornito (potrebbe essere predefinito, privato o pubblico).

C'è una buona ragione per cui questa informazione è omessa dal diagramma di classe: l'autore del diagramma non lo considera importante per il messaggio che vuole comunicare con il diagramma. Non dobbiamo dimenticare che i diagrammi UML sono usati per aiutare la comprensione di un sistema visualizzando alcuni dei suoi aspetti. Generalmente creiamo più di un diagramma per fornire diverse prospettive di un sistema. Nella maggior parte dei casi l'elemento di informazione più importante è la relazione tra le classi. Quindi i dettagli di implementazione sono spesso omessi. Nota che ci sono molti dettagli di implementazione riguardanti l'associazione Book - Author che sono omessi da questi diagrammi. Come forzare che Book avrà sempre almeno uno Author o come assicurarsi che se uno Book ha un Author allora anche lo Author ha questo Book tra i dettagli che vengono omessi.