Note UML

Post date: Nov 26, 2014 12:28:43 PM

I connettori

• Aggregation __<>

  • E'un tipo di associazione che mostra un elemento che contiene o è costituito da altri elementi.

  • Viene utilizzato in modelli di classe, modelli di pacchetti e modelli di oggetti per mostrare come elementi più complessi (aggregati) sono costruiti da un insieme di elementi semplici (componenti), ad esempio, una macchina è composta da ruote, pneumatici, motore e così via.

• Association __

• Una association implica che due elementi del modello abbiano un rapporto, che di solito è implementato come una variabile di istanza in una Classe. Questo connettore può includere i nomi dei ruoli ad ogni estremità, la molteplicità, la direzione e vincoli. Association è il tipo di relazione generale tra gli elementi. Per collegare più di due elementi in una associazione, è possibile utilizzare l'elemento N-Ary Association.

• Quando viene generato il codice per i diagrammi di classe, association diventano variabili di istanza della classe di destinazione. Questa relazione è utilizzata anche in Package, Object, Communication, Data Modeling e Deployment diagrams.

• Composition __<@>

• Una composition è usata per rappresentare un elemento che si compone di altri componenti che lo costituiscono, tipicamente in una classe o package diagramma. Un componente (o parte istanza) può essere incluso in un massimo di una composizione per volta. Se una composition viene eliminata, in genere tutte le sue parti sono cancellati con essa; tuttavia, una parte può essere rimossa singolarmente, senza dover cancellare l'intera composition. Le composition sono transitive (se a = b e b = c, allora a = c), relazioni asimmetriche e possono essere ricorsive.

• Dependency --->

• Relazione tra due elementi del modello, in cui la modifica di uno di essi (quello indipendente) può generare ripercussioni sull'altro (quello dipendente). Relazioni dependency sono utilizzate per modellare una vasta gamma di relazioni di dipendenza tra elementi del modello in Use Case, Activity e Structural diagrams, e anche tra i modelli stessi. La dependency definita in UML 2.3 ha molti derivati, come Realize, Deployment e Use. Una volta creata una dipendenza è possibile raffinare ulteriormente il suo significato, applicando uno stereotipo specializzato.

• Extend -=->

• Extend viene usato per indicare che un elemento estende (aggiunge nuove funzionalità) il comportamento di un altro. Le estensioni sono utilizzati negli Use case models per indicare che un caso d'uso (opzionale) estende il comportamento di un altro. Un use case che si estende, esprime spesso flussi alternativi. (Es.: il telecomando può estendere la televisione [entrambi funzionano indipendentemente ma il telecomando estende le funzionalità di un televisore])

• Es.: Acquista prodotto <- extend Registra Account (Se si registra un account si ottiene la funzione opzionale di poter acquistare un prodotto. Il punto di estensione è: "account non registrato")

• Es.: Emetti un ordine Urgente -> extend Emetti un ordine (in questo caso abbiamo un punto di estensione che è la "priorità", quindi sul segmento di collegamento possiamo mettere in evidenza "definisci priorità")

• Ragionamento: Se faccio ottengo

• Generalizzation __|>

• Una generalizzation è usata per indicare l'ereditarietà. Il collegamento va da uno specifico classificatore a quello generico, questo implica che il figlio eredita le caratteristiche del padre. È usato tipicamente in Class, Component, Object, Package, Use Case e Requirements diagrams. Negli use case posso definire diversi comportamenti (figlio) per risolvere un determinato caso d'uso generale (padre).

• Include -=->

