UML, Astrazioni e Relazioni Astrazione

Astrazione
• prendi qualcosa di concreto e lo fai diventare un
UML,
Astrazioni e Relazioni
Prof. A. Calvagna
• generalizzi: elimini i dettagli superflui, mantieni solo
le proprieta’ significative
2007
• Vari livelli d’astrazione possibili
• Al livello piu’ basso (il concreto):
• ho un solo oggetto per tipo: ogni oggetto concreto
ha sempre qualcosa di diverso da tutti gli altri
•
concetto, una categoria
il mio paio di nike e’ ben diverso dal tuo paio di nike.
• ogni livello di astrazione superiore individua un
insieme sempre piu’ ampio di oggetti equivalenti
• caratterizzati dalle stesse proprieta’ strutturali
e funzionali (attributi e operazioni)
• Esempi:
• corriere della sera - giornale - media
• nike “runners” - scarpa da ginnastica - calzatura
• for (; ;) - loop infinito - ciclo
Date due astrazioni A e B
A Generalizza B
A Realizza B
A Dipende da B
A Associata a B
A Aggrega B
A Compone B
Class A
Class B
Class A
Interface B
Class A
Class B
Class A
Class B
Class A
Class B
Class A
Class B
Generalizzazione (IS-a)
• A generalizza B: ogni istanza di tipo B e' anche
vita indipendente
• A possiede B (lo gestisce)
• B e’ sì una parte di A, ma non solo di A
• A e B sono astrazioni di pari livello.
• A ha al suo interno un insieme (in senso
A e’ una astrazione di livello piu’ alto rispetto a
B: un insieme di oggetti piu’ ampio e generico.
• in genere, A e’ consequenziale a B
una istanza di tipo A
• Si parte da B e si astrae ancora definendo A
(possibile anche percorso inverso)
• Le rispettive istanze dei due tipi hanno ciclo di
•
Composizione
(Has subpart)
• B e’ una parte di A
• B non e' un A ma ne e’ una sua parte integrante,
imprescindibile
•
Aggregazione (Has)
B e' sensata solo nel contesto di A
• puo' essere istanziata solo da un A (quindi
dopo di A)
• A e’ una astrazione di livello piu’ alto rispetto a B.
matematico) di B
Ciclo di vita di una
istanza
• creazione: chi dedice quando e’ il momento
di allocarla?
• accesso: chi si preoccupa di mantenere un
riferimento valido alle istanze esistenti?
• distruzione: chi decide quando eliminare una
istanza?
Prerogative di A su B
Responsabilità
=>
creazione accesso distruzione
istanze istanze
istanze
legame
nel codice...
Relazione
generalizzazione
no
no
no
realizzazione
no
no
no
dipendenza
no
no
no
associazione
no
no
no
aggregazione
no
si
no
composizione
si
si
si
tra tipi:
A astrazione di B
con le proprietà B
A super di B
A implements B
parametri
con l’impl. di B
di tipo B in A
strutturale,
attributi di tipo B in A
“relazione” in AxB
e viceversa
strutturale,
attributi di tipo B in A
“whole-part lasco”
ma non viceversa
strutturale,
attributi di tipo B in A
“whole-part stretto” con B inner class di A
CLASSI
INTERFACCE
CLASSI ASTRATTE
Classe
Esempio
• sintassi per l’astrazione
• definisce le proprietà strutturali (attributi) e funzionali
• e' un “orologio” qualsiasi cosa che...
• mantiene internamente informazione
(operazioni) caratterizzanti una categoria (un tipo) di
oggetti
• distintive rispetto alle altre categorie.
• associata ad un’unica implementazione, completa,
condivisa da tutte le sue istanze
sull’ora (attributo)
• mi consente di leggerla/regolarla
(funzionalita')
• ma solo ed esclusivamente questo!
Interfaccia
• sintassi per una porzione di astrazione
• definisce un set di proprieta’ caratterizzanti un solo
aspetto specifico
• non distintivo di un’unica astrazione (non definisce un tipo)
• senza una implementazione associata
• trasversale a piu’ astrazioni esistenti (che la implementano)
• può quindi avere molte implementazioni diverse, tutte
valide allo stesso tempo.
Classe Astratta
•
sintassi per una particolare astrazione la cui
implementazione non e’ (del tutto) definibile.
•
•
•
le sue istanze sono oggetti non funzionanti (astratti)
definisce comunque un tipo completo (struttura e
funzioni)
Le sottoclassi devono completare l’implementazione,
ciascuna a modo suo
Esempio
•
•
Cosa è “iterabile”?
qualsiasi cosa che mi consenta: first(), last(), next(), prev(), isDone()...
ma non per forza solo questo!
•
•
implements Runnable vs extends Thread
• definisco un legame tra i tipi, introducendo di fatto un nuovo tipo
di thread:
• class MyThreadedClass extends Thread
• class MyThreadedClass extends MyClass,Thread
• dico solo che il mio tipo avrà anche un proprio thread di
esecuzione:
• class MyClass implements Runnable
• NB: linguaggi senza ereditarietà multipla:
• eliminata dai progettisti per semplificare i compilatori
• le interfacce non vanno usate per compensarne la mancanza
Esempio
• Cosa e’ una figura geometrica?
• un insieme di lati
• area(), perimetro()
• ...impossibile implementarla senza sapere lo
specifico (sottotipo) di figura (cerchio,
triangolo, ecc.).