Relazioni tra le classi e rappresentazione mediante diagrammi delle classi UML. Relazioni tra le classi Ereditarietà (is a)...

Transcript

1 Sommario Relazioni tra le classi... 2 Ereditarietà (is a)... 2 Associazione (has a)... 2 Composizione... 2 Aggregazione... 2 Dipendenza (using)... 3 Unified Modeling Language (UML)... 3 Diagramma delle Classi in notazione UML... 4 Rappresentazione di una classe... 4 Diagrammi UML dell ereditarietà... 5 Diagrammi UML delle associazioni... 6 Relazione di associazione... 6 Relazioni di composizione... 7 Relazioni di aggregazione... 8 Relazione di dipendenza... 8 Schemi di progettazione di base... 9 Generalizzazione...11 Design Pattern

2 Relazioni tra le classi Una classe è quasi sempre in relazione con altre classi. Le relazioni possibili tra le classi sono: Ereditarietà (is a) é la relazione che esiste tra una classe più generale ed una più specializzata; viene indicata come relazione is a (o ISA); chi progetta una classe deve cercare di partire da altre già esistenti; ogni classe deve essere progettata in modo da essere facilmente estesa. La classe Impiegato estende la classe Dipendente; un impiegato è un (is a) dipendente Associazione (has a) rappresenta un legame tra istanze di classi; si può pensare come una classe i cui attributi sono oggetti di altre classi; viene indicata come relazione has a (o HasA) Date le classi Persona e Provincia si può definire la classe associazione Residenza con un attributo di tipo Persona e uno di tipo Provincia Date le classi Persona e Automobile si può definire la classe associazione Pilota con un attributo di tipo Persona e uno di tipo Automobile Casi particolari di associazione sono le relazioni intero-parte, come la composizione e la aggregazione che esprimono il contenimento da parte di una classe, e le relazioni di dipendenza tra le classi. Composizione indica le parti di cui è composto un oggetto; i componenti possono essere eterogenei; per esempio: - la classe Cerchio ha come centro un oggetto di classe Punto - la classe Triangolo ha come vertici tre oggetti di classe Punto - la classe Personaggio ha come componenti un oggetto di classe Testa, uno di classe Tronco, due di classe Braccia e due di classe Gamba (ulteriormente scomponibili) Aggregazione è un insieme di parti omogenee; per esempio: - una Biblioteca è un insieme di Libro - una Classe (scolastica) è un insieme di Studente N.B.: Le differenze fra associazione, aggregazione e composizione possono confondere anche i progettisti più esperti essendo a volte molto sottili le differenze fra questi concetti. Dal punto di vista pratico è utile invece sapere come implementare queste associazioni. Solitamente si utilizzano dei riferimenti all altra classe. Per esempio in Cerchio inserisco come attributo un riferimento ad un 2

3 oggetto di classe Punto (il centro), in Biblioteca inserisco come attributo un riferimento ad un array di oggetti di classe Libro, in Residenza inserisco due attributi, uno è un riferimento ad un oggetto di classe Persona e il secondo è un riferimento ad un oggetto di classe Provincia. Dipendenza (using) Una classe dipende da un altra se uno dei suoi metodi usa un oggetto di tale classe in qualche modo. Per esempio, tutte le classi applet dipendono dalla classe Graphics, perché ricevono un oggetto di tipo Graphics nel metodo paint e lo usano per disegnare varie forme. Le applicazioni di console dipendono dalla classe System, perché usano la variabile statica System.out. - il metodo intersezione della classe Retta restituisce un oggetto di classe Punto (il punto d intersezione tra due rette) - il metodo vertice della classe Parabola restituisce un oggetto di classe Punto (che corrisponde al vertice della parabola) - il metodo comprende della classe Retta riceve un oggetto di classe Punto e verifica se esso appartiene alla retta Unified Modeling Language (UML) Per riuscire a comprendere bene un sistema complesso nella sua interezza si utilizzano modelli. Per descrivere graficamente le relazioni tra un insieme di classi inserite in un progetto si usano dei simboli particolari. Le metodologie di analisi usano simbolismi diversi e individuano diversamente taluni tipi di relazioni. UML è un linguaggio di modellazione e specifica basato sul paradigma object-oriented che deriva dalle precedenti metodologie Booch e OMT e che si è affermato come linguaggio universale presso le comunità di progettazione e programmazione a oggetti. Gran parte della letteratura di settore usa UML per descrivere soluzioni analitiche e progettuali in modo sintetico e comprensibile a un vasto pubblico. UML consente di rappresentare più tipi di diagramma: Diagramma dei casi d'uso (Use Case Diagram) Diagramma delle classi (Class Diagram) Diagramma di sequenza (Sequence Diagram) Diagramma di collaborazione tra oggetti (Collaboration Diagram) Diagramma di transizione di stato (State Diagram) Diagramma delle componenti software (Component Diagram) Diagramma di allocazione delle componenti (Deployment Diagram) 3

