Sei sulla pagina 1di 33

Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M.

270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30
Titolo: INTRODUZIONE A UML
Attività n°: 1

Introduzione a UML

Luigi Sarti
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30
Titolo: INTRODUZIONE A UML
Attività n°: 1

Che cos'è UML


• Dedicheremo questa lezione (e le due successive) ad approfondire
lo Unified Modeling Language (UML)
• UML mette a disposizione una notazione grafica standardizzata per
la modellazione di applicazioni software basate su un paradigma di
programmazione orientato agli oggetti.
• UML offre un formalismo molto
ricco, che facilita la descrizione
progettuale di un sistema
architetture

packages
Progetto di software da una molteplicità di
un sistema prospettive (i dati, le
software operazioni, i processi, le
architetture ecc.), ad ognuna
operazioni
delle quali è associato un
particolare tipo di diagramma.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30
Titolo: INTRODUZIONE A UML
Attività n°: 1

UML e database
• UML non è specificamente dedicato alla descrizione dello schema
concettuale di un database; alcuni suoi diagrammi possono essere
adottati per il progetto dei dati, mentre altri sono genericamente
usati nel campo dell'ingegneria del software, per organizzare e
progettare il codice che costituirà il sistema.
• Nel contesto del progetto dei database, i diagrammi UML più usati
sono il diagramma delle classi e il diagramma degli oggetti. Molti dei
costrutti del modello E-R visti nella lezione precedente sono
riconducibili a elementi del diagramma delle classi, per cui questo è
spesso usato per rappresentare il modello concettuale di un
database: per alcuni versi questi strumenti UML sono più espressivi
del modello E-R.
• Anche il modello logico di un database può, in alcuni casi, essere
descritto con un diagramma delle classi.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30
Titolo: INTRODUZIONE A UML
Attività n°: 1

