Principi di Programmazione
Object-Oriented
Modello ad oggetti
• Concetto di oggetto riconducibile a diversi
settori:
– Software engineering
– Linguaggi di programmazione
– Basi di dati
– Intelligenza Artificiale
Approcci alla produzione di
programmi
• Programmazione in the small
– Progetto di algoritmi e strutture dati
• Programmazione in the large
– Software engineering
Metodi per la produzione di
programmi
• Metodi tradizionali:
– programmazione strutturata orientata alle
funzioni:
• flusso di controllo
• flusso di dati
• Metodi attuali:
– programmazione orientata agli oggetti:
• classe
• oggetti
• servizi
Strumenti per la progettazione
• Orientati alle funzioni:
– Diagramma di flusso (in the small)
– Analisi e progetto strutturato (in the large)
• Orientati agli oggetti:
– OOSE, OMT, ecc. (in the large)
• Unified Modeling Language UML
Approcci e Metodi
Structured
software
engineering
Programming in the large
UML
Programmazione
OO
Programmazione
strutturata
Flow chart
Programming in the small
Modello del software
• Necessità di modellare un sistema:
– creare una astrazione del sistema attraverso
cui specificarne la struttura ed il
comportamento.
• Il modello di un software deve
rappresentare le informazioni trasformate
dal software, le funzioni e sottofunzioni
che effettuano tali trasformazioni e il
comportamento del sistema conseguente
alle trasformazioni stesse
Processo software
• Definisce la strategia adottata nella
realizzazione del software.
– Comprende metodi, tecniche e strumenti.
– Si fonda sul concetto di qualità totale
– E’ caratterizzato da:
• Attività portanti
• Un insieme di compiti: punti di controllo, prodotti intermedi
(modelli, documenti), punti di garanzia dalla qualità.
• Attività ausiliarie: garanzie dalla qualità, gestione delle
configurazioni
Processo di sviluppo unificato
• Fasi del ciclo di vita
– Avviamento: consente di stabilire l’effettiva
realizzabilità del progetto
– Elaborazione: preparazione del piano del
progetto
– Costruzione: implementazione di un sistema
funzionante per un ristretto numero di utenti
tester
– Transizione: consegna ai clienti del sistema
completamente funzionante
Workflow del Processo Unificato
• Requisiti: costruzione del modello dei casi d’uso che
definisce i requisiti funzionali del sistema modellato
• Analisi: raffinamento e strutturazione dei requisiti
funzionali descritti nel modello dei casi d’uso mediante la
costruzione del modello di analisi
• Progetto: descrizione della realizzazione fisica dei casi
d’uso costruzione di un modello di progetto ed un
modello di deployment
• Implementazione:definizione dei componenti software
che realizzazione gli elementi del modello di progetto
• Test: descrizione dei dati test e delle modalità secondo
cui condurre i test del sistema nel modello di test
Modelli UML associati a ciascun
workflow
– dei casi d’uso
– di analisi
– di progetto
– di implementazione
– di test
– di deployment
Lo sviluppo di ciascun modello è condotto in
modo trasversale attraverso le 4 fasi del
processo unificato
Iterazioni e raffinamenti
• Occorre adottare un modello iterativo e
incrementale nel processo di sviluppo
– Iterazione:
• un progetto che attraversa trasversalmente ciascuno dei
workflow del processo unificato
– Raffinamento:
• è prodotto in ciascuna iterazione
• versione del progetto con maggiori funzionalità rispetto alla
versione precedente
• Scopo dell’approccio:
– Gestione dei rischi del progetto iniziale
– Valutazione dell’estensione del progetto iniziale
Punti di vista sul sistema
• I 6 modelli sono sviluppati in modo
incrementale attraverso i 5 workflow e
attraverso le 4 fasi del processo unificato
• E’ possibile definire diversi punti di vista
sul sistema sotto cui considerare i diversi
modelli
Punti di vista su un sistema
software
Implementazione
Progetto
Casi d’uso
Processo
Deployment
Modello guidato dai casi d’uso
• UML considera un sistema secondo
prospettive diverse in base agli utilizzatori
• Fondamentale è la prospettiva dei casi
d’uso che rappresentano la descrizione di
un particolare aspetto del sistema
• La modellazione in UML è guidata dai casi
d’uso
Casi d’uso
• Definiscono gli scenari d’uso del sistema
• Offrono una descrizione dei modi in cui il sistema sarà
utilizzato.
• Scenario:
– una sequenza di passi che descrivono l’interazione tra un utente
ed il sistema
• Per la descrizione dei casi d’uso occorre individuare:
– attori
• principali
• secondari
– ruoli
• E’ un testo informale che descrive il ruolo di un attore nel
corso dell’interazione con il sistema
Rappresentazione grafica in UML
• Caso d’uso
Caso d’uso
Caso d’uso
• Attore
Concetti object oriented
• Oggetto: una entità del mondo reale
• Classe:un insieme di oggetti aventi le
stesse caratteristiche
• Attributi: proprietà di classi ed oggetti che
ne definiscono le caratteristiche
• Metodi: definiscono il comportamento di
un oggetto
• Operazioni: definiscono il comportamento
degli oggetti istanze di una classe
Principi object oriented
• Ereditarietà:
– ciascuna classe può essere definita in termini di una
classe esistente. La nuova classe (sottoclasse)
contiene automaticamente la definizione di elementi
propri della classe originaria (superclasse)
• Polimorfismo:
– pluralità di forme, gli oggetti possono ridefinire le
operazioni della classe di cui fanno parte
• Information Hiding (incapsulamento):
– ciascuna classe nasconde al proprio interno i dettagli
implementativi
Esempio: ereditarietà
Classificazione delle specie animali
Vertebrati
Pesci
Anfibi
Rettili
Mammiferi
Uccelli
Oggetto
• Identità: espressa da un nome
• Stato: include le proprietà dette attributi
che descrivono gli oggetti
• Comportamento: rappresentato da
funzioni dette metodi che utilizzano o
cambiano il valore degli attributi
Classe
• Un insieme di oggetti aventi le stesse
caratteristiche. E’ caratterizzata da:
– Identità: definisce il nome della classe
– Attributi: la classe non ha stato, ma definisce
proprietà locali che sono l’astrazione delle proprietà
comuni agli oggetti istanze della classe
– Operazioni: definiscono il comportamento della
classe. Rappresentano i servizi che possono essere
richiesti da un oggetto. I metodi sono implementazioni
delle operazioni
Visibilità delle proprietà
Una classe è concettualmente divisa in due parti:
• Una parte visibile che fornisce l’unico modo
tramite il quale è possibile operare sugli oggetti
della classe e descrive che cosa, in termini di
operazioni ammissibili è possibile fare sugli
oggetti
• Una parte nascosta il cui contenuto non è
visibile all’esterno della classe e che riguarda
come le funzionalità visibili sono realizzate
Rappresentazione grafica in UML
Classe
Classe
Oggetto
Oggetto:Classe
attributi
operazioni
attributo1=valore1
attributo2=valore2
Relazioni tra classi
• Associazione: connessione strutturale tra
classi
• Aggregazione: relazione in cui una o più
classi sono parti di una classe intera
• Generalizzazione: (ereditarietà) relazione
in cui una classe (sottoclasse) eredita gli
attributi e le operazioni di una superclasse
– multipla
– semplice
Rappresentazione in UML delle
relazioni tra classi
associazione
generalizzazione
classe1
classe2
superclasse
classe
intera
aggregazione
sottoclasse
sottoclasse
classe
parte
Relazioni tra i casi d’uso
– Inclusione:
• un caso d’uso include esplicitamente il comportamento di un
altro in un punto specifico dell’azione.
• Il meccanismo serve per eliminare comportamenti ripetuti
all’interno di più casi d’uso
– Estensione:
• un caso d’uso include implicitamente il comportamento di un
altro in uno o più punti detti di estensione
• Il meccanismo è utilizzato per fattorizzare comportamenti
opzionali o che si verificano in determinate circostanze
– Generalizzazione:
• analoga alla generalizzazione per le classi
Rappresentazione in UML delle
relazioni tra casi d’uso
inclusione
generalizzazione
include
Caso d’uso padre
estensione
extend
Caso d’uso figlio
Caso d’uso figlio
Caso d’uso base
Caso d’uso esteso
Diagrammi UML
• Strutturali
– Delle classi
– Degli oggetti
• Architetturali
– Componenti
• Comportamentali
–
–
–
–
–
Casi d’uso (use case)
Sequenza
Collaborazione
Transizione di stato (state/transition diagram)
Attività (activity diagram)
Workflow di Analisi
• Scopo del workflow di analisi è delineare
un modello di analisi
• Il modello di analisi
– si compone di una serie di diagrammi che
descrivono il software nel suo contesto
operativo rispetto ai requisiti.
– rappresenta le informazioni, le funzionalità e il
comportamento nel contesto degli elementi di
un modello ad oggetti
Diagramma delle classi
• Rappresenta la struttura del sistema che si
sta sviluppando
• Descrive il tipo degli oggetti che
compongono il sistema e le relazioni
statiche tra loro esistenti
• Mostra gli attributi e le operazioni di una
classe
Diagramma degli oggetti
• Rappresenta una parte della struttura del
sistema che si sta modellando
• Rappresenta oggetti e valori specifici per
gli attributi
Diagramma dei casi d’uso
• Descrive le funzionalità fondamentali che il
sistema deve realizzare in termini di
scenari di utilizzo del sistema
• Descrive gli scenari percepiti in modi
diversi dai diversi attori
• Contiene la rappresentazione degli attori e
dei casi d’uso usando delle frecce per
associare gli attori ai casi d’uso con cui
interagiscono
Diagramma di casi d’uso
<<include>>
Caso d’uso
punti di estensione
Generalizzazione
<<extend>>
punti di estensione
Package di analisi
Rappresenta il raggruppamento concettuale
di elementi dell’analisi.
Comprende le classi di analisi e rappresenta
le loro interazioni
Workflow di progetto
• Nel workflow di progetto si delinea il modello di
progetto.
• Nel modello di progetto:
– si indicano gli oggetti derivati da ciascuna classe e le
loro interazioni
– si implementano i comportamenti e le comunicazioni
– si rappresenta dinamicamente il comportamento del
sistema mediante la modellazione delle
comunicazioni fra gli oggetti
Messaggio
• Rappresenta la comunicazione tra due
oggetti o all’interno di un oggetto
• La comunicazione è rappresentata da due
tipi di diagrammi:
– di collaborazione
– di sequenza
che rappresentano la stessa informazione
con diversi dettagli
Diagramma di sequenza
Un caso d’uso dà origina ad un diagramma di
sequenza che. Tale diagramma:
• Specifica come gli oggetti interagiscono
evidenziando la sequenza temporale dei
messaggi scambiati
• Il diagramma ha due dimensioni
– sull’asse orizzontale sono rappresentati gli oggetti
che interagiscono
– sull’asse verticale la sequenza temporale dei
messaggi
Elementi del diagramma di
sequenza
• Gli oggetti sono rappresentati come box in
cima ad una linea tratteggiata verticale
– Lifeline: rappresenta la vita dell’oggetto
– Box di attivazione: rappresenta il periodo
durante il quale l’oggetto ha il controllo del
flusso
Diagramma di sequenza
un Oggetto
creazione
nuovo Oggetto
messaggio
ritorno
distruzione
delega interna
Diagramma di collaborazione
• Illustra come gli oggetti interagiscono
evidenziando le relazioni tra gli oggetti che
collaborano
• Le relazioni sono specificate anche nel
diagramma delle classi; in questo
diagramma assumono la forma di link
istanza della associazione
Diagramma di collaborazione
nome dell’oggetto: classe
1: messaggio semplice()
messaggio asincrono
nome
del ruolo
1.1*: messaggio di iterazione()
1.2: [condizione] messaggio()
: classe
nome del ruolo
nome dell’oggetto
Raffinamento della struttura del
sistema
• Il modello di progetto include oltre ai diagrammi
di collaborazione e di sequenza che modellano
gli aspetti dinamici del comportamento del
sistema anche diagrammi che modellano gli
aspetti strutturali
• Raffinando la struttura del modello, il diagramma
delle classi viene arricchito con ulteriori
informazioni riguardanti le operazioni e gli
attributi.
• Le classi diventano più specifiche: classi di
progetto
Classi di progetto
• Dettagli di attributi e di operazioni
– Visibilità
• pubblica +
• protetta #
• privata -
– Dettagli di attributi
• molteplicità
• modificabilità
• frozen
– Dettagli di operazioni
• proprietà per l’esecuzione parallela e thread
Attività e azioni
• Attività:
– E’ un lavoro svolto da un oggetto in maniera
continuativa
– Può essere suddivisa in attività più semplici
• Azione:
– E’ un insieme di computazioni eseguibili in
modo indivisibile (è atomica)
– Si assume che sia istantanea
Diagramma delle attività
• Rappresenta azioni sequenziali o parallele
• E’ necessario rappresentare punti di
sincronismo
Ciclo di vita di un oggetto
• Evento:
– Qualcosa che accade ed ha rilevanza per un
oggetto
• Stato:
– Condizioni in cui un oggetto può trovarsi
durante il suo ciclo di vita
• Transizione:
– Passaggio di un oggetto da uno stato ad un
altro
Diagramma di stato
• Rappresenta la macchina a stati di un
oggetto. Indica:
– Gli stati che un oggetto può assumere
durante il suo ciclo di vita
– Gli eventi a cui può rispondere
– Le possibili risposte che può fornire a quegli
eventi
– Le transizioni tra gli stati dell’oggetto
Diagramma di stato
Nome del superstato
Nome dello Stato
Evento(parametri)[condizione]/azione
entry / azione
do / attività
exit / azione
evento/ azione(parametri)
Nome dello stato
Package di progetto
• Rappresenta il raggruppamento degli
elementi di progetto. Comprende i
diagrammi:
– di sequenza
– di collaborazione
– di stato
– delle attività
– delle classi di progetto
Workflow di implementazione
• Si sviluppa il modello di implementazione
– Illustra come gli elementi del modello di
progetto sono organizzati in componenti
software sotto forma di file di codice sorgente,
librerie collegate dinamicamente ecc.
Elementi del sistema
• Package:
– Raggruppamento concettuale di elementi del modello
• Componente:
– Raggruppamento di elementi fisici del sistema
– Rappresenta un modulo di codice
• Package e componenti possono coincidere ma
anche essere differenti: una singola classe può
essere presente in più componenti ma essere
definita in un solo package
Diagramma di componenti
• Illustra i componenti di un sistema e le
relative dipendenze.
• Dipendenze: mostrano come i
cambiamenti apportati ad un componente
si ripercuotono sugli altri. Esistono
dipendenze:
– di comunicazione
– di compilazione
Diagramma di deployment
• Mostra le relazioni fisiche tra i componenti
software ed hardware del sistema finito.
• Le unità computazionali sono
rappresentate come nodi
• Le associazioni tra nodi rappresentano le
connessioni fisiche usate dai componenti
del sistema per interagire
Diagramma di deployment
Componente 2
Componente 1
Fattori di qualità del SW
• Qualità esterne
– Riusabilità
– Estendibilità
• Qualità interne
– Strutturazione
– Modularità
Riusabilità: vantaggi
• Riduce la quantità di lavoro necessario
• Evita di ripetere le fasi di sviluppo
• Aumenta la qualità del software: il codice è
già stato testato verificato e l’uso
• Software più affidabile
Fattori di qualità influenzati
dall’approccio OO
Esterne
Favorite da
Interne
Favorite da
Estensibilità
•Ereditarietà
Strutturazione •Incapsulamento
•Ereditarietà
Riusabilità
•Ereditarietà
•Concetto di
Classe
Modularità
•Concetto di classe