Towards an evolutionary Formal Software- Development Using CASL Corso di Metodi di Specifica dei Sistemi Software A.A. 2004/05 Docente: Prof. Giuseppe Scollo Candidato: Giovanni Tommasi, in000569

Contenuti Introduzione Introduzione Development Graph Development Graph Traduzione CASL – Development Graph Traduzione CASL – Development Graph Differenze tra Development Graph Representation Differenze tra Development Graph Representation Gestione delle modifiche in un DG Gestione delle modifiche in un DG Cambiare un Development Graph Cambiare un Development Graph

Introduzione Qui si vuole presentare una soluzione al problema per le specifiche CASL, mostrando come gli effetti dei cambiamenti possono essere computati in modo da avere le prove risultanti con meno sforzo. Questo è ottenuto in due passi successivi: 1.qualsiasi cambiamento nelle specifiche è decomposto in modifiche minori, ciascuna delle quali ha effetto solo su un singolo modulo della specifica 2.gli effetti di questi cambiamenti locali sono analizzati basandosi sulla struttura della specifica complessiva Lo sviluppo formale di un programma è un processo evolutivo. Specifica e verifica sono mutualmente interconnesse: fallimenti nelle verifiche portano a cambiamenti nelle specifiche, le quali rendono non valide le prove trovate in precedenza. Per scopi pratici è indispensabile restringere al minimo gli effetti di tali cambiamenti in modo da contenere quanto più possibile gli sforzi di dimostrazione dopo una modifica nelle specifiche.

Introduzione (2) I Development Graph forniscono uno strumento di supporto generico, indipendente da uno specifico linguaggio. Si istanzia un framework e si definisce una struttura preservando una mappatura tra CASL e DG. La traduzione è eseguita in due fasi: 1.Si utilizza una rappresentazione intermedia usata anche per calcolare le differenze locali tra specifiche. 2.Queste differenze sono tradotte in cambiamenti del grafo corrispondenti e i loro effetti sono analizzati. In questo processo, il controllo sul cambiamento del grafo assicura che lo sviluppo complessivo sia sempre consistente.

Development Graph Rappresenta lo stato effettivo dello sviluppo formale di un programma ed è usato per codificare le specifiche strutturate nelle varie fasi. E un grafo diretto aciclico N,L. Ciascun nodo N N del grafo rappresenta una teoria: le foglie corrispondono a specifiche di base, le quali non fanno uso di altre teorie. i nodi interni corrispondono a specifiche strutturate che definiscono teorie usando altre teorie. Gli archi nel grafo definiscono come le teorie possono far uso di altre teorie, collegando tra loro i nodi, e possono essere globali o locali a seconda che siano transitivi o meno: archi di definizione: definiscono le teorie dei nodi. archi di teorema: postulano relazioni tra diverse teorie; sono la struttura dati centrale per rappresentare i vincoli sulle prove che sorgono nello sviluppo formale. N = ( N, N, N )

Development Graph (2) La teoria di un nodo N dipende da: le teorie di tutti i nodi che sono connessi con un arco globale a N. gli assiomi locali di tutti i nodi che sono connessi con un arco locale a N. N

Traduzione CASL - Development Graph Inoltre, la traduzione non mappa direttamente in grafi di sviluppo, ma semplicemente in una rappresentazione sintattica (Development Graph Representation) dei grafi di sviluppo. La rappresentazione DGR contiene solo la struttura risultante dalla specifica CASL, laddove il grafo contenga informazioni riguardo la decomposizione di archi globali in archi locali e prove di vincoli derivanti dagli archi di teoremi locali. Si definisce una mappa da un sottoinsieme di CASL ai grafi di sviluppo che: sia adeguata: qualsiasi teorema che può essere provato in un nodo del grafo vale nella corrispondente specifica CASL. preservi la struttura: la struttura di una specifica si riflette in quella del grafo. Sarà considerato il seguente sottoinsieme di CASL: definizioni di specifica specifiche di base specifiche strutturate

Traduzione CASL - Development Graph (2) La costruzione di un DG è unapplicazione iterata di regole di riscrittura che traducono le specifiche CASL in grafi di pre-sviluppo, in cui le sotto-specifiche non ancora tradotte sono indicate da box in grigio. Queste box grigie sono decomposte finché si arriva ad un grafo in cui non sono rimaste altre box del genere, ovvero un grafo di sviluppo. Durante questo processo, possono essere state create altre box con archi entranti oppure uscenti. Le frecce in grassetto indicano come questi archi sono ereditati quando la box viene riscritta. Precisamente, viene mostrato solo come vengono trattati gli archi di definizione e non quelli di teorema. Quantunque una box sia riscritta, tutti gli archi di teorema entranti sono redirezionati al cerchio vuoto creato dal processo di riscrittura. Questo cerchio diventa anche la sorgente di tutti gli archi di teorema uscenti dalla box originale.

Traduzione CASL - Development Graph (3) Definizioni di specifica Definizioni di specifica spec SN = SP Il nodo SP verrà poi riscritto nel DGR e corrisponderà al corpo della definizione di specifica; SN è un nodo vuoto con lannotazione del nome SN della specifica per riferimenti successivi. spec SN[SP 1 ]…[SP n ] given SP 1,…,SP m = SP

