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 Sessione II Anno Accademico 1998-’99

16 Dicembre 1999Tesi di Laurea di Riccardo Solmi2 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

16 Dicembre 1999Tesi di Laurea di Riccardo Solmi3 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

16 Dicembre 1999Tesi di Laurea di Riccardo Solmi4 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

16 Dicembre 1999Tesi di Laurea di Riccardo Solmi5 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

16 Dicembre 1999Tesi di Laurea di Riccardo Solmi6 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à

16 Dicembre 1999Tesi di Laurea di Riccardo Solmi7 Implementazioni possibili Caratteristiche comuni: Ridefiniscono interamente il comportamento degli oggetti Ridirigo tutti i metodi sulla copia differenziata

16 Dicembre 1999Tesi di Laurea di Riccardo Solmi8 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

16 Dicembre 1999Tesi di Laurea di Riccardo Solmi9 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

16 Dicembre 1999Tesi di Laurea di Riccardo Solmi10 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

16 Dicembre 1999Tesi di Laurea di Riccardo Solmi11 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?

16 Dicembre 1999Tesi di Laurea di Riccardo Solmi12 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

16 Dicembre 1999Tesi di Laurea di Riccardo Solmi13 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

16 Dicembre 1999Tesi di Laurea di Riccardo Solmi14 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)

16 Dicembre 1999Tesi di Laurea di Riccardo Solmi15 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

16 Dicembre 1999Tesi di Laurea di Riccardo Solmi16 Conclusioni I linguaggi attuali obbligano il programmatore a fare delle scelte vincolanti per l'utente finale Tutti gli identificatori legati a valori (parametri, campi) sovraspecificano gli algoritmi L'Obiettivo di Adattabilità si può raggiungere sottraendo delle responsabilità al programmatore