Panoramica su UML
• UML nasce negli anni 90 per unificare (unified ml...) vari formalismi
e linguaggi di modellizzazione preesistenti, tutti più o meno
equivalenti sul piano dell'espressività ma del tutto incompatibili
reciprocamente.
• Tra gli autori dello sforzo di unificazione vale la pena ricordare i
nomi di Jim Runbaugh, Grady Booch, Ivar Jacobson. L'istituzione
che maggiormente contribuì a UML fu Rational Software, un'azienda
dedita allo sviluppo di strumenti dell'ingegneria del software, in
seguito (2003) acquisita da IBM.
• Oggi UML è uno standard riconosciuto a livello internazionale e
gestito da OMG, un consorzio no-profit (http://www.omg.org/)
• La versione più recente delle specifiche dello standard UML è la
2.4.1, datata Agosto 2011.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30
Titolo: INTRODUZIONE A UML
Attività n°: 1

Come presenteremo UML


• Anche se, come abbiamo visto, molte delle potenzialità
rappresentative di UML sono dedicate allo sviluppo di software in
generale e non allo specifico progetto di un database, in queste
lezioni presenteremo molta parte dello standard, perché limitarsi a
trattare solo le componenti direttamente usabili nella
modellizzazione dei dati sarebbe riduttivo e decontestualizzante.
• Non mancheremo, tuttavia, di sottolineare, ogni volta che se ne
presenterà l'opportunità, la rilevanza di un costrutto o di un
diagramma nei confronti del modello concettuale di un database.
Inoltre tutti gli esercizi saranno istanziati con attività contestuali al
progetto di basi di dati.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30
Titolo: INTRODUZIONE A UML
Attività n°: 1

Come usare UML (in generale, e coi database)


• UML è uno strumento potente e flessibile, con cui si possono
progettare applicazioni e sistemi software di qualità.
• Le specifiche standard sono rigorose, ma il progettista può decidere
di volta in volta quali componenti usare nel disegno del sistema. I
modelli possono essere sviluppati a vari livelli di approfondimento,
da un livello astratto (il modello concettuale, nel caso dei database)
fino al livello del linguaggio di programmazione (i modelli logico e
fisico di un database)
• In termini generali, questa gerarchia di livelli può essere
rappresentata così:
– Schizzo (sketch)
– Progetto dettagliato (specifiche, blueprint)
– Linguaggio di programmazione
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30
Titolo: INTRODUZIONE A UML
Attività n°: 1

Lo sk etch
• Lo sketch è l'approccio più astratto: consiste nel descrivere, usando
i diagrammi UML, solo gli elementi essenziali del sistema,
demandando ad una fase successiva il loro raffinamento e
approfondimento.
• Uno sketch UML persegue gli obiettivi di essere espressivo, chiaro,
veloce, di immediata comprensione.
• Uno sketch UML non persegue gli obiettivi della completezza e
dell'approfondimento, non fornisce dettagli, non risponde a tutte le
domande che ci si pone in fase di progetto. È uno strumento a
supporto delle fasi "alte" del disegno del software.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30
Titolo: INTRODUZIONE A UML
Attività n°: 1

Il progetto dettagliato
• A differenza dello sketch, Il progetto dettagliato persegue l'obiettivo
della completezza.
• I suoi diagrammi contengono tutte (o quasi) le informazioni atte a
descrivere compiutamente il sistema software che stiamo
progettando, e possono essere dati in input ai programmatori per la
produzione del codice.
• Gli aspetti formali e sintattici dello standard UML assumono
particolare rilevanza, e devono essere rispettati con cura, nella fase
di stesura del progetto dettagliato; per questo motivo, mentre lo
sketch può essere sviluppato con relativamente poca attenzione agli
aspetti formali, nel caso del progetto dettagliato si fa spesso uso di
ambienti di disegno e strumenti software specifici (ad es. Rational
Rose), che garantiscono il rispetto della sintassi UML.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30
Titolo: INTRODUZIONE A UML
Attività n°: 1

UML come linguaggio di program m azione


• È anche possibile usare UML come linguaggio di programmazione:
esistono strumenti che traducono direttamente i diagrammi UML in
codice C++ o Java.
• In genere, il codice prodotto automaticamente deve comunque
essere integrato o arricchito "a mano" dal programmatore; questi
strumenti apportano in ogni caso notevoli vantaggi in termini di
produttività e qualità del codice. È evidente che i diagrammi UML di
questo tipo devono essere molto dettagliati e approfonditi.
• È sempre più sfumata, in questo approccio, la distinzione tra
modello del software e codice sorgente. Nel campo specifico dei
database, vedremo come MySQL Workbench consenta di passare
da una rappresentazione grafica UML-like al codice SQL, e di
effettuare anche il passaggio inverso (reverse engineering: da SQL
a UML) in modo completamente automatico.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30
Titolo: INTRODUZIONE A UML
Attività n°: 1

UML: visione d'insieme


• Ecco una rappresentazione generale dei diagrammi UML (espressa, in modo
autoreferenziale, usando proprio un diagramma UML):
http://commons.wikimedia.org/wiki/
File:UML_diagrams_overview.svg
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S1
Titolo: Il diagramma delle classi
Attività n°: 1

Il diagramma delle classi

Luigi Sarti
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S1
Titolo: Il diagramma delle classi
Attività n°: 1

Il diagramma delle classi


• Il diagramma delle classi rappresenta le caratteristiche sia statiche
(le proprietà) sia dinamiche (le operazioni) dei moduli (classi) che
compongono un'applicazione software.
• Le relazioni che intercorrono tra le classi in UML si chiamano
associazioni. Il diagramma mostra i vincoli di cardinalità di
un'associazione, ma come vedremo adotta una convenzione diversa
da quella assunta negli schemi E-R.
• Nel diagramma ogni box rappresenta una classe, ed è diviso in
varie sezioni:
– Il nome
– Gli attributi
– Le operazioni
– I classificatori interni (nested classifiers, che
per ora ignoreremo)
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S1
Titolo: Il diagramma delle classi
Attività n°: 1

Un esempio di diagramma delle classi


Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S1
Titolo: Il diagramma delle classi
Attività n°: 1

Proprietà
• Le proprietà rappresentano le caratteristiche statiche e strutturali
della classe.
• Le proprietà sono costituite da:
– Attributi, i cui valori sono rappresentati direttamente nelle istanze
della classe, e corrispondono ai campi (instance variables,
member variables) di un oggetto in un linguaggio di
programmazione OO
– Associazioni, che rappresentano relazioni o collegamenti (link)
ad altre classi
• Entrambi sono dotati di molteplicità; gli attributi sono inoltre
caratterizzati dalla visibilità
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S1
Titolo: Il diagramma delle classi
Attività n°: 1

Nota sulla molteplicità


• Abbiamo già incontrato questa caratteristica negli schemi E-R, dove
prende il nome di cardinalità (Lezione 29.2, slide #10 e #11.
• Anche qui è possibile indicare una coppia di valori che specificano il
numero minimo e massimo di istanze di una classe con cui questa
partecipa all'associazione.
• La notazione però è differente:
– Minimo e massimo sono separati da due punti consecutivi (e non da
una virgola come nel modello E-R): ad es. 0..1
– La molteplicità "molti" viene rappresentata con * (asterisco) invece che
con N: ad es. 1..*
– Quando si specifica solo * si intende 0..*
– Quando si specifica 1 si intende 1..1
– La molteplicità di default è 0..* e può essere omessa nel diagramma.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S1
Titolo: Il diagramma delle classi
Attività n°: 1

Gli attributi
• Come abbiamo visto, gli attributi costituiscono
le proprietà intrinseche della classe
e sono rappresentati con una riga di testo
all’interno del secondo box della classe.
• La sintassi completa della riga è:
<visibilità> <nome> : <tipo> [<molteplicità>] = <default>
• Solo <nome> è obbligatorio. + public
• <visibilità> può assumere i seguenti valori: - private
# protected
~ package
• <molteplicità> indica quanti valori dell'attributo possono essere
rappresenti nella classe.
• <default> è il valore di inizializzazione dell'attributo (in assenza di
altre indicazioni).
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S1
Titolo: Il diagramma delle classi
Attività n°: 1

Le associazioni
• Le associazioni sono le proprietà estrinseche della classe, in quanto
fanno riferimento ad altre classi mediante collegamenti (link) che
connettono una classe sorgente ad una classe destinazione. Le
associazioni sono proprietà: il nome è indicato vicino alla
destinazione, che corrisponde al tipo della proprietà.
• Le molteplicità sono specificate agli estremi del connettore.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S1
Titolo: Il diagramma delle classi
Attività n°: 1

Navigabilità
• Le associazioni binarie si rappresentano con semplici linee che
congiungono le classi coinvolte. La presenza (opzionale) di una
freccia ad uno degli estremi indica la navigabilità unidirezionale
dell'associazione.
• In un'associazione unidirezionale due classi sono correlate, ma solo
una classe "sa" che la relazione esiste
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S1
Titolo: Il diagramma delle classi
Attività n°: 1

Classi di associazione
• Non è possibile assegnare attributi alle associazioni; a tal scopo si
usano le classi di associazione, che descrivono le proprietà di
un'associazione e vengono collegate mediante una linea
all'associazione da descrivere.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S1
Titolo: Il diagramma delle classi
Attività n°: 1

Le operazioni
• Le operazioni sono le azioni che una classe può eseguire; nei
linguaggi di programmazione OO le operazioni prendono il nome di
metodi.
• La sintassi della dichiarazione di un'operazione nel diagramma UML
delle classi è:
<visibilità> <nome> (<parametri> ) : <tipo di ritorno>
• I <parametri> sono indicati così:
<direzione> <nome> : <tipo> = <default>
• La <direzione> indica se un parametro è in
ingresso (in), uscita (out) o entrambi (inout).
Se non specificato, un parametro è in.
• Anche qui, solo <nome> è obbligatorio.
• Nel disegno concettuale dei database le operazioni rivestono minore
rilevanza delle proprietà.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S1
Titolo: Il diagramma delle classi
Attività n°: 1

Dipendenza
• Il legame di dipendenza permette di rappresentare una relazione fra
due classi in cui una modifica dell’una, il fornitore (supplier), causa
un cambiamento nell’altra, il cliente (client).
• Vari tipi di dipendenza:
– call: il client esegue un'operazione sul supplier
– create: il client crea un'istanza del supplier
– use: il client richiede, per la propria implementazione, un'istanza del
supplier.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S1
Titolo: Il diagramma delle classi
Attività n°: 1

Aggregazioni
• Le aggregazioni sono un tipo particolare di associazioni, in cui viene
definita una relazione tra un concetto composto e uno o più concetti
che costituiscono le sue parti.
• Un oggetto della classe "componente" può esistere senza dover
appartenere a un oggetto della classe "aggregatore".
• La relazione che ne viene definita è di tipo part-of.
• Il rombo all'estremo "aggregatore" dell'arco di connessione è vuoto.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S1
Titolo: Il diagramma delle classi
Attività n°: 1

Composizioni
• Anche nelle composizioni viene definita una relazione tra un
concetto composto e uno o più concetti che costituiscono le sue
parti, ma qui gli oggetti delle classi "componente" sono definiti solo
in quanto parti di un oggetto della classe "aggregatore".
• Il rombo all'estremo dell'arco di connessione (dal lato del concetto
composto) è pieno.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S2
Titolo: Altre caratteristiche dei diagrammi strutturali
Attività n°: 1

Altre caratteristiche dei


diagrammi strutturali
Luigi Sarti
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S2
Titolo: Altre caratteristiche dei diagrammi strutturali
Attività n°: 1

Generalizzazione ed ereditarietà
• Le relazioni di generalizzazione sono molto importanti nel contesto
dei linguaggi OO, un po' meno nell'ambito dei database relazionali.
Esistono tuttavia modelli di database orientati agli oggetti, per cui
presentiamo comunque la rappresentazione UML dell'ereditarietà.
• Il concetto UML di generalizzazione consente la rappresentazione di
ereditarietà sia singola
che multipla.
• Nel diagramma a lato un
esempio di ereditarietà
singola.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S2
Titolo: Altre caratteristiche dei diagrammi strutturali
Attività n°: 1

Ereditarietà multipla
• Ecco un esempio di ereditarietà multipla: la classe Veicolo anfibio
eredita sia da Autovettura sia da Natante.

• È da notare che in alcuni linguaggi OO, come ad es. Java,


l'ereditarietà multipla non viene implementata.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S2
Titolo: Altre caratteristiche dei diagrammi strutturali
Attività n°: 1

Classi astratte
• Analogamente ai linguaggi OO che consentono il polimorfismo,
anche in UML è possibile definire classi astratte.
• Il nome di una classe astratta è in corsivo.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S2
Titolo: Altre caratteristiche dei diagrammi strutturali
Attività n°: 1

P ack ages
• Quando si progetta un sistema complesso, in cui ci sono molte
classi, interfacce ecc. è opportuno organizzare le classi in gruppi
che prendono il nome di packages e facilitano la comprensibilità e la
manutenibilità del modello generale.
• I packages consentono di definire namespaces (spazi dei nomi) che
sono simili alle cartelle di un file system.
• Nella notazione
UML un package
è rappresentato
così:
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S2
Titolo: Altre caratteristiche dei diagrammi strutturali
Attività n°: 1

Interfacce
• In UML è possibile modellare le interfacce (interfaces) tipiche del
linguaggio Java.
• Una interface deve essere implementata da almeno una classe. In
UML una interface è considerata un caso particolare di classe, il cui
nome indica la caratteristica «interface». Ecco un esempio in cui le
due classi Studente e Docente implementano l'interfaccia Persona.
• La relazione di interface
realization (dalla classe
all'interfaccia) è tratteggiata
e termina con un triangolo
vuoto (come la generalizza-
zione, che però ha una linea
continua).
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S2
Titolo: Altre caratteristiche dei diagrammi strutturali
Attività n°: 1

Istanze
• È talvolta necessario rappresentare nel modello UML istanze
particolari delle classi, come esempi o come casi particolari degli
oggetti che popoleranno il sistema.
• La notazione è simile a quella delle classi, ma nel box del nome
viene specificata la riga:
<nome-istanza> : <nome-classe>
• Ad esempio:

• Nota: solo i valori degli attributi interessanti sono visualizzati.


• Possono essere esplicitate le (istanze di) associazioni tra istanze,
purché tali associazioni siano definite, nel modello, a livello di classi.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S2
Titolo: Altre caratteristiche dei diagrammi strutturali
Attività n°: 1

Nelle prossime lezioni


• Per ora concludiamo qui la nostra analisi dei diagrammi delle classi
UML.
• Nella prossima attività ti proponiamo un esercizio.
• Nelle prossime lezioni presenteremo vari altri tipi di diagramma
UML, e alcuni strumenti che consentono di disegnare i diagrammi di
un modello UML e ottenere automaticamente i corrispondenti
semilavorati e componenti software.
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S3
Titolo: Esercizio
Attività n°: 1

Esercizio

Luigi Sarti
Corso di Laurea: INGEGNERIA INFORMATICA E DELL’AUTOMAZIONE (D.M. 270/04)
Insegnamento: BASI DI DATI
Lezione n°: 30/S3
Titolo: Esercizio
Attività n°: 1

Conversione E-R  UML


• Nell'attività 29.3 ti è stato proposto il seguente schema E-R:

• Disegna un equivalente diagramma delle classi UML. Al termine,


confrontalo con la soluzione proposta in allegato alla lezione.