4 Diagramma delle Classi in notazione UML Il Diagramma delle classi descrive il tipo degli oggetti che compongono il sistema e le relazioni statiche esistenti tra loro. Esistono strumenti automatici di modellazione che a partire dal codice esistente creano dai diagrammi delle classi e viceversa. Tra questi strumenti il più noto è Rational Rose, ma esistono anche alternative open source come StarUml e ArgoUml. Rappresentazione di una classe Una classe è rappresentata da un rettangolo diviso in tre sezioni orizzontali: la prima contiene il nome della classe, solitamente in grassetto; quella centrale elenca gli attributi la terza elenca i metodi 4

5 In certi casi si può semplificare, per esempio lasciando impliciti il nome dei metodi get e set. In generale, specificare più o meno accuratamente i metodi e gli attributi delle classi in gioco, dipende dalla fase di progettazione in cui ci troviamo. I metodi in overload o overriding si ripetono più volte. Attributi e metodi di classe (statici) vanno sottolineati o preceduti dal simbolo $. Diagrammi UML dell ereditarietà L ereditarietà è rappresentata con una freccia con la punta a triangolo vuoto che va dalla sottoclasse alla superclasse. In questo caso, a volte, le classi sono rappresentate soltanto da un rettangolo col nome della classe. Se da una classe derivano più classi si può rappresentare l ereditarietà con un unica freccia che si suddivide in più rami. Nel caso di ereditarietà multipla (non consentita in Java) da una classe partono più frecce dirette alle superclassi. Quando da una classe derivano più sottoclassi, la superclasse risulta partizionata nelle sottoclassi. La freccia dell ereditarietà può riportare la proprietà di partizionamento (tra parentesi graffe): disjoint (disgiunte) o overlapping(sovrapposte). Due classi sono disgiunte quando non esistono elementi che possono appartenere contemporaneamente a due classi. Per esempio, nella gerarchia degli animali, tutte le sottoclassi sono disgiunte; un animale può essere solo mammifero, rettile o altro. Complete o incomplete (indica se le sottoclassi comprendono tutti i possibili elementi o se esistono elementi che non si trovano in alcuna delle sottoclassi); a volte si può avere un partizionamento incompleto perché si definiscono solo le sottoclassi necessarie all applicazione. 5

6 Dynamic o static (indica se un elemento può passare da una classe ad un altra; es.: un impiegato può passare nella classe dirigente) Una interfaccia è rappresentata da un rettangolo diviso in due sezioni (mancano gli attributi) nella prima sezione compare il nome e lo stereotipo <<interface>> nella seconda sezione i metodi Una classe che implementa l interfaccia è collegata all interfaccia da una freccia tratteggiata. Diagrammi UML delle associazioni Relazione di associazione Per la relazione di associazione si possono riscontrare diversi stili di rappresentazione. Secondo lo standard UML, un associazione bidirezionale si rappresenta con una linea a tratto continuo senza alcuna freccia. Esempio di associazione bidirezionale è quella esistente tra un dipendente e la ditta per la quale lavora: un dipendente lavora in una ditta (una e una sola); in una ditta lavorano molti dipendenti. A volte le associazioni hanno un verso. In questo caso le rappresentiamo con una freccia. Un associazione può avere un nome, dei ruoli o delle molteplicità. Un nome descrive la natura della relazione. I ruoli esprimono in modo specifico le funzioni che le classi associate svolgono l una rispetto all altra. Il nome dell associazione appare sopra la linea di congiunzione. Il ruolo di una classe appare accanto ad essa. La molteplicità di una associazione appare all estremità della linea: 0..* qualunque numero 1..1 esattamente o 1 1..* 1 o più di uno n esattamente n L associazione invece che dal nome può essere rappresentata anche da una classe collegata da una linea tratteggiata alla linea dell associazione. In questo caso possiamo descrivere anche attributi e metodi della classe associazione. L associazione è sempre una classe, anche quando è indicato solo il nome sulla linea della relazione. Se l associazione collega più di due classi (associazione multipla) si usa un rombo per collegare le linee di associazione. La molteplicità sarà sempre 0..*. Nelle associazioni si possono aggiungere i simboli di navigabilità che indicano come passare da un oggetto a quello associato. I simboli di navigabilità sono rappresentati da punte di frecce nel verso della navigabilità sulla linea dell associazione. 6