Traduzione CASL - Development Graph (4) Specifiche di base Specifiche di base La dichiarazione di tipi, operazioni, predicati e tipi di dati nel corpo contribuisce alla firma N. N = ( N, N, N ) N è definita come una relazione di conseguenza corrispondente alla relazione di soddisfazione di CASL. Ciascun tipo di dato libero o generazione di tipo risulta nellestensione di N per mezzo dello schema di induzione corrispondente. La definizione di operazioni e predicati, gli attributi di operazioni e predicati, la dichiarazione di selettori nelle dichiarazioni dei tipi di dati, e le dichiarazioni di tipi di dati liberi corrispondono tutti ad assiomi locali in N. Questi assiomi, rispettivamente, esprimono lequazione o equivalenza definita, lattributo, il risultato di applicazioni di selettori a termini, e liniettività dei costruttori.

Traduzione CASL - Development Graph (5) Specifiche strutturate Specifiche strutturate Tutte le regole di riscrittura per specifiche strutturate inseriscono un nodo vuoto che corrisponde alla specifica riscritta nel grafo di sviluppo. Con questo otteniamo una relazione stretta tra la struttura della specifica e la struttura del risultante grafo di sviluppo. Usando la corrispondenza possiamo affermare ladeguatezza della traduzione. Un riferimento ad una specifica non generica SN è tradotto in un nodo vuoto e un arco di definizione globale dal nodo con nome SN. Questo è il nodo corrispondente al corpo della definizione di specifica per SN.

Differenze tra DGR Il carattere evolutivo dello sviluppo formale di software implica che la specifica venga rivista diverse volte. Durante uno sviluppo formale, errori nelle specifiche sono rilevati mentre si tenta di dimostrare dei vincoli sulla prove. Questo porta a revisioni della specifica e nasce lesigenza di mantenere quante più prove possibili stabilite fino a quel punto. Inoltre, in pratica gli sviluppi formali sono spesso eseguiti da diversi sviluppatori, ciascuno dei quali revisiona indipendentemente la specifica originale a causa degli errori rilevati. Ad un certo punto, uniscono le varie specifiche modificate in una singola specifica. Di nuovo nasce lesigenza di preservare le prove stabilite da ciascun sviluppatore separatamente, incorporandole in un grafo di sviluppo corrispondente alla nuova specifica globale. Caso a singolo sviluppatore Caso a singolo sviluppatore Caso con più di uno sviluppatore Caso con più di uno sviluppatore

Differenze tra DGR (2) Caso a singolo sviluppatore Caso a singolo sviluppatore Specifica iniziale: S 1 DGR1 e DG1 differiscono per la decomposizione degli archi globali in archi locali e le prove degli archi locali, mentre i nodi sono esattamente gli stessi. Assumiamo che, a causa di un errore, la specifica iniziale debba essere modificata, ottenendo una specifica S2, che viene tradotta in una nuova rappresentazione DGR2. Devono essere determinate le modifiche, usate per mappare DG1 in DG2, dove DG2 corrisponde a DGR2. Naturalmente vanno preservate quante più prove possibili in DG1. Per questo fine, il grafo di sviluppo fornisce un insieme fissato di operazioni di base, come laddizione di singoli nodi, archi o assiomi in un nodo; le modifiche calcolate devono essere una sequenza di tali operazioni di base. Quindi, il risultato dellanalisi delle differenze tra DGR1 e DGR2 è un piano di lavoro per laggiornamento del grafo di sviluppo. Il problema di trovare le differenze tra la vecchia e la nuova rappresentazione del grafo di sviluppo consiste nel trovare le differenze tra due grafi e quindi tra i contenuti dei nodi e gli archi delle parti identificate.

Differenze tra DGR (3) Caso con più di uno sviluppatore Caso con più di uno sviluppatore Specifiche in input S 1 e S 2 sviluppate concorrentemente. Gli sviluppatori decidono di unire S 1 e S 2 nella nuova specifica globale S, che è tradotta in DGR. Sorge la necessità di unire i grafi di sviluppo DG 1 e DG 2 in modo da preservare quante più prove possibili contenute in DG 1 e DG 2. Lunione è ottenuta calcolando separatamente le modifiche da eseguire su DGR 1 e DGR 2 per ottenere la rappresentazione DGR. Queste modifiche 1 e 2 sono usate per trasformare i rispettivi grafi di sviluppo DG 1 e DG 2 nei grafi di sviluppo DG 1 e DG 2 (attraverso 1 e 2 ). Dal momento che DG 1 e DG 2 corrispondono entrambi a DGR, le loro strutture differiscono solo nelle prove, come la decomposizione di qualche arco di teorema globale, o prove di vincoli su archi di teorema locali. Quindi, i grafi di sviluppo sono uniti in un singolo grafo di sviluppo DG, che contiene lunione delle prove stabilite da entrambi gli sviluppatori.

