Per un nuovo orientamento nella progettazione
dei linguaggi di programmazione
Tesi di Laurea di:
RICCARDO SOLMI
Università degli Studi di Bologna
Facoltà di scienze matematiche, fisiche e naturali
Corso di Laurea in Informatica
Relatore:
Prof. ANDREA ASPERTI
Obiettivi
• Mostrare che esiste una funzionalità generale non supportabile dagli attuali linguaggi
• Mostrare la rilevanza di questa funzionalità
• Individuare gli aspetti fondazionali responsabili di questo limite
• Indicare un nuovo punto di partenza per la
progettazione dei linguaggi di programmazione
Adattabilità e ristrutturazione classi
• Programmazione OO obbliga a fissare composizione delle classi e parametri dei metodi
• Esigenza di ristrutturare le classi accomuna diverse tendenze di sviluppo attuali (SOP, AOP, IP, classi di specializzazione dinamica del comportamento)
• Convinzione: rigidità struttura non limita adattabilità
• Introduco operazione di differenziazione in una forma limitata e adattata al paradigma OO
• La differenziazione evidenzia rigidità nel dominio
dell’applicazione
Operazione di differenziazione OO
• Si applica ad un oggetto scegliendo una variabile di differenziazione
• Coinvolge quattro soggetti
• Un oggetto differenziato ha stati diversi per ogni valore della variabile
• Ha effetti sul comportamento dei clienti
• Sposta un campo dalle classi cliente alla classe
destinazione
obj 1
object
client 1
o.var
obj n client
2
obj 2
target n target
2 target
1
client
m Oggetto da differenziare
Copie differenziate
Oggetti destinatari
Variabile di differenziazione
object differenziato da var
(
object.differentiate(o.var))
Esempi di applicazione
Ogni gruppo deve poter
avere le proprie preferenze di visualizzazione
Ogni messaggio deve poter avere il proprio font
Ogni gruppo deve poter avere la propria vista messaggi
Ogni vista messaggi deve poter avere le proprie
preferenze di visualizzazione
GRUPPI
admin Mittente Destinatario Oggetto
Clelia Riccardo Clelia Ricetta torta Sacher seminars Clelia Riccardo Re: Ricetta torta Sacher students Clelia Riccardo Orari dei treni
PREFERENZE
v Mostra mittente Ciao, eccoti la ricetta della Sacher. Questa volta vedi di v Mostra destinatario non perderla. Clelia
v Mostra oggetto Sacher torte
Mettere il burro a pezzi in una ciotola; versare la maggior Carattere: Arial parte dello zucchero nella ciotola e lavorare a crema Dimensione: 10 punti Versare lo zucchero restante in una seconda ciotola.
Spezzettare la cioccolata; metterla in un resipiente nel forno e farla fondere. Versare la cioccolata fusa nella ciotola. Rimescolare.
Per ogni uovo: separare rosso da albume. Versare INTESTAZIONI
MESSAGGIO
Mail & News reader
Ricerca di una soluzione OO
Requisiti soluzione:
Usabile dai
programmatori e dagli utenti
Generale (semplice da usare)
• Trasformazione persistente del programma
Soluzioni esplorate:
• Design Pattern
• Progr. a soggetti
Progr. ad aspetti
• Progr. basata su oggetti
• Modelli con predicati
Modelli ad attori
Riflessività
Implementazioni possibili
Caratteristiche comuni:
• Ridefiniscono interamente il
comportamento degli oggetti
• Ridirigo tutti i metodi sulla copia differenziata
obj 1
object
client 1
o.var
obj n client
2
obj 2
target n target
2 target
1 client
m
object differenziato da var (aspetti, attori)
map
target,obj
Insufficienza della riflessività
Fornisce operazioni sufficienti nelle mani di un
programmatore ma introduce conflitti di responsabilità
• La ristrutturazione richiede di definire nuovi percorsi di inizializzazione/instradamento per i dati
• Esistono diverse soluzioni ragionevoli
• I programmatori sono gli unici garanti della linearità
dello sviluppo di nuove versioni e della compatibilità
dei formati dei file
Fatti che orientano la ricerca
• È possibile implementare l’operazione di differenziazione (seppure limitatamente)
• Una singola operazione può localizzare scelte
progettuali che solitamente vengono disperse nella struttura del programma
Ipotesi: la programmazione ad oggetti sovraspecifica la struttura dei programmi. Non è necessario assumersi la responsabilità di definire i percorsi di
inizializzazione dei dati e la composizione delle classi
Sovraspecificazioni obbligate
• Sono interessato al risultato di una funzione;
non ho bisogno, in generale, di vincolare tutti i parametri attuali
• Spesso mi basta fissare il vincolo che il
chiamante e la funzione chiamata usino lo
stesso oggetto senza precisare quale
Domande funzionali alla soluzione
Posso ripartire la responsabilità della determinazione dei parametri attuali tra la chiamata a funzione e la funzione chiamata?
• Posso trovare un sostituto ai puntatori che lasci aperta la determinazione dell’oggetto puntato?
• E posso come programmatore sottrarmi alla
responsabilità di definire la struttura per
rappresentare una entità complessa?
Programmazione procedurale
Paradigma imperativo:
• Dominato dal flusso del controllo
• I dati hanno esclusivamente un ruolo passivo
• Le funzioni non cercano di produrre i parametri attuali
Paradigma funzionale:
• Dominato dal flusso del controllo però si può scegliere la strategia di valutazione
• I dati possono propagarsi verso il risultato
• Le funzioni possono
propagare la richiesta del
risultato verso i parametri
attuali
Programmazione dataflow e logica
Paradigma dataflow:
• Dominato dal flusso dei dati
• I dati si propagano sul grafo dataflow verso tutte le
operazioni che possono contribuire a calcolare
Paradigma logico:
• Dominato dal flusso della domanda
• La richiesta di un dato si
propaga verso tutte le
funzioni che possono
contribuire a calcolarlo
Una nuova unità funzionale: Step
• Due linee di ingresso/uscita: entry-call e done-action
• Una richiesta (entry) si propaga (call) solo se il risultato (done) non è
disponibile
• Un risultato (done) si propaga (action) solo quando viene richiesto (entry)
• La propagazione del risultato (action) è una continuazione della richiesta (entry) e non dipende dalla persistenza del risultato (done)
Step Call Entry
Action Done
Done Idle
EntryCall
EntryDone Action
Entry Action
Soluzione prospettata
• Programmazione esplicita dei flussi della domanda e dei dati
• Funzioni definite a partire dal
risultato, lungo la sequenza inversa
• Chiamante e chiamato legati da una comune richiesta non da un comune valore
• Rappresentazione disaggregata delle entità. Per ogni attributo
definisco un albero di funzioni per determinare il valore in diversi contesti
dato A disponibile richiesta
dato B
