Fondamenti di Informatica II a.a. 2020-2021 - Dalla programmazione procedurale alla programmazione orientata agli oggetti Prof. Luca Mainetti ...
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Fondamenti di Informatica II
a.a. 2020-2021
Dalla programmazione procedurale alla
programmazione orientata agli oggetti
Prof. Luca Mainetti
Università del SalentoObiettivi della lezione
! Apprendere alcune tecniche per scomporre un sistema in
moduli (oggetti)
! Presentare le principali tipologie di relazioni che esistono tra
i moduli (oggetti)
! Vedere alcuni principi guida di modularizzazione
(principalmente l’information hiding)
! Riflettere su alcuni pattern architetturali e su alcuni stili di
progettare le architetture software
Programmazione procedurale e OO 2 Luca MainettiProgrammazione procedurale vs.
programmazione orientata agli oggetti
Programmazione procedurale e OO 3 Luca MainettiProgrammazione procedurale vs.
programmazione orientata agli oggetti (cont.)
Procedurale Orientata agli oggetti
Procedura Metodo
Record Oggetto
Modulo (es. funzione C) Classe
Chiamata di procedura Messaggio
Programmazione procedurale e OO 4 Luca MainettiC vs. Java: un semplice esempio C
#include
void SayHello(char *); // prototipo
int main(int argc, char *argv[])
{
sayHello("World");
return 0; }
void sayHello(char *name)
{
printf("Hello, %s\n", name);
return 0; }
Programmazione procedurale e OO 5 Luca MainettiC vs. Java: C suddiviso in moduli
SayHello.h Main.c
void SayHello(char *); /* prototipo */ #include
#include "sayhello.h"
int main(int argc, char *argv[])
SayHello.c
{
#include
sayHello ("World");
#include "sayhello.h”
// se si premettesse static, SayHelloTo return 0; }
// non sarebbe invocabile da main.c
void sayHello (char *name)
{
printf("Hello, %s\n", name);
return 0;}
Programmazione procedurale e OO 6 Luca MainettiC vs. Java: l’equivalente codice Java
Greeter.java GreaterMain.java
public class Greeter public class GreeterMain
{ {
private String name; public static void main(String[] args)
public Greeter(String aName) {
{ Greeter worldGreeter = new
name = aName; Greeter(“World”);
} String greeting =
worldGreeter.sayHello();
System.out.println(greeting);
public String sayHello()
}
{
}
return “Hello, ” + name ;
}
}
Programmazione procedurale e OO 7 Luca MainettiDominio del problema e dominio della soluzione
! I linguaggi imperativi definiscono un “dominio della
soluzione” che “astrae” la macchina sottostante
– Es.
1. read i
2. print i
3. goto 1
! Il programmatore deve creare un mapping fra “dominio
del problema” e “dominio della soluzione”
– Tale mapping è spesso innaturale e di difficile comprensione
Programmazione procedurale e OO 8 Luca MainettiParadigma Object Oriented
! Per risolvere i problemi presentati dall’approccio
procedurale, i programmatori hanno fatto sempre più uso di
tecniche mirate a proteggere dati globali o funzioni
nascondendone il codice.
! Il paradigma Object Oriented accentra l’attenzione verso i
dati.
– L’applicazione viene suddivisa in un insieme di oggetti in grado di
interagire tra di loro e codificati in modo tale che la macchina sia in
grado di comprenderli.
– Un linguaggio OO semplifica il meccanismo di creazione degli
oggetti.
– Il paradigma OO si basa sulla tecnica di incapsulare e
raggruppare parti di un programma
Programmazione procedurale e OO 9 Luca MainettiCos’è un Oggetto?
! Definizione da vocabolario:
“Un oggetto è un’entità che si
possa immaginare dotata di
determinate caratteristiche
e funzionalità”.
! Il confinamento di informazioni e funzionalità in
oggetti permette livelli maggiori di astrazione e
semplifica la gestione di sistemi complessi.
Programmazione procedurale e OO 10 Luca MainettiGli oggetti come modello naturale
! Gli oggetti nel software possono rappresentare entità
del mondo reale
– Il primo uso di linguaggi a oggetti è stato fatto per effettuare
simulazioni
Interazioni tra diversi componenti
=
scambio di messaggi
Programmazione procedurale e OO 11 Luca MainettiLinguaggi orientati agli oggetti
! Forniscono astrazioni che consentono di rappresentare
direttamente nel dominio della soluzione gli elementi
del dominio del problema
– Oggetti
– Classi
– Messaggi
• Il programmatore inizia analizzando tutti i singoli aspetti concettuali che
compongono un programma. Questi concetti sono chiamati oggetti con nomi legati a
ciò che rappresentano.
• Gli oggetti sono costituiti da attributi (dati) e funzionalità (metodi).
• L’analisi dovrà includere le modalità di interazione tra gli oggetti e proprio grazie a
queste interazioni sarà possibile riunire gli oggetti per formare un’applicazione.
• A differenza di procedure e funzioni, gli oggetti sono auto-documentanti
e il funzionamento interno delle funzionalità di un oggetto è
completamente nascosto al programmatore.
Programmazione procedurale e OO 12 Luca MainettiClassi di oggetti
! Pensiamo ad un libro come appartenente ad una classe di oggetti
aventi caratteristiche comuni: numeri di pagine, testo inserito in ogni
pagina, note inserite a fondo pagina (attributi).
! Le azioni che tipicamente si compiono quando si utilizza un libro sono:
voltare pagina, leggere il testo, guardare le figure, ecc.( metodi).
! È interessante notare che si utilizza il termine libro per generalizzare un
concetto relativo a qualcosa che contiene pagine da sfogliare, da
leggere o da strappare ossia ci si riferisce ad un insieme di oggetti con
attributi comuni, ma comunque composto da entità aventi ognuna
caratteristiche proprie che rendono ognuna differente rispetto all’altra.
! La classe è una categoria di oggetti che fornisce la descrizione
generale del concetto di libro.
! L’oggetto è una istanza della classe ( ogni nuovo libro) avente
caratteristiche proprie.
Programmazione procedurale e OO 13 Luca MainettiUn modello a oggetti
! L’idea informale:
rappresentare le entità della programmazione
come aggregazioni di variabili e metodi
Esempio: ContoCorrente
comportamento saldoAttuale
deposita
codice ritira
titolare
struttura saldo
interesse
fido
variabili modificaFido
modificaInteresse
metodi
Programmazione procedurale e OO 14 Luca MainettiRappresentazione di un oggetto
Mes
sag
gio
Met
odo
Me
ss
Met
ag
odo
gi
Attributo
o
Attributo
M
Mes
e
Attributo
to
s
do
aggio
Programmazione procedurale e OO 15 Luca MainettiMessaggi
! Gli oggetti sono gli elementi attivi di un programma
– Come fanno gli oggetti a compiere le azioni desiderate ?
! Gli oggetti sono attivati dalla ricezioni di un messaggio
! Una classe determina i messaggi a cui un oggetto può
rispondere
– metodi
! I messaggi sono inviati da altri oggetti
Programmazione procedurale e OO 16 Luca MainettiScambio di messaggi
! Il flusso dell’esecuzione viene visto come
un flusso di messaggi
Esempio:
Oggetto A Ciclista
ricevente.nomeMetodo(parametri) bici.cambiaRapporto(2)
bici
Oggetto B Bicicletta
messaggio
! Componenti di un messaggio:
– un riferimento al ricevente;
– il nome del metodo;
– i parametri.
Programmazione procedurale e OO 17 Luca MainettiClassi
! Descrivere gli oggetti uno ad uno è poco vantaggioso.
Infatti:
– ogni oggetto richiederebbe una descrizione specifica;
– la grande varietà ostacolerebbe la comunicazione.
! Al contrario, una classe è uno schema generale
per la creazione di oggetti simili:
– la struttura degli oggetti è descritta come schema;
– il comportamento degli oggetti è definito in modo effettivo.
comportamento
struttura
dichiarazione delle variabili
metodi effettivi
Programmazione procedurale e OO 18 Luca MainettiClassi e istanze: ContoCorrente
class ContoCorrente {
String codice; ContoCorrente
String titolare;
float saldo; ritira
...
void deposita(float somma) { codice istanza di
saldo += somma; N58AB
titolare
} Gino
saldo
1.350
void preleva(float somma) { deposita
saldo -= somma;
istanza di
}
}
c1.deposita(31)
istanza di
AA54Z
Pino
7.823
N58AB
Lino
2.500 c2.preleva(275)
Operatore
c3.deposita(50)
Programmazione procedurale e OO 19 Luca MainettiAttività di progettazione
! La progettazione
– fornisce la struttura agli artefatti
– permette di decomporre un sistema in parti
– di assegnare le relative responsabilità
– assicurare che le parti concorrano ai requisiti globali
! Il risultato della progettazione è il modello dei sistema
! L’architettura è la parte centrale del modello
! Definisce un modo generale di procedere all’organizzazione
di un modello in parti
! La progettazione è il ponte tra requisiti e implementazione
Programmazione procedurale e OO 20 Luca MainettiAttività di progettazione (cont.)
! La scomposizione di un sistema in moduli è la parte
principale dell’attività di progettazione
! Il documento di progettazione pone enfasi
sull’organizzazione del sistema in moduli e sulle relazioni
che esistono tra i moduli
! Questo è ciò che si intende con “architettura software”: un
insieme di moduli e di relazioni tra moduli che concorrono a
realizzare un sistema comune (in termini di requisiti)
! Saper progettare l’architettura del software è quindi
fondamentale
! Non vanno però persi di vista i requisiti: l’architettura
“realizza i requisiti”
Programmazione procedurale e OO 21 Luca MainettiArchitettura software
! Mostra la struttura generale del sistema
! I moduli che la compongono sono generalmente troppo
“grandi” per poter essere mappati direttamente in software,
ma sono già una linea guida importante per procedere nel
raffinamento
! La descrizione dell’architettura software include
– i componenti principali del sistema
– le relazioni tra questi componenti
– il motivo e le ragioni per cui si è scelta tale scomposizione
– vincoli che devono essere rispettati nella progettazione dei
componenti
Programmazione procedurale e OO 22 Luca MainettiArchitettura software (cont.)
! Vi sono due obiettivi importanti
! Progettazione per il cambiamento (Parnas)
– il design si concentra sulle necessità espresse nei requisiti
– una parte dell’effort è comunque dedicata ad anticipare possibili
cambiamenti
! Progettazione per famiglie di applicazioni (Parnas)
– pensare che il sistema che si sta progettando non è una sola
istanza, ma fa parte di una famiglia di programmi
– gli esemplari della famiglia possono differenziarsi per versioni
dovute a differenti ambienti di rilascio (device/canali) o a contesti di
utilizzo
Programmazione procedurale e OO 23 Luca MainettiProgettazione per il cambiamento
! E’ fondamentale saper progettare per il cambiamento
! Il 60% del costo del software è per la manutenzione
– correttiva
– adattiva
– perfettiva
! Chi non progetta per il cambiamento
– corre il rischio di spendere più effort per la manutenzione adattiva e
perfettiva
– compromette progressivamente la struttura logica del software per
soddisfare le richieste di cambiamento quando queste emergono
– rischia di peggiorare l’affidabilità del sistema
Programmazione procedurale e OO 24 Luca MainettiAlcune cause di cambiamento
! Cambiamenti riguardanti gli algoritmi
– ad esempio, sostituire un algoritmo di ordinamento con uno più
efficiente
– a proposito degli algoritmi, esiste un pattern di progettazione
dedicato dal nome “strategy” che risolve il problema
dell’incapsulamento di un algoritmo al fine di facilitarne la
sostituibilità
! Cambiamenti riguardanti la rappresentazione dei dati
– ad esempio, passare da un albero binario ad un albero tramato
– il 17% dei costi di manutenzione sono attribuibili a cambiamenti nella
struttura dei dati (Lientz e Swanson, 1980)
– il cambiamento nella struttura dati non ha solamente effetto
sull’efficienza. Pensate, ad esempio, a strutture che permettono di
aggiungere facilmente e velocemente informazioni (campi) in un file
Programmazione procedurale e OO 25 Luca MainettiAlcune cause di cambiamento (cont.)
! Cambiamenti riguardanti la macchina astratta sottostante
– nuove versioni di sistema operativo
– nuove versioni (ottimizzate) dei compilatori
– nuove versioni di DBMS
– ecc.
! Cambiamenti dovuti a periferiche e device
– molto importante ora che nuove periferiche d’interazione si stanno
affermando
! Cambiamenti dovuti al contesto
– ad esempio, nuovo regime fiscale, passaggio all’Euro per un sistema che si
occupa di transazioni finanziarie
! Cambiamenti dovuti al processo di sviluppo
– trasformazioni di prototipi in prodotti in un processo incrementale
Programmazione procedurale e OO 26 Luca MainettiModuli e architettura
! Un modulo è uno dei sottosistemi che compongono
un’applicazione software
! La progettazione di un’applicazione riguarda quindi la
progettazione dei moduli e delle mutue interrelazioni
! Un modulo è una porzione di software dotata di una sua
memoria persistente. E’ quindi qualcosa di più di una
semplice routine la cui memoria perde di significato quando
lo stack viene deallocato
! Un modulo è una porzione di software che contiene e
fornisce risorse e servizi computazionali
Programmazione procedurale e OO 27 Luca MainettiModuli e architettura (cont.)
! I principali criteri per una buona modularizzazione sono la
valutazione del grado di coesione e del disaccoppiamento
! Coesione
– è il grado di unità e di legami interni tra gli elementi di un modulo
– un modulo coeso è fatto da elementi omogenei
– un modulo coeso è facilmente comprensibile, è facilmente
realizzabile, rende facilmente modificabile l’intero sistema poiché gli
interventi sono localizzati
! Disaccoppiamento
– è il grado di indipendenza tra moduli distinti
– quanto più i moduli sono disaccoppiati, tanto più sono facili da
comprendere e da realizzare indipendentemente poiché la
comprensione di un modulo non richiede la comprensione degli altri
– moduli disaccoppiati hanno pochi e semplici legami
Programmazione procedurale e OO 28 Luca MainettiModuli e architettura (cont.)
! L’insieme delle interrelazioni tra i moduli viene detta
architettura del sistema
! In realtà, quando si definisce un’architettura software, si
definiscono contemporaneamente moduli ed interrelazioni.
L’identificazione dei moduli non può essere ovviamente
disgiunta dall’individuazione delle mutue dipendenze
! L’architettura di un sistema viene generalmente
rappresentata tramite grafi diretti (la direzione indica il verso
delle dipendenze)
– G =
– N è l’insieme dei nodi
– A Í N x N è l’insieme degli archi (l’ordine è importante nella
specifica delle dipendenze)
Programmazione procedurale e OO 29 Luca MainettiModuli e architettura (cont.)
! Siamo generalmente interessati a grafi aciclici
– una sequenza ,, …, di archi di un grafo è
un ciclo se n1=nk, cioè se si ha un cammino chiuso
– un grafo diretto aciclico viene detto gerarchia. In una gerarchia i
nodi possono essere classificati per livelli
– spesso siamo anche interessati a particolari grafi aciclici. In un
albero esiste uno ed un solo cammino diretto che collega la radice
con ciascuno degli altri nodi
A A
B C D B C D
E F G E F G
Grafo Albero
H H
Programmazione procedurale e OO 30 Luca MainettiLa relazione USA
! La relazione USA è una di quelle più spesso ricorrenti tra i
moduli
! Tale relazione evidenzia quali sono i servizi che un modulo
mette a disposizione agli altri, e quali sono i servizi che ogni
singolo modulo richiede agli altri
! E’ quindi la struttura logica più importante di un’architettura
di sistema
! ni USA nj se perché il modulo ni risulti corretto rispetto alle
specifiche è necessaria anche la corretta esecuzione di nj
! In altri termini ni risulta cliente dei servizi di nj
Programmazione procedurale e OO 31 Luca MainettiLa relazione USA (cont.)
! La relazione USA sta tra due estremi
– USA = M x M
• tutti i moduli del sistema sono in relazione USA
• il grado di disaccoppiamento del sistema è troppo basso
– USA = Æ
• nessun modulo usa servizi di nessun altro
• il sistema è fatto di sottosistemi isolati in cui è presumibile che siano
replicate varie funzionalità, quindi il livello di coesione è scarso
! Si deve trovare il giusto equilibrio tra i due estremi
– un modulo deve fare uso di un numero limitato di risorse di altri
moduli (il modulo risulta più facilmente comprensibile da solo),
quindi il numero di archi uscenti deve essere basso
– un modulo deve ricevere invece parecchie richieste dall’esterno (i
servizi sono stati fattorizzati), quindi il numero di archi entranti deve
essere elevato
Programmazione procedurale e OO 32 Luca MainettiLa relazione USA (cont.)
! La relazione USA non si esaurisce con la sola chiamata di
metodo o di procedura
! Vanno considerate situazioni in cui i moduli si scambino
messaggi oppure condividano strutture dati
! Questa osservazione è molto importante vista la costante
evoluzione tecnologica e dei linguaggi di programmazione
! I moduli che si scambiano messaggi ed i moduli che usano
strutture condivise sono in relazione USA
Programmazione procedurale e OO 33 Luca MainettiLa relazione USA (cont.)
! Nella progettazione di sistemi concreti, è utile che la
relazione USA sia aciclica. In altri termini è utile che
l’architettura del sistema sia gerarchica
! In una gerarchia si dice che mi è ad un livello di astrazione
maggiore di mj sei il suo livello rispetto alla gerarchia USA è
minore del livello di mj
! Un sistema gerarchico può essere analizzato dal livello più
alto di astrazione: per comprendere un modulo è sufficiente
avere conoscenza dei moduli utilizzati
! Un sistema gerarchico può essere realizzato, integrato e
verificato per parti
! Si evitano quindi i casi pericolosi in cui nulla funziona finché
tutto funziona
Programmazione procedurale e OO 34 Luca MainettiLa relazione COMPONENTE_DI
! Una relazione ortogonale a USA è COMPONENTE_DI
! In questo caso si rappresenta il raffinamento progressivo di
un modulo in sottomoduli
! COMPONENTE_DI Í M x M
– tale relazione deve dare luogo necessariamente ad una gerarchia
– la gerarchia non deve essere necessariamente un albero, ma in
generale può contenere collegamenti diretti anche tra livelli non
contigui
! Tra tutti i moduli appartenenti ad una relazione
COMPONENTE_DI solamente quelli terminali esistono
effettivamente nel sistema. I moduli intermedi servono per il
raffinamento del sistema e per la sua documentazione
Programmazione procedurale e OO 35 Luca MainettiLa relazione COMPONENTE_DI (cont.)
! Una volta che un modulo che appartiene alla relazione USA
viene scomposto in sottomoduli, devono essere anche
ridefiniti gli archi USA sui sottomoduli stessi
A A a1 a2 a3
B C
a1 a2 a3 F B C
E F D
I: specifica di USA II: specifica di III: ridefinizione di USA
COMPONENTE_DI per i moduli coinvolti
Programmazione procedurale e OO 36 Luca MainettiInformation hiding
! Una volta definita l’architettura di sistema, con le relazioni
USA e COMPONENTE_DI, prima di procedere
all’implementazione è necessario entrare maggiormente nel
dettaglio della progettazione delle effettive relazioni che
legano i moduli
! In sostanza devono essere definite le interfacce dei moduli,
cioè l’insieme dei servizi messi a disposizione
! Il contenuto del modulo (anche detto realizzazione o
implementazione) rimane invisibile dall’esterno. Deve poter
essere deciso localmente e non deve dipendere dagli altri
moduli
! Questo in sintesi è il concetto di information hiding
– interfaccia (risorse esportate, risorse importate)
– realizzazione
Programmazione procedurale e OO 37 Luca MainettiInformation hiding (cont.)
! Sono principalmente le scelte di progetto locali (interne al
modulo) che devono essere tenute nascoste, così che
possa essere garantita la modificabilità
! Ad esempio, tipiche scelte locali possono essere
– gli algoritmi utilizzati (non è utile che un modulo cliente conosca i
dettagli degli algoritmi utilizzati da un modulo servente per fornire
servizi)
– le strutture dati locali (differente è ovviamente il discorso per le
strutture dati condivise)
– le politiche di assegnamento delle risorse
! L’elenco sopra riportato è ampiamente incompleto e
puramente indicativo
Programmazione procedurale e OO 38 Luca MainettiArchitetture standard
! Si possono riscontrare alcune
architetture ricorrenti
– pipeline pipeline
– blackboard: un modulo fa
comunicare tutti gli altri
– basate su eventi: soddisfano il
paradigma “pubblicazione-
sottoscrizione”; alcuni moduli blackboard
pubblicano (generano) eventi,
altri si registrano (si
sottoscrivono)
– specifiche di dominio: tengono
conto delle caratteristiche di
eventi
determinati domini applicativi
Programmazione procedurale e OO 39 Luca MainettiArchitetture standard (cont.)
! Un esempio molto noto di un’architettura specifica di dominio è
“model-view-controller”
! Si presta a risolvere situazioni in cui è rilevante l’interazione con l’utente
Programmazione procedurale e OO 40 Luca MainettiL’architettura software del corso di
Principi di Ingegneria del Software
Programmazione procedurale e OO 41 Luca MainettiPuoi anche leggere