Gestione delle modifiche in un DG Si studia il problema di cambiare un grafo di sviluppo preservando quanta più informazione possibile sulle prove (sotto forma di archi di teorema globali e locali). Definizione. Sia S un grafo di sviluppo. Un nodo M è raggiungibile globalmente da un nodo N attraverso una mappatura, N M S per brevità, sse o N = M e =, o N K S, K M S, con =. Un nodo M è raggiungibile localmente da un nodo N attraverso una mappatura, N M S per brevità, sse N M S o cè un nodo K con N M S, N M S, con =. Gli archi di teorema globali postulano proprietà tra teorie. La teoria di un nodo N è una proprietà non locale visto che dipende dalle teorie o dagli assiomi di altri nodi connessi con N. Quindi, gli archi di teorema globali descrivono proprietà tra sottografi e qualsiasi cambiamento allinterno di ciascuno di questi sottografi influisce su questa proprietà.

Gestione delle modifiche in un DG (2) Per arrivare ad una gestione efficiente dei cambiamenti cè bisogno di una descrizione più dettagliata per localizzare meglio gli effetti di un cambiamento. E allora necessario decomporre la proprietà tra sottografi in proprietà tra nodi e sottografi, descrivibili attraverso archi di teorema locali. Relazione tra archi di teorema globali e locali: Esiste un arco di teorema globale tra N e M se e solo se esiste un arco di teorema locale tra ogni nodo da cui N è raggiungibile localmente e M. Sussunzione di archi di teorema locali: Se S N K e K M allora S N o M

Gestione delle modifiche in un DG (3) Calcolo di riduzione Calcolo di riduzione Usando il calcolo di riduzione si può ottenere un approccio a due passi per stabilire le relazioni proposte dagli archi di teorema: Si fa uso della modularità e delle dipendenze nello sviluppo formale per dividere gli archi di teorema globali e minimizzare linsieme degli archi di teorema locali. Usando il calcolo di riduzione, si determinano quegli archi che sono già conseguenza di altri archi, arrivando ad ottenere un insieme di archi di teorema locali elementari ed indipendenti. In un secondo passo, si devono controllare i vincoli che possono insorgere da un arco di teorema elementare. Questo calcolo di riduzione non è in generale confluente, in quanto applicare le regole in modi diversi può portare ad ottenere diversi grafi di sviluppo.

Cambiare un Development Graph Lapplicazione del calcolo di riduzione dipende dalla struttura del grafo di sviluppo; i vincoli che insorgono da un arco di teorema elementare dipendono dagli assiomi locali del nodo sorgente e anche dal sottografo del nodo target. Cambiare uno di questi comporta ancora una volta cambiare i vincoli. Ciascun cambiamento nel grafo di sviluppo può rendere parti della verifica non valide. E necessario aggiustare in modo incrementale i vincoli, una volta che il grafo viene cambiato attraverso qualche operazione di base.

Cambiare un Development Graph (2) Assumiamo che linsieme di archi di teorema sia stato semplificato dal calcolo di riduzione. In particolare, ogni arco di teorema globale è stato decomposto in un insieme di archi di teorema locali. Per arrivare ad una gestione dei cambiamenti per un grafo di sviluppo, cè bisogno di una rappresentazione esplicita delle prove fatte dal calcolo di riduzione. La gestione dei cambiamenti riuserà le prove precedenti per aggiustare i vincoli una volta che il grafo di sviluppo è cambiato. Quindi, durante la prima fase, non si rimuovono gli archi di teorema globali o gli archi di teorema locali sussunti, ma si marcano come ridondanti, attaccando una qualche etichetta di validazione (per esempio la regola di riduzione istanziata che ha portato alla rimozione). Se si cambia il grafo di sviluppo, allora bisogna ricontrollare gli archi rimossi. Per ciascun arco si controlla o si aggiorna letichetta di validazione. Per ciascuna arco di teorema elementare bisogna aggiornare la lista dei vincoli e le rispettive prove. Operazioni di base del grafo di sviluppo prese in considerazione: laggiunta e la cancellazione di archi di definizione, laggiunta e la cancellazione di assiomi locali di una teoria, e il cambiamento di un morfismo attaccato ad un arco. (Laggiunta o la cancellazione di nodi non influisce in alcun modo sulla validità di archi di teorema.)

Conclusione E stata presentata la nozione di grafo di sviluppo come struttura dati di base per la codifica di specifiche CASL strutturate, per scopi di verifica. Vincoli sulla relazione tra specifiche danno luce ad archi di teorema, che denotano appunto vincoli sulle prove. Tali archi possono essere verificati o riducendoli ad altri archi già esistenti, o fornendo i corrispondenti teoremi esplicitamente. Cambiamenti nella sottostante specifica CASL sono propagati a cambiamenti (minimali) al grafo di sviluppo in modo da preservare quanto più lavoro di dimostrazione è già stato eseguito. Il framework presentato è già stato inplementato e testato con successo su vari esempi. (S. Autexier, D. Hutter, H. Mantel, A.Schairer. System description: INKA 5.0 – a logic voyager. In H. Ganziger (Ed.): 16th International Conference on Automated Deduction, Springer, LNAI 1632, 1999)