• Un include indica che l'elemento sorgente include la funzionalità dell'elemento di destinazione (che è indipendente da esso e riutilizzabili in altri casi d'uso distinti). Include è usato nei Use case models per indicare che un caso d'uso include il comportamento di un altro. Utilizzare una relazione include per evitare di avere lo stesso sottoinsieme di comportamento in molti use case; questo è simile a delegation utilizzato nei Class models.

• In EA posso rappresentarlo come la deviazione nel testo di un caso d'uso, come approfondimento di uno dei vari punti dello stesso.

• Es.: 7 - Il cliente paga e il sistema gestische il pagamento

• 7b.- Pagamento con carta di credito: "Include" Handle credit card payment

• 7c.- Pagamento con assegno: "Include" Handle check payment

• Da usare per evitare ripetizioni dello stesso testo in più casi d'uso diversi

• Es.: Acquista prodotto -> include: Consulta catalogo, effettua pagamento (queste 2 sono funzioni indipendenti e riutilizzabili in altri casi d'uso)

• Ragionamento: Per fare, uso

• Manifest -=->

• Un rapporto manifest indica che la fonte artifact incarna l'elemento del modello di destinazione; in genere Component e Deployment diagrams. Gli stereotipi possono essere aggiunti per classificare il tipo di manifestazione dell'elemento modello.

• Nesting __+0

• Il connettore Nesting è una notazione grafica alternativa per esprimere il contenimento o la nidificazione di elementi all'interno di altri elementi. Esso è più appropriato per la visualizzazione di Package nidificati in Package diagrams.

• Realizzation --|>

  • Un oggetto di origine implementa o realizza il suo oggetto di destinazione.

  • Indica che l'elemento del modello client è un'implementazione dell'elemento del modello del fornitore (la specifica).

  • I connettori realize sono utilizzati in un Use case, Component o Requirements diagram per esprimere la tracciabilità e la completezza del modello. Un processo di business o requisito, è realizzato da uno o più use case, che a loro volta sono realizzati da alcune Class, che a loro volta sono realizzati da un Component, e così via. Mappare requisiti, classi e tutta la progettazione del sistema, attraverso i livelli di modellazione astrazione, assicura che il quadro del sistema ricordi e rifletta tutte le piccole immagini e dettagli che lo limitano e lo definiscono.

• Trace -=->

  • E' una specializzazione di una dipendenza.

  • Correla due elementi di modello o serie di elementi del modello che rappresentano lo stesso concetto a differenti livelli di astrazione o da diversi punti di vista

  • Trace è di solito bidirezionale, informale e raramente computabile (calcolabile).

  • Le trace sono spesso utilizzate per monitorare i requisiti e le modifiche dei modelli.

• Use __>

• La relazione use indica che un elemento richiede un altro per eseguire qualche interazione. Il rapporto d'uso (o d'utilizzo), non specifica come verrà utilizzato dall'elemento di destinazione, diverso da quello del client di origine che lo usa in definizione o attuazione. Un rapporto use è una relazione sotto-tipo di dipendenza.

• Di solito si utilizza use, negli use case diagrams, per modellare come gli attori utilizzano la funzionalità del sistema (Use case), o per illustrare le dipendenze di utilizzo tra Classi o componenti.

Vedi qui per approfondimento

Enterprise architect: UML Connectors

Variazione stati figlio in base a relazione con padre

Associazione: Hanno un rapporto

Aggregazione: Vive senza

Composizione: Muore con lui

Dipendenza: Non centra col padre ma se varia lo compromette

Associazione Binaria 0..1

Una persona (lavora in) Azienda

Responsabilità:

-Conoscere se la persona lavora in un azienda

-Conoscere azienda in cui lavora (se esiste)

-Modificare tale azienda

Classe: Persona

- Attributo: Azienda Lavora in

+ Metodo: getLavoraIn , ritorna Azienda

+ Metodo: setLavoraIn(Azienda)

Activity diagrams VS State diagrams

Gli Activity Diagrams modellano il flusso di controllo da un’attività ad un’altra attività, mentre gli Statechart Diagrams sono usati per modellare il flusso di controllo da evento a evento.

Orientamento associazioni

Esempio di "Composizione" (L'animale non vive senza la testa e la testa nemmeno, l'animale possiede una testa)

Questo tipo di associazione prevede una linea con un rombo pieno su una delle estremità.

Il rombo pieno va attaccato a chi rappresenta il totale ("Whole").

All'altra estremità va collegata la parte ("Part").

Se parto creando un collegamento fra "Animale" e "Testa" dirò che sto creando una composizione verso la parte ("Composition to Part").

Se parto creando un collegamento fra "Testa" e "Animale" dirò che sto creando una composizione verso il totale ("Composition to Whole").

Lo stesso principio si una anche per l'aggregazione solo che il rombo è vuoto.

Esempio di "Aggregazione" (Il museo vive anche senza la statua e la statua vive senza museo, il museo contiene la statua)

Esempio di "Associazione" (Un cuoco lavora in un ristorante e in un ristorante lavorano uno o più cuochi, mente: Un ristorante ha uno o più proprietari)

Se c'è la freccia, l'associazione è mono-direzionale. In questo caso, perché non si ha nessuna informazione riguardo alla relazione che intercorre tra Proprietario e un Ristorante.

Tradotto in classi informatiche, Ristorante conterrebbe un array di n proprietari, ma proprietario non contiene nessuna istanza di Ristorante.

Esempio di "dipendenza" (Carrello dipende da prodotto, perché lo utilizza come parametro di un operazione di aggiunta)

La suddetta relazione indica che una modifica alla classe Prodotto potrebbe richiedere una modifica alla classe Carrello.