7 Per ottenere la navigabilità in un senso il primo oggetto deve contenere un riferimento al secondo (nell implementazione inserisco nella prima classe un attributo che rappresenta il riferimento ad un oggetto della seconda classe). Per ottenere la navigabilità nei due sensi gli oggetti devono avere riferimenti reciproci. Relazioni di composizione Le relazioni di aggregazione e di composizione hanno una notazione particolare: sulle linee di composizione e di aggregazione non compare alcun nome. 7

8 La composizione è rappresentata da una linea d associazione con un rombo nero dal lato dell oggetto composto; vicino al componente si può indicare il ruolo e la molteplicità. L oggetto composto di solito ha i riferimenti ai componenti (nel diagramma si possono aggiungere le frecce di navigabilità. Relazioni di aggregazione L aggregazione è rappresentata da una linea d associazione con un rombo vuoto dal lato dell oggetto aggregato; vicino al componente si può indicare il ruolo. La molteplicità deve essere indicata da entrambi i lati. Relazione di dipendenza La dipendenza è rappresentata da una linea tratteggiata con una freccia con la punta aperta che punta alla classe dipendente Alcune relazioni possono essere presenti contemporaneamente; es.: la classe Automobile estende la classe Veicolo, ma è associata alla classe Pneumatico (ogni automobile ha 4 pneumatici + 1, ovvero la gomma di scorta) Veicolo Automobile 5 Pneumatico Le frecce usate nella notazione UML possono confondere; la tabella seguente riassume i quattro simboli usati nella notazione UML per rappresentare le relazioni descritte: 8

9 Schemi di progettazione di base Uno stesso problema può essere risolto utilizzando schemi di progettazione diversi. Di seguito vediamo alcuni schemi di base. Problema 1 Si devono gestire i prestiti dei libri di una biblioteca, ponendosi come obiettivo sapere quali libri ha in prestito una persona. Si individuano subito le entità Libro ed UtenteBiblioteca associate tra di loro dalla relazione prestito 9

10 Posso avere anche una soluzione del seguente tipo Anche l associazione tra Prestito e Utente è sostituita da una di composizione. In UtenteBiblioteca inserisco sia il riferimento alla Persona che il riferimento all insieme dei prestiti. In questo caso Prestito si riferisce ad un solo Libro; se un utente prende in prestito più libri si dovranno creare più istanza di Prestito. Se cancello l utente della biblioteca resta la Persona. 10

11 Generalizzazione Uno stesso schema di progettazione può essere utilizzato in molti casi diversi, ma analoghi dal punto di vista della soluzione. Gli schemi visti precedentemente sono generalizzabili ad altri tipi di problemi completamente diversi. Un problema analogo a quello dei libri è quello relativo al possesso. Problema 2 Una persona possiede una o più automobili. Si vogliono rappresentare i dati relativi alle persone, alle automobili e i dati relativi alla proprietà. 11

12 In quest ultimo schema l associazione tra Proprietario e Proprietà è sostituita da una di composizione. In Proprietario inserisco sia il riferimento alla Persona che il riferimento a tutti i documenti di proprietà. La 12

13 classe Proprietà rappresenta in realtà il documento di proprietà. In questo caso Proprietà si riferisce ad una sola Auto; se un proprietario possiede più auto si dovranno creare più istanze di Proprietà. Se volessi rappresentare i passaggi di proprietà potrei creare un altra classe PassaggiProprietà che ha un riferimento ad Auto e un riferimento all insieme dei documenti di proprietà. Design Pattern Dal momento che la progettazione di applicazioni object oriented è spesso molto complicata e non è facile individuare subito le classi e le relazioni più adatte, si utilizzano i design pattern che sono schemi che descrivono soluzioni riutilizzabili di particolari problematiche di progettazione. Ogni design pattern si applica ad un particolare problema di progettazione (insieme di situazioni ricorrenti); la soluzione è espressa in modo generale mediante diagrammi delle classi in modo da lasciare una certa libertà nelle scelte implementative. Bisogna fare una certa attenzione nell utilizzare i design pattern perché a volte possono portare a complicare la soluzione anziché semplificarla. Bibliografia: Fabrizia Scorzoni, Informatica. Programmazione in Java, Loescher,