Towards an Towards an evolutionary Formal evolutionary Formal

Software-Software-Development Using Development Using

CASLCASLCorso di Metodi di Specifica dei Sistemi Corso di Metodi di Specifica dei Sistemi

SoftwareSoftwareA.A. 2004/05A.A. 2004/05

Docente: Prof. Giuseppe Scollo

Candidato: Giovanni Tommasi, in000569

ContenutiContenuti

IntroduzioneIntroduzione Development GraphDevelopment Graph Traduzione CASL – Development Traduzione CASL – Development

GraphGraph Differenze tra Development Graph Differenze tra Development Graph

RepresentationRepresentation Gestione delle modifiche in un DGGestione delle modifiche in un DG Cambiare un Development GraphCambiare un Development Graph

IntroduzioneIntroduzione

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)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 GraphDevelopment 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)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 KS S

K N S K N S

Th N Th K

N

Traduzione CASL - Development Traduzione CASL - Development GraphGraph

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 Traduzione CASL - Development Graph (2)Graph (2)

La costruzione di un DG è un’applicazione 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 Traduzione CASL - Development Graph (3)Graph (3)

Definizioni di specificaDefinizioni 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 l’annotazione del nome SN della specifica per riferimenti successivi.

spec SN[SP1’’]…[SPn’’] given SP1’,…,SPm’ = SP

Traduzione CASL - Development Traduzione CASL - Development Graph (4)Graph (4)

Specifiche di baseSpecifiche di base

La dichiarazione di tipi, operazioni, predicati e tipi di dati nel corpo contribuiscealla 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 nell’estensione 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 l’equazione o equivalenza definita, l’attributo, il risultato di applicazioni di selettori a termini, e l’iniettività dei costruttori.

Traduzione CASL - Development Traduzione CASL - Development Graph (5)Graph (5)

Specifiche strutturateSpecifiche 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 l’adeguatezza 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 DGRDifferenze 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 l’esigenza 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 l’esigenza di preservare le prove stabilite da ciascun sviluppatore separatamente, incorporandole in un grafo di sviluppo corrispondente alla nuova specifica globale.

Caso a singolo sviluppatoreCaso a singolo sviluppatore

Caso con più di uno sviluppatoreCaso con più di uno sviluppatore

Differenze tra DGR (2)Differenze tra DGR (2) Caso a singolo sviluppatoreCaso a singolo sviluppatore

Specifica iniziale: S1

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 l’addizione di singoli nodi, archi o assiomi in un nodo; le modifiche calcolate devono essere una sequenza di tali operazioni di base. Quindi, il risultato dell’analisi delle differenze tra DGR1 e DGR2 è un piano di lavoro per l’aggiornamento 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)Differenze tra DGR (3) Caso con più di uno sviluppatoreCaso con più di uno sviluppatore

Specifiche in input S1 e S2 sviluppate concorrentemente.

Gli sviluppatori decidono di unire S1 e S2 nella nuova specifica globale S, che è tradotta in DGR. Sorge la necessità di unire i grafi di sviluppo DG1 e DG2 in modo da preservare quante più prove possibili contenute in DG1 e DG2.

L’unione è ottenuta calcolando separatamente le modifiche da eseguire su DGR1 e DGR2 per ottenere la rappresentazione DGR. Queste modifiche 1 e 2 sono usate per trasformare i rispettivi grafi di sviluppo DG1 e DG2 nei grafi di sviluppo DG1’ e DG2’ (attraverso 1 e 2). Dal momento che DG1 e DG2 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 l’unione delle prove stabilite da entrambi gli sviluppatori.

Gestione delle modifiche in un Gestione delle modifiche in un DGDG

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 all’interno di ciascuno di questi sottografi influisce su questa proprietà.

Gestione delle modifiche in un Gestione delle modifiche in un DG (2)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 Gestione delle modifiche in un DG (3)DG (3)

Calcolo di riduzioneCalcolo 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 l’insieme 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 Cambiare un Development GraphGraph

L’applicazione 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 Cambiare un Development Graph (2)Graph (2)

Assumiamo che l’insieme di archi di teorema sia stato semplificato dal calcolo diriduzione. 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 l’etichetta 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: l’aggiunta e la cancellazione di archi di definizione, l’aggiunta e la cancellazione di assiomi locali di una teoria, e il cambiamento di un morfismo attaccato ad un arco. (L’aggiunta o la cancellazione di nodi non influisce in alcun modo sulla validità di archi di teorema.)

ConclusioneConclusione

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)