Progetto di un modello dell'informazione versionata e ... - InterDataNet
Progetto di un modello dell'informazione versionata e ... - InterDataNet
Progetto di un modello dell'informazione versionata e ... - InterDataNet
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
UNIVERSITÀ DEGLI STUDI DI FIRENZE<br />
Facoltà <strong>di</strong> Ingegneria<br />
Dipartimento <strong>di</strong> Elettronica e Telecom<strong>un</strong>icazioni<br />
Corso <strong>di</strong> Laurea in<br />
Ingegneria delle Telecom<strong>un</strong>icazioni P.O.<br />
<strong>Progetto</strong> <strong>di</strong> <strong>un</strong> <strong>modello</strong><br />
dell’informazione <strong>versionata</strong> e <strong>di</strong><br />
<strong>un</strong>’architettura <strong>di</strong> rete finalizzati<br />
al lavoro collaborativo<br />
Relatori<br />
Prof. Franco Pirri<br />
Prof. Dino Giuli<br />
Tesi <strong>di</strong> Laurea <strong>di</strong><br />
Davide Chini<br />
Correlatori<br />
Anno Accademico 2004/2005<br />
Ing. Samuele Innocenti<br />
Ing. Maria Chiara Pettenati
Ringraziamenti<br />
Ringrazio il Prof. Franco Pirri ed il Prof. Dino Giuli per avermi fornito<br />
l’opport<strong>un</strong>ità <strong>di</strong> svolgere il presente lavoro e per la <strong>di</strong>sponibilità <strong>di</strong>mostrata<br />
nei miei confronti.<br />
I miei ringraziamenti vanno inoltre all’Ing. Samuele Innocenti per tutto<br />
il tempo che mi ha de<strong>di</strong>cato, il supporto morale, la competenza nel settore<br />
messa a <strong>di</strong>sposizione e l’ottimo rapporto <strong>di</strong> collaborazione instaurato che ha<br />
guidato positivamente il mio lavoro.<br />
Ringrazio l’Ing. Maria Chiara Pettenati per i preziosi consigli e la <strong>di</strong>sponibilità<br />
che mi ha concesso.<br />
Grazie a tutte le persone presenti nel “Laboratorio <strong>di</strong> Tecnologie della<br />
Telematica” per gli ottimi rapporti stabiliti che mi hanno garantito <strong>un</strong>a<br />
con<strong>di</strong>zione <strong>di</strong> assoluta serenità durante lo svolgimento della tesi e <strong>un</strong> grazie<br />
particolare a Luca Capannesi per l’in<strong>di</strong>spensabile supporto tecnico.<br />
Un pensiero particolare va ai miei familiari: mi sono sempre stati vicini<br />
con tanto affetto e comprensione. La gioia che provo, a conclusione del mio<br />
percorso <strong>di</strong> stu<strong>di</strong>, so che è dovuta anche a loro.<br />
L’ultimo ringraziamento è per Michela che ha con<strong>di</strong>viso con me questo<br />
periodo così impegnativo, pieno <strong>di</strong> momenti <strong>di</strong>fficili e <strong>di</strong> rin<strong>un</strong>ce ma anche <strong>di</strong><br />
gran<strong>di</strong> sod<strong>di</strong>sfazioni.<br />
Firenze, 13 Aprile 2006<br />
Davide Chini
Everything should be made as simple as possible,<br />
but not one bit simpler.<br />
Attributed to Albert Einstein
Ai miei genitori
In<strong>di</strong>ce<br />
Introduzione xiii<br />
I Analisi del versioning in ambienti collaborativi 1<br />
1 Cooperazione e collaborazione nelle organizzazioni 2<br />
1.1 La gestione dei documenti . . . . . . . . . . . . . . . . . . . . 3<br />
1.2 Il lavoro collaborativo . . . . . . . . . . . . . . . . . . . . . . . 6<br />
1.2.1 Progettazione <strong>di</strong> groupware . . . . . . . . . . . . . . . 10<br />
1.2.2 I gruppi e la collaborazione . . . . . . . . . . . . . . . 11<br />
1.2.3 Requisiti generali per sistemi groupware . . . . . . . . 13<br />
1.2.4 Modelli <strong>di</strong> lavoro . . . . . . . . . . . . . . . . . . . . . 16<br />
1.3 Il concetto <strong>di</strong> configurazione . . . . . . . . . . . . . . . . . . . 18<br />
2 Versioning a supporto della collaborazione 23<br />
2.1 Il controllo delle versioni . . . . . . . . . . . . . . . . . . . . . 24<br />
2.2 Modelli <strong>di</strong> sincronizzazione . . . . . . . . . . . . . . . . . . . . 25<br />
2.2.1 Checkout/Checkin . . . . . . . . . . . . . . . . . . . . 26<br />
2.2.2 Composizione . . . . . . . . . . . . . . . . . . . . . . . 26<br />
2.2.3 Transazioni estese nel tempo . . . . . . . . . . . . . . . 27<br />
2.2.4 Change set . . . . . . . . . . . . . . . . . . . . . . . . 28<br />
2.3 Modelli <strong>di</strong> versioning . . . . . . . . . . . . . . . . . . . . . . . 30<br />
2.3.1 Modello intensionale . . . . . . . . . . . . . . . . . . . 30<br />
2.3.2 Modello estensionale . . . . . . . . . . . . . . . . . . . 32<br />
2.3.3 Valutazione dei modelli . . . . . . . . . . . . . . . . . . 32
In<strong>di</strong>ce<br />
2.3.4 Una nuova alternativa: UEVM . . . . . . . . . . . . . 33<br />
2.4 Unified Extensional Versioning Model . . . . . . . . . . . . . . 33<br />
2.4.1 Il <strong>modello</strong> . . . . . . . . . . . . . . . . . . . . . . . . . 34<br />
Il <strong>modello</strong> del documento . . . . . . . . . . . . . . . . . 34<br />
Esempio <strong>di</strong> documento strutturato . . . . . . . . . . . 38<br />
Versioning . . . . . . . . . . . . . . . . . . . . . . . . . 39<br />
Versioning <strong>di</strong> <strong>un</strong> singolo documento . . . . . . . . . . . 41<br />
Versioning <strong>di</strong> più documenti legati fra loro . . . . . . . 42<br />
2.4.2 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . 43<br />
UEVM dal p<strong>un</strong>to <strong>di</strong> vista dell’utente . . . . . . . . . . 43<br />
Gestione dell’esplosione combinatoria . . . . . . . . . . 43<br />
2.5 WebDAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44<br />
2.6 Revision Control System (RCS) . . . . . . . . . . . . . . . . . 45<br />
2.7 Concurrent Versions System (CVS) . . . . . . . . . . . . . . . 49<br />
2.7.1 CVS, evoluzione <strong>di</strong> RCS . . . . . . . . . . . . . . . . . 49<br />
2.7.2 Concetti <strong>di</strong> base . . . . . . . . . . . . . . . . . . . . . . 49<br />
Revisioni, branch e configurazioni . . . . . . . . . . . . 51<br />
2.8 Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53<br />
2.8.1 Concetti <strong>di</strong> base . . . . . . . . . . . . . . . . . . . . . . 55<br />
Numerazione esplicita delle configurazioni . . . . . . . 55<br />
2.9 L’ambiente integrato COOP/Orm . . . . . . . . . . . . . . . . 56<br />
2.9.1 Ambienti <strong>di</strong> sviluppo integrati . . . . . . . . . . . . . . 56<br />
2.9.2 Da Orm a COOP/Orm . . . . . . . . . . . . . . . . . . 57<br />
2.10 Sistemi <strong>di</strong> versioning peer-to-peer . . . . . . . . . . . . . . . . 59<br />
2.11 Valutazioni comparative . . . . . . . . . . . . . . . . . . . . . 61<br />
II Ambiente virtuale e <strong>modello</strong> dell’informazione 63<br />
3 Modello dell’ambiente virtuale 64<br />
3.1 Rappresentazione dell’ambiente . . . . . . . . . . . . . . . . . 65<br />
3.1.1 Le entità . . . . . . . . . . . . . . . . . . . . . . . . . . 65<br />
Avatar . . . . . . . . . . . . . . . . . . . . . . . . . . . 67<br />
Group . . . . . . . . . . . . . . . . . . . . . . . . . . . 68<br />
World . . . . . . . . . . . . . . . . . . . . . . . . . . . 68<br />
Stuff . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69<br />
3.2 Il <strong>modello</strong> delle interazioni . . . . . . . . . . . . . . . . . . . . 70<br />
v
In<strong>di</strong>ce<br />
3.2.1 Prima fase dell’interazione . . . . . . . . . . . . . . . . 72<br />
3.2.2 Seconda fase dell’interazione . . . . . . . . . . . . . . . 72<br />
3.3 Il delivery dell’informazione . . . . . . . . . . . . . . . . . . . 73<br />
4 Modello dell’informazione <strong>versionata</strong> D3IM 77<br />
4.1 Principi <strong>di</strong> strutturazione . . . . . . . . . . . . . . . . . . . . . 79<br />
4.1.1 Il concetto <strong>di</strong> responsabilità . . . . . . . . . . . . . . . 81<br />
4.2 I no<strong>di</strong> informativi del documento . . . . . . . . . . . . . . . . 81<br />
4.2.1 Identificazione dei no<strong>di</strong> e relativo accesso . . . . . . . . 82<br />
4.2.2 Informazioni atomiche . . . . . . . . . . . . . . . . . . 86<br />
4.2.3 Informazioni primitive . . . . . . . . . . . . . . . . . . 88<br />
4.3 Relazioni fra i no<strong>di</strong> informativi . . . . . . . . . . . . . . . . . 90<br />
4.4 Storico dei documenti . . . . . . . . . . . . . . . . . . . . . . . 91<br />
4.4.1 La propagazione delle mo<strong>di</strong>fiche . . . . . . . . . . . . . 93<br />
4.4.2 Authoring concorrente . . . . . . . . . . . . . . . . . . 94<br />
Controllo delle sessioni . . . . . . . . . . . . . . . . . . 95<br />
4.5 Lo stato <strong>di</strong> <strong>un</strong> documento . . . . . . . . . . . . . . . . . . . . 98<br />
4.5.1 Lo stato delle informazioni . . . . . . . . . . . . . . . . 98<br />
Lo stato delle informazioni atomiche . . . . . . . . . . 98<br />
Lo stato delle informazioni primitive . . . . . . . . . . 99<br />
III Dai modelli teorici all’architettura concreta 102<br />
5 Architettura CISA 103<br />
5.1 Visione stratificata <strong>di</strong> CISA . . . . . . . . . . . . . . . . . . . 104<br />
5.1.1 Application Layer . . . . . . . . . . . . . . . . . . . . . 108<br />
5.1.2 Virtual Repository Layer . . . . . . . . . . . . . . . . . 108<br />
Operazioni <strong>di</strong> base sulle entità . . . . . . . . . . . . . . 109<br />
5.1.3 Structure Layer . . . . . . . . . . . . . . . . . . . . . . 112<br />
5.1.4 Replica Management Layer . . . . . . . . . . . . . . . 112<br />
5.1.5 Me<strong>di</strong>um Dependent Layer . . . . . . . . . . . . . . . . 115<br />
5.2 CISA, sistema <strong>di</strong>stribuito . . . . . . . . . . . . . . . . . . . . . 115<br />
5.2.1 Control Plane . . . . . . . . . . . . . . . . . . . . . . . 116<br />
5.3 Definizione <strong>di</strong> livelli, servizi e processi . . . . . . . . . . . . . . 117<br />
vi
In<strong>di</strong>ce<br />
6 Versioning in CISA 126<br />
6.1 Da D3IM al versioning in CISA . . . . . . . . . . . . . . . . . 127<br />
6.2 Lo storico in CISA . . . . . . . . . . . . . . . . . . . . . . . . 128<br />
6.2.1 La struttura dello storico . . . . . . . . . . . . . . . . . 128<br />
D3IM nel layer Structure . . . . . . . . . . . . . . . . . 129<br />
6.2.2 Relazioni fra no<strong>di</strong> <strong>di</strong> livello Structure . . . . . . . . . . 130<br />
6.2.3 Gestione delle revisioni: la propagazione . . . . . . . . 133<br />
Propagazione “push” e propagazione “pull” . . . . . . . 135<br />
6.2.4 Branching e merging . . . . . . . . . . . . . . . . . . . 138<br />
Richiami <strong>di</strong> branching e merging in Subversion . . . . . 139<br />
Branching da D3IM a CISA . . . . . . . . . . . . . . . 141<br />
Merging da D3IM a CISA . . . . . . . . . . . . . . . . 145<br />
Gestione degli aspetti strutturali del documento . . . . 149<br />
6.2.5 La navigazione nello storico . . . . . . . . . . . . . . . 151<br />
6.2.6 I parametri <strong>di</strong> versione . . . . . . . . . . . . . . . . . . 153<br />
7 Il servizio fornito dal layer Structure 157<br />
7.1 Interfacce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158<br />
7.1.1 Interfaccia mostrata a Virtual Repository . . . . . . . . 159<br />
7.1.2 Interfaccia fornita da Replica Management . . . . . . . 165<br />
7.2 La struttura dati interna a Structure . . . . . . . . . . . . . . 169<br />
7.2.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . 169<br />
7.2.2 Descrizione dello XML Schema . . . . . . . . . . . . . 173<br />
7.3 Introduzione agli algoritmi . . . . . . . . . . . . . . . . . . . . 180<br />
7.3.1 Accesso ai documenti . . . . . . . . . . . . . . . . . . . 181<br />
7.3.2 Uso del parametro <strong>di</strong> versione . . . . . . . . . . . . . . 181<br />
Accesso alla versione . . . . . . . . . . . . . . . . . . . 182<br />
7.3.3 Mo<strong>di</strong>fica <strong>di</strong> documenti . . . . . . . . . . . . . . . . . . 186<br />
Il concetto <strong>di</strong> sessione . . . . . . . . . . . . . . . . . . . 191<br />
Servizi <strong>di</strong> branching e <strong>di</strong> merging . . . . . . . . . . . . 191<br />
8 Il servizio <strong>di</strong> risoluzione dei nomi 193<br />
8.1 Requisiti dei nomi . . . . . . . . . . . . . . . . . . . . . . . . . 194<br />
8.1.1 Requisiti per gli HFN . . . . . . . . . . . . . . . . . . . 195<br />
8.1.2 Requisiti per gli URN . . . . . . . . . . . . . . . . . . 195<br />
Requisiti non f<strong>un</strong>zionali . . . . . . . . . . . . . . . . . 196<br />
8.1.3 Requisiti sulla co<strong>di</strong>fica . . . . . . . . . . . . . . . . . . 197<br />
vii
In<strong>di</strong>ce<br />
8.2 LRI: gli identificatori logici delle risorse . . . . . . . . . . . . . 197<br />
8.3 PRI: gli identificatori persistenti . . . . . . . . . . . . . . . . . 199<br />
8.4 Logical DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201<br />
8.4.1 Supporto alla navigazione . . . . . . . . . . . . . . . . 210<br />
8.4.2 Espansione del Logical Name Space . . . . . . . . . . . 210<br />
Aggiornamento del database . . . . . . . . . . . . . . . 212<br />
8.4.3 Proprietà . . . . . . . . . . . . . . . . . . . . . . . . . 213<br />
8.5 Localization Service . . . . . . . . . . . . . . . . . . . . . . . . 213<br />
8.6 Risoluzione inversa . . . . . . . . . . . . . . . . . . . . . . . . 215<br />
8.7 Ottimizzare le prestazioni . . . . . . . . . . . . . . . . . . . . 221<br />
9 Protocolli <strong>di</strong> com<strong>un</strong>icazione e architettura <strong>di</strong> rete in CISA 222<br />
9.1 Interfacce e protocolli . . . . . . . . . . . . . . . . . . . . . . . 222<br />
9.1.1 Interfaccia bi<strong>di</strong>mensionale . . . . . . . . . . . . . . . . 225<br />
9.2 L’architettura <strong>di</strong> rete . . . . . . . . . . . . . . . . . . . . . . . 229<br />
9.2.1 Routing delle richieste . . . . . . . . . . . . . . . . . . 231<br />
9.2.2 Protocollo con delega . . . . . . . . . . . . . . . . . . . 232<br />
Conclusioni 235<br />
Bibliografia 240<br />
In<strong>di</strong>ce analitico 245<br />
viii
Elenco delle figure<br />
1.1 Gli strati <strong>di</strong> supporto alla collaborazione. . . . . . . . . . . . . 12<br />
1.2 Albero ottenibile dalla definizione ricorsiva <strong>di</strong> configurazione. . 20<br />
2.1 Rappresentazione della storia delle versioni. . . . . . . . . . . 25<br />
2.2 Para<strong>di</strong>gma <strong>di</strong> interazione. . . . . . . . . . . . . . . . . . . . . 27<br />
2.3 Esempi <strong>di</strong> applicazione della grammatica. . . . . . . . . . . . . 37<br />
2.4 Esempi <strong>di</strong> documento. . . . . . . . . . . . . . . . . . . . . . . 38<br />
2.5 Altri esempi <strong>di</strong> documenti strutturati: <strong>un</strong> libro e del co<strong>di</strong>ce<br />
Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39<br />
2.6 Alc<strong>un</strong>i cambiamenti all’interno della stessa sessione. . . . . . . 41<br />
2.7 La mo<strong>di</strong>fica <strong>di</strong> <strong>un</strong> link genera la nascita <strong>di</strong> <strong>un</strong>a nuova versione<br />
del documento. . . . . . . . . . . . . . . . . . . . . . . . . . . 42<br />
2.8 Gestione delle configurazioni in RCS. . . . . . . . . . . . . . . 47<br />
2.9 Evoluzione delle versioni in Subversion. . . . . . . . . . . . . . 56<br />
2.10 Topologie a stella ed albero. . . . . . . . . . . . . . . . . . . . 60<br />
3.1 Ruoli degli attori dell’ambiente virtuale. . . . . . . . . . . . . 66<br />
3.2 Il <strong>modello</strong> <strong>di</strong> interazione. . . . . . . . . . . . . . . . . . . . . . 71<br />
3.3 La notifica delle mo<strong>di</strong>fiche. . . . . . . . . . . . . . . . . . . . . 75<br />
4.1 Documento D3IM: DAG ed albero associato. . . . . . . . . . . 83<br />
4.2 Nomi <strong>di</strong> risorse replicate. . . . . . . . . . . . . . . . . . . . . . 85<br />
4.3 Stato “Update” delle informazioni. . . . . . . . . . . . . . . . . 92<br />
4.4 Generazione delle revisioni. . . . . . . . . . . . . . . . . . . . . 93<br />
4.5 Casi <strong>di</strong> authoring concorrente. . . . . . . . . . . . . . . . . . . 95<br />
4.6 Stati <strong>di</strong> <strong>un</strong>’informazione atomica. . . . . . . . . . . . . . . . . 99
Elenco delle figure<br />
4.7 Stati <strong>di</strong> <strong>un</strong>’informazione primitiva. . . . . . . . . . . . . . . . 100<br />
5.1 Livelli dell’architettura CISA. . . . . . . . . . . . . . . . . . . 105<br />
5.2 Para<strong>di</strong>gma <strong>di</strong> interazione request/response. . . . . . . . . . . . 107<br />
5.3 La pila CISA più nel dettaglio. . . . . . . . . . . . . . . . . . 116<br />
5.4 Livelli, servizi e processi. . . . . . . . . . . . . . . . . . . . . . 121<br />
6.1 No<strong>di</strong> <strong>di</strong> livello Structure. . . . . . . . . . . . . . . . . . . . . . 130<br />
6.2 Gestione dei link <strong>di</strong> propagazione. . . . . . . . . . . . . . . . . 131<br />
6.3 Concessione dei <strong>di</strong>ritti <strong>di</strong> mo<strong>di</strong>fica a tutti i responsabili nella<br />
gerarchia <strong>di</strong> successori. . . . . . . . . . . . . . . . . . . . . . . 137<br />
6.4 Organizzazione tipica <strong>di</strong> <strong>un</strong> progetto gestito con Subversion. . 140<br />
6.5 Risultato della copia <strong>di</strong> <strong>un</strong> file in Subversion: branch in D3IM. 143<br />
6.6 Risultato della copia <strong>di</strong> <strong>un</strong>a <strong>di</strong>rectory in Subversion. . . . . . . 144<br />
6.7 Branch in D3IM con <strong>un</strong> figlio con<strong>di</strong>viso. . . . . . . . . . . . . 145<br />
6.8 Propagazione in presenza <strong>di</strong> <strong>un</strong> figlio con<strong>di</strong>viso. . . . . . . . . 145<br />
6.9 Merge <strong>di</strong> due no<strong>di</strong>. . . . . . . . . . . . . . . . . . . . . . . . . 147<br />
6.10 Propagazione a seguito <strong>di</strong> <strong>un</strong> merge. . . . . . . . . . . . . . . 148<br />
6.11 Gestione <strong>di</strong> due rami <strong>di</strong> sviluppo concorrente. . . . . . . . . . 149<br />
6.12 Branch <strong>di</strong> <strong>un</strong> intero documento. . . . . . . . . . . . . . . . . . 151<br />
6.13 Sintassi degli in<strong>di</strong>rizzi <strong>di</strong> livello Structure. . . . . . . . . . . . 152<br />
6.14 Esempio <strong>di</strong> elemento più recente relativamente al nodo <strong>di</strong> partenza.<br />
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155<br />
6.15 Esempi <strong>di</strong> “last” relativi al branch. . . . . . . . . . . . . . . . . 155<br />
7.1 Casi d’uso relativi all’interfaccia mostrata da Structure a Virtual<br />
Repository. . . . . . . . . . . . . . . . . . . . . . . . . . . 160<br />
7.2 Casi d’uso relativi all’interfaccia mostrata a Structure da Repository<br />
Management. . . . . . . . . . . . . . . . . . . . . . . 166<br />
7.3 Albero del XML Schema: visione globale. . . . . . . . . . . . . 174<br />
7.4 Albero del XML Schema: particolare dei link <strong>di</strong> versione. . . . 175<br />
7.5 XML Schema che rappresenta gli in<strong>di</strong>rizzi PRI. . . . . . . . . 175<br />
7.6 Espressione regolare che definisce gli identificativi <strong>di</strong> versione. 177<br />
7.7 Convenzione sui nomi dei no<strong>di</strong> relativi allo storico. . . . . . . . 178<br />
7.8 Accesso al nodo “last” in tempo costante. . . . . . . . . . . . . 183<br />
7.9 Diagramma <strong>di</strong> sequenza relativo all’accesso ad <strong>un</strong> documento. 185<br />
7.10 Diagramma <strong>di</strong> sequenza relativo alla prenotazione per la mo<strong>di</strong>fica<br />
<strong>di</strong> <strong>un</strong> documento. . . . . . . . . . . . . . . . . . . . . . . 188<br />
x
Elenco delle figure<br />
7.11 Diagramma <strong>di</strong> sequenza relativo alla richiesta <strong>di</strong> salvataggio<br />
<strong>di</strong> <strong>un</strong> documento. . . . . . . . . . . . . . . . . . . . . . . . . . 190<br />
8.1 Sintassi dei Logical Name. . . . . . . . . . . . . . . . . . . . . 198<br />
8.2 Espressione regolare che definisce i PRI in CISA. . . . . . . . 199<br />
8.3 Sintassi dei PRI in CISA espressa tramite BNF. . . . . . . . . 200<br />
8.4 Associazione tra LRI, PRI ed URL. . . . . . . . . . . . . . . . 201<br />
8.5 Esempio <strong>di</strong> Logical Name Space. . . . . . . . . . . . . . . . . . 202<br />
8.6 Esempio <strong>di</strong> sud<strong>di</strong>visione in zone del LNSP. . . . . . . . . . . . 204<br />
8.7 Esempio <strong>di</strong> albero delle zone. . . . . . . . . . . . . . . . . . . 204<br />
8.8 Risoluzione senza Look-Ahead. . . . . . . . . . . . . . . . . . 206<br />
8.9 Risoluzione con Look-Ahead. . . . . . . . . . . . . . . . . . . . 206<br />
8.10 Richieste ricorsive per la risoluzione. . . . . . . . . . . . . . . 209<br />
8.11 Esempio <strong>di</strong> LS. . . . . . . . . . . . . . . . . . . . . . . . . . . 214<br />
8.12 Schema per la risoluzione inversa. . . . . . . . . . . . . . . . . 215<br />
8.13 Tabelle necessarie per la risoluzione inversa iterativa. . . . . . 218<br />
9.1 Bi<strong>di</strong>mensionalità dell’interfaccia fra processi. . . . . . . . . . . 223<br />
9.2 Inter-Application Comm<strong>un</strong>ication System. . . . . . . . . . . . 227<br />
9.3 Esempio <strong>di</strong> scenario <strong>di</strong> utilizzo <strong>di</strong> CISA. . . . . . . . . . . . . 230<br />
9.4 Esempio <strong>di</strong> interazione con protocollo con delega. . . . . . . . 233<br />
xi
Elenco delle tabelle<br />
1.1 Modello Johansen. . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
1.2 Requisiti per sistemi groupware. . . . . . . . . . . . . . . . . . 13<br />
1.3 Struttura e dati <strong>di</strong> <strong>un</strong> documento. . . . . . . . . . . . . . . . . 19<br />
2.1 Approcci <strong>di</strong> versioning adottati dai CM sui vari tipi <strong>di</strong> entità. 34<br />
2.2 Grammatica che definisce la struttura del documento. . . . . . 35<br />
4.1 Mappa per la determinazione degli stati. . . . . . . . . . . . . 101<br />
5.1 Decomposizione dei ruoli degli utenti. . . . . . . . . . . . . . . 109
Introduzione<br />
Le tecnologie telematiche hanno ra<strong>di</strong>calmente trasformato, e lo stanno<br />
facendo tuttora, tutti i processi aziendali ed i vari para<strong>di</strong>gmi operativi dando<br />
vita ad <strong>un</strong>a nuova concezione <strong>di</strong> lavoro collaborativo. Questi cambiamenti<br />
sono avvenuti grazie alle capacità <strong>di</strong> elaborazione dei calcolatori elettronici<br />
ed a quelle <strong>di</strong> scambio <strong>di</strong> informazioni fornite dalle reti <strong>di</strong> telecom<strong>un</strong>icazione.<br />
Tali caratteristiche sono state ampiamente sfruttate per realizzare sistemi<br />
finalizzati al supporto della collaborazione.<br />
Nello sviluppo <strong>di</strong> <strong>un</strong> progetto collaborativo è possibile ottenere notevoli<br />
vantaggi mantenendo sotto il controllo delle versioni le varie fasi evolutive<br />
del lavoro effettuato ovvero applicando tecniche, più o meno sofisticate, <strong>di</strong><br />
versioning.<br />
Il versioning consiste nell’archiviare opport<strong>un</strong>e informazioni al fine <strong>di</strong><br />
poter ripercorrere tutte le tappe che hanno contribuito al raggi<strong>un</strong>gimento<br />
dei risultati attuali. Questo consente, ad esempio, <strong>di</strong> ripristinare il progetto<br />
sulla base <strong>di</strong> <strong>un</strong>o stato evolutivo precedente al fine <strong>di</strong> annullare operazioni che<br />
hanno in<strong>di</strong>rizzato lo sviluppo verso risultati non sod<strong>di</strong>sfacenti.<br />
I benefici sono più che evidenti nel caso in cui i risultati raggi<strong>un</strong>ti siano<br />
il frutto della collaborazione <strong>di</strong> <strong>un</strong> insieme eterogeneo <strong>di</strong> in<strong>di</strong>vidui che<br />
si <strong>di</strong>fferenziano in base alle loro caratteristiche e professionalità, ma anche<br />
relativamente al luogo e all’istante temporale in cui operano. In tal caso il<br />
versioning permette <strong>di</strong> tracciare le azioni dei vari utenti al fine <strong>di</strong> rendere<br />
ogni in<strong>di</strong>viduo maggiormente responsabile e consapevole del lavoro svolto. In<br />
questo modo si contribuisce ad incrementare il grado <strong>di</strong> conoscenza che ogn<strong>un</strong>o<br />
ha sul proprio lavoro, su quello degli altri ed in generale sullo stato globale<br />
del progetto (awareness).
Introduzione<br />
Non deve sorprendere che, lavorando quoti<strong>di</strong>anamente con questi strumenti,<br />
i primi sistemi <strong>di</strong> controllo delle versioni si siano sviluppati nell’ambito<br />
dell’ingegneria del software per il supporto allo sviluppo <strong>di</strong> co<strong>di</strong>ce sorgente.<br />
Il motivo è comprensibile in quanto gli esperti del settore hanno avuto sia la<br />
necessità <strong>di</strong> dover lavorare con strumenti finalizzati alla collaborazione che le<br />
capacità <strong>di</strong> realizzarli.<br />
Naturalmente sono stati sviluppati anche sistemi finalizzati ad essere utilizzati<br />
in ambienti del tutto estranei allo sviluppo del software, con l’intento<br />
<strong>di</strong> supportare tutti i processi aziendali come quelli, ad esempio, commerciali,<br />
amministrativi o produttivi. Normalmente questi ambienti <strong>di</strong> lavoro<br />
forniscono molte altre f<strong>un</strong>zionalità in aggi<strong>un</strong>ta al versioning, come la gestione<br />
avanzata degli utenti e dei loro <strong>di</strong>ritti; l’archiviazione, l’in<strong>di</strong>cizzazione e la<br />
con<strong>di</strong>visione dei documenti; l’utilizzo <strong>di</strong> lavagne con<strong>di</strong>vise e <strong>di</strong> altri strumenti<br />
per la com<strong>un</strong>icazione in tempo reale ed asincrona.<br />
Questi sistemi possono essere sud<strong>di</strong>visi in opport<strong>un</strong>e categorie che <strong>di</strong>pendono<br />
dalle f<strong>un</strong>zionalità peculiari che offrono. Si parla ad esempio <strong>di</strong> Document<br />
Management Systems (DMS) nel caso in cui la principale caratteristica sia<br />
quella <strong>di</strong> archiviare ed in<strong>di</strong>cizzare documenti intesi nel senso convenzionale<br />
del termine e gestirne il relativo workflow. I Content Management Systems<br />
(CMS) <strong>di</strong>fferiscono dai precedenti in quanto il concetto <strong>di</strong> documento<br />
scompare a favore della definizione <strong>di</strong> <strong>un</strong> formato dell’informazione interno<br />
al sistema stesso. Recentemente è stato introdotto il concetto <strong>di</strong> Enterprise<br />
Content Management (ECM ) che rappresenta <strong>un</strong> insieme <strong>di</strong> tecnologie<br />
finalizzate all’acquisizione, gestione, memorizzazione e <strong>di</strong>stribuzione <strong>di</strong> contenuti<br />
informativi e documenti relativi a tutti i processi organizzativi. In<br />
questi termini i sistemi per l’ECM risultano quelli più generali e si inquadrano<br />
principalmente nel contesto delle gran<strong>di</strong> organizzazioni, nelle quali le<br />
problematiche menzionate risultano particolarmente evidenti.<br />
Tutti i sistemi che rientrano nelle categorie precedenti trattano e gestiscono<br />
le informazioni definite secondo specifiche <strong>di</strong>verse perché sebbene esista<br />
<strong>un</strong>o standard per l’infrastruttura <strong>di</strong> com<strong>un</strong>icazione tra piattaforme eterogenee<br />
(TCP/IP), altrettanto non si può <strong>di</strong>re per la rappresentazione dell’informazione.<br />
In generale ogni contesto organizzativo definisce <strong>un</strong>a propria<br />
rappresentazione per la base <strong>di</strong> conoscenza e questo impe<strong>di</strong>sce il completo<br />
interscambio dei dati. Una possibile soluzione finalizzata a definire <strong>un</strong>a<br />
rappresentazione omogenea dell’informazione viene <strong>di</strong>scussa nella <strong>di</strong>ssertazione<br />
<strong>di</strong> laurea [Inn04] dal titolo “Modello dell’informazione per documen-<br />
xiv
Introduzione<br />
ti <strong>di</strong>stribuiti e delocalizzati a supporto della cooperazione applicativa nelle<br />
Pubbliche Amministrazioni”, nella quale viene analizzato lo scenario che si<br />
presenta nelle Pubbliche Amministrazioni (P.A.). Le P.A. sono particolari<br />
enti <strong>di</strong>stribuiti in modo omogeneo sul territorio nazionale che detengono e<br />
devono gestire <strong>un</strong>’enorme quantità <strong>di</strong> informazioni eterogenee, <strong>di</strong>slocate e regolamentate<br />
<strong>un</strong>iformemente, sia nei contenuti che nel ciclo <strong>di</strong> vita, da leggi<br />
ed atti amministrativi. Questo contesto risulta appropriato per lo stu<strong>di</strong>o<br />
<strong>di</strong> sistemi finalizzati al lavoro collaborativo in quanto i requisiti, particolarmente<br />
restrittivi, che devono essere sod<strong>di</strong>sfatti portano a presumere che i<br />
risultati raggi<strong>un</strong>ti potranno essere agevolmente applicati anche nel caso <strong>di</strong><br />
organizzazioni <strong>di</strong> tipo <strong>di</strong>verso.<br />
Al fine <strong>di</strong> affrontare le varie problematiche in modo efficace, sono stati<br />
messi in evidenza gli aspetti e le proprietà fondamentali delle informazioni<br />
che sono state in<strong>di</strong>viduate nel contesto delle Pubbliche Amministrazioni<br />
ed applicabili anche in altri ambiti. Tali proprietà risultano infatti <strong>di</strong> carattere<br />
generale e proprie <strong>di</strong> qualsiasi tipologia <strong>di</strong> documento. Tutte queste<br />
caratteristiche sono alla base <strong>di</strong> <strong>un</strong> <strong>modello</strong> dell’informazione denominato<br />
“Distributed Delocalized Document Information Model” (D3IM). Tale <strong>modello</strong><br />
è <strong>di</strong>stribuito ed in<strong>di</strong>pendente dalla localizzazione fisica (delocalizzato);<br />
inoltre tutte le scelte che hanno portato alla sua definizione sono state effettuate<br />
principalmente con l’intento <strong>di</strong> sod<strong>di</strong>sfare il requisito non f<strong>un</strong>zionale <strong>di</strong><br />
scalabilità.<br />
L’obiettivo del presente lavoro <strong>di</strong> tesi è quello <strong>di</strong> progettare <strong>un</strong>’infrastruttura<br />
a supporto dell’Enterprise Content Management, nella quale il versioning<br />
riveste <strong>un</strong>o dei ruoli <strong>di</strong> importanza primaria, che aggiornerà ed estenderà<br />
il <strong>modello</strong> D3IM. Le operazioni che verranno effettuate consistono nello scindere<br />
tutti gli aspetti riguardanti il vero e proprio <strong>modello</strong> dell’informazione<br />
dagli aspetti architetturali ed implementativi. Ciò darà vita ad <strong>un</strong>’evoluzione<br />
<strong>di</strong> D3IM che risulterà astratta e consistente, in<strong>di</strong>pendentemente dai modelli<br />
dei dati concreti che verranno sviluppati e dalle specifiche implementazioni<br />
architetturali. Volendo sfruttare <strong>un</strong>’analogia è possibile <strong>di</strong>re che D3IM starà<br />
alla programmazione orientata agli oggetti come i vari modelli dei dati a cui<br />
darà vita staranno agli specifici linguaggi <strong>di</strong> programmazione (ad esempio<br />
C++, Java, etc.). Oppure, nell’ambito delle telecom<strong>un</strong>icazioni, D3IM potrà<br />
essere messo in relazione alla pila ISO/OSI mentre i vari modelli dei dati alle<br />
varie implementazioni dello stack <strong>di</strong> rete (ad esempio TCP/IP).<br />
Sulla base del <strong>modello</strong> attuale dell’informazione verrà progettata anche<br />
xv
Introduzione<br />
<strong>un</strong>’architettura <strong>di</strong>stribuita, denominata Collaborative Information System<br />
Architecture (CISA), che definirà <strong>un</strong> proprio <strong>modello</strong> dei dati conforme a<br />
D3IM. Tale architettura sarà progettata seguendo <strong>un</strong> approccio stratificato<br />
similmente a quanto realizzato nell’ambito delle telecom<strong>un</strong>icazioni per quanto<br />
riguarda l’infrastruttura <strong>di</strong> rete.<br />
Verranno definite le f<strong>un</strong>zionalità degli strati e progettati i sistemi che<br />
sono stati in<strong>di</strong>viduati per espletarle, dando particolare enfasi al livello che si<br />
occupa della gestione delle versioni.<br />
Il presente lavoro <strong>di</strong> tesi è sud<strong>di</strong>viso in tre parti:<br />
Parte I (Capitoli 1 e 2).<br />
Riguarda la definizione del problema del lavoro collaborativo e la descrizione<br />
dello stato dell’arte relativamente ai sistemi <strong>di</strong> controllo delle versioni.<br />
Parte II (Capitoli 3 e 4).<br />
Illustra la definizione del <strong>modello</strong> astratto dell’informazione D3IM.<br />
Parte III (Capitoli da 5 a 9).<br />
Riguarda la progettazione dell’architettura CISA.<br />
In particolare i singoli capitoli trattano i seguenti argomenti:<br />
Capitolo 1.<br />
Lavoro collaborativo in ambiente <strong>di</strong>stribuito e descrizione dei requisiti desiderabili<br />
per <strong>un</strong> sistema groupware.<br />
Capitolo 2.<br />
Controllo delle versioni, modelli <strong>di</strong> sincronizzazione per l’accesso a risorse<br />
con<strong>di</strong>vise e versionate; stato dell’arte <strong>di</strong> sistemi per il controllo delle versioni<br />
finalizzati allo sviluppo collaborativo <strong>di</strong> progetti software.<br />
Capitolo 3.<br />
Definizione <strong>di</strong> ambiente virtuale, <strong>modello</strong> delle interazioni e delivery dell’informazione.<br />
xvi
Introduzione<br />
Capitolo 4.<br />
Modello dell’informazione <strong>versionata</strong> D3IM, concetto <strong>di</strong> documento strutturato<br />
e <strong>di</strong> responsabilità, classificazione, identificazione dell’informazione,<br />
storico e stato dei documenti.<br />
Capitolo 5.<br />
Architettura stratificata CISA basata sul <strong>modello</strong> D3IM, descrizione dei livelli<br />
e <strong>modello</strong> <strong>di</strong>stribuito dell’architettura.<br />
Capitolo 6.<br />
Modello <strong>di</strong> versioning in CISA, formalizzazione dello storico delle informazioni<br />
nel contesto dell’architettura.<br />
Capitolo 7.<br />
Progettazione dettagliata dello storico, interfacciamento verso il sottosistema<br />
<strong>di</strong> gestione del versioning con relativo <strong>modello</strong> dei dati ed algoritmi operativi.<br />
Capitolo 8.<br />
Sistema <strong>di</strong> nomi a tre livelli e servizio <strong>di</strong> risoluzione dei nomi. Nomi logici utilizzati<br />
dall’uomo e nomi persistenti utilizzati dal sistema per l’identificazione<br />
<strong>un</strong>ivoca delle risorse, risoluzione da nomi logici in persistenti e risoluzione da<br />
nomi persistenti in URL per l’accesso.<br />
Capitolo 9.<br />
Infrastruttura <strong>di</strong> com<strong>un</strong>icazione client/server fra i vari sistemi <strong>di</strong> CISA, interfaccia<br />
“bi<strong>di</strong>mensionale” ed architettura <strong>di</strong> rete.<br />
xvii
Parte I<br />
Analisi del versioning in<br />
ambienti collaborativi
Capitolo<br />
1<br />
Cooperazione e collaborazione nelle<br />
organizzazioni<br />
In questo capitolo verranno presentati i problemi, le proprietà ed i requisiti<br />
relativi alla gestione collaborativa dell’informazione all’interno delle<br />
organizzazioni.<br />
Verranno esposte ed analizzate le principali caratteristiche della gestione<br />
dei documenti, fornendo <strong>un</strong> quadro esplicativo delle organizzazioni e in<br />
generale <strong>di</strong> ciò che attiene al lavoro collaborativo.<br />
L’obiettivo della cooperazione è <strong>di</strong> consentire ad <strong>un</strong> insieme <strong>di</strong> risorse,<br />
siano esse processi o persone, <strong>di</strong> lavorare insieme per risolvere efficientemente<br />
<strong>un</strong> problema com<strong>un</strong>e.<br />
Le caratteristiche fondamentali <strong>di</strong> <strong>un</strong> ambiente collaborativo sono costituite<br />
sia dalla rappresentazione, gestione e con<strong>di</strong>visione dell’informazione che<br />
dai para<strong>di</strong>gmi <strong>di</strong> interazione; esiste quin<strong>di</strong> la necessità <strong>di</strong> concordare convenzioni<br />
e regole <strong>di</strong> linguaggio com<strong>un</strong>i in modo da permettere ai vari soggetti<br />
<strong>un</strong>a efficace intercom<strong>un</strong>icazione.<br />
Uno dei p<strong>un</strong>ti centrali per sod<strong>di</strong>sfare queste esigenze è la realizzazione<br />
<strong>di</strong> <strong>un</strong>a completa integrazione attraverso la con<strong>di</strong>visione delle risorse, delle<br />
procedure adottate all’interno <strong>di</strong> <strong>un</strong>’organizzazione e dei dati detenuti da<br />
ogni entità coinvolta.
Cooperazione e collaborazione nelle organizzazioni La gestione dei documenti<br />
1.1 La gestione dei documenti<br />
La con<strong>di</strong>visione dell’informazione è il presupposto al lavoro collaborativo.<br />
Se non esiste passaggio <strong>di</strong> informazione gli in<strong>di</strong>vidui rimangono alienati ed i<br />
sistemi isolati. Tale informazione è convenzionalmente e storicamente rappresentata<br />
all’interno <strong>di</strong> documenti (cartacei o elettronici), il cui volume cresce<br />
proporzionalmente al tempo, al numero <strong>di</strong> persone e all’efficienza delle tecnologie.<br />
Per rendere umanamente trattabili enormi quantità <strong>di</strong> documenti e la<br />
loro evoluzione sono necessari strumenti capaci <strong>di</strong> memorizzarli, coor<strong>di</strong>narne<br />
gli accessi, ricercare e mantenere la consistenza dei dati entro contenuti.<br />
Con Document Management (DM ) si intende il controllo automatizzato<br />
dei documenti elettronici (immagini, fogli <strong>di</strong> calcolo, testi) inerente al loro<br />
completo ciclo <strong>di</strong> vita all’interno <strong>di</strong> <strong>un</strong>’organizzazione, dalla iniziale creazione<br />
alla finale archiviazione [Cle95]. Il Document Management permette<br />
alle organizzazioni <strong>di</strong> esercitare <strong>un</strong> grande controllo sulla produzione, sull’immagazzinamento<br />
e sulla <strong>di</strong>stribuzione dei documenti, consentendo <strong>di</strong> riusare<br />
l’informazione, controllarne il workflow 1 e ridurre i tempi <strong>di</strong> produzione dei<br />
manoscritti.<br />
Complessivamente l’insieme <strong>di</strong> f<strong>un</strong>zionalità che <strong>un</strong> sistema <strong>di</strong> DM può<br />
realizzare copre vari aspetti quali l’identificazione, l’immagazzinamento, il<br />
recupero, la tracciabilità, il controllo delle versioni, la gestione del workflow<br />
e la presentazione.<br />
Tra<strong>di</strong>zionalmente i sistemi <strong>di</strong> DM sono classificati in gestionali <strong>di</strong> documenti<br />
non e<strong>di</strong>tabili e gestionali <strong>di</strong> documenti e<strong>di</strong>tabili [Cle95]. Queste due<br />
classi <strong>di</strong>fferiscono notevolmente per il fatto che i primi trattano artefatti<br />
statici, mentre i secon<strong>di</strong> artefatti <strong>di</strong>namici. I sistemi della prima categoria<br />
concentrano l’attenzione sull’accesso, l’acquisizione, l’in<strong>di</strong>cizzazione e il recupero,<br />
mentre i secon<strong>di</strong> sulla creazione collaborativa, authoring 2 , workflow e<br />
controllo delle revisioni.<br />
Attualmente la <strong>di</strong>stinzione in queste due classi è puramente storica. I<br />
recenti sistemi tendono ad incorporare <strong>un</strong> largo insieme <strong>di</strong> f<strong>un</strong>zionalità con<br />
la finalità <strong>di</strong> superare le <strong>di</strong>visioni tra <strong>un</strong>ità organizzative, piattaforme e spe-<br />
1 Secondo la definizione della Workflow Management Coalition [Coa06], il workflow è:<br />
“L’automazione <strong>di</strong> <strong>un</strong>a parte o dell’intero processo aziendale dove documenti, informazioni<br />
e compiti vengono passati da <strong>un</strong> partecipante ad <strong>un</strong> altro per ricevere qualche tipo <strong>di</strong><br />
azione, seguendo <strong>un</strong> determinato insieme <strong>di</strong> regole”.<br />
2 Per authoring si intende l’insieme dei processi finalizzati alla creazione <strong>di</strong><br />
<strong>un</strong>’informazione.<br />
3
Cooperazione e collaborazione nelle organizzazioni La gestione dei documenti<br />
cifiche applicazioni, abbracciando l’uso e il controllo dei documenti in tutta<br />
la loro vita.<br />
È importante notare che DM non è <strong>un</strong>a singola tecnologia, ma <strong>un</strong> insieme<br />
<strong>di</strong> tecniche e tecnologie atte alla realizzazione <strong>di</strong> <strong>un</strong> sistema integrato.<br />
Accor<strong>di</strong> bilaterali su standard com<strong>un</strong>i e alleanze tra organizzazioni facilitano<br />
questo processo <strong>di</strong> integrazione spesso fondato su <strong>un</strong> approccio aperto.<br />
Con Document Management Systems (DMS) si intendono sistemi software<br />
che svolgono, tutte o in parte, le f<strong>un</strong>zionalità previste nel contesto del<br />
Document Management.<br />
Normalmente in sistemi <strong>di</strong> questo tipo possono essere in<strong>di</strong>viduate le seguenti<br />
caratteristiche [Rob06]:<br />
• i documenti gestiti vanno intesi nel senso convenzionale del termine<br />
ovvero si tratta <strong>di</strong> testi, fogli <strong>di</strong> calcolo, eccetera;<br />
• ogni documento (<strong>un</strong>ità informativa elementare dal p<strong>un</strong>to <strong>di</strong> vista del<br />
DM) è piuttosto ampio e completo in quanto contiene tutti i dati<br />
necessari alla sua fruizione (è ben definito come entità in<strong>di</strong>viduale);<br />
• le relazioni fra documenti <strong>di</strong>stinti, se esistono, sono in numero limitato;<br />
• i documenti vengono salvati e gestiti nel loro formato nativo;<br />
• i DMS sono orientati principalmente al salvataggio e all’archiviazione<br />
dell’informazione;<br />
• i DMS prevedono sofisticati meccanismi <strong>di</strong> gestione del workflow dell’informazione.<br />
I DMS sono sistemi ormai consolidati e presenti nel mercato da molti<br />
anni. Più recentemente è stato introdotto il concetto <strong>di</strong> Content Management<br />
(CM ) che si <strong>di</strong>fferenzia dal precedente in quanto tratta quei processi e<br />
tecnologie finalizzati a supportare l’evoluzione temporale <strong>di</strong> generiche informazioni<br />
in formato <strong>di</strong>gitale durante il loro intero ciclo <strong>di</strong> vita. In questo caso<br />
il concetto <strong>di</strong> documento convenzionale viene perso a favore <strong>di</strong> <strong>un</strong> formato<br />
dell’informazione definito interamente o parzialmente nel contesto del CM<br />
stesso.<br />
I Content Management Systems (CMS) sono i sistemi software finalizzati<br />
al CM e, normalmente, hanno le seguenti caratteristiche:<br />
4
Cooperazione e collaborazione nelle organizzazioni La gestione dei documenti<br />
• gestiscono <strong>un</strong>ità informative molto piccole ed interconnesse (come, ad<br />
esempio, le pagine web);<br />
• l’interconnessione fra le varie <strong>un</strong>ità è elevata;<br />
• sono specializzati nel supporto alla redazione e pubblicazione delle<br />
informazioni;<br />
• si basano su <strong>un</strong> formato dei dati proprietario.<br />
È evidente che i DMS ed i CMS hanno molte caratteristiche in com<strong>un</strong>e<br />
pur non risolvendo esattamente le stesse problematiche inerenti alla gestione<br />
delle informazioni.<br />
Attualmente la <strong>di</strong>sciplina che tratta tutte le problematiche affrontate e<br />
gestite sia nel contesto dei DM che dei CM è chiamata Enterprise Content<br />
Management (ECM ).<br />
In generale è possibile in<strong>di</strong>viduare varie fasi attraversate dall’informazione<br />
(in qual<strong>un</strong>que forma essa sia) durante il suo ciclo <strong>di</strong> vita. Tali fasi sono le<br />
seguenti:<br />
• creazione, operazione effettuata da <strong>un</strong>o o più autori con il fine <strong>di</strong> creare<br />
l’informazione;<br />
• aggiornamento, operazione effettuata da <strong>un</strong>o o più autori con il fine <strong>di</strong><br />
mo<strong>di</strong>ficare <strong>un</strong>’informazione già esistente;<br />
• pubblicazione, operazione che permette <strong>di</strong> attestare la vali<strong>di</strong>tà <strong>di</strong> <strong>un</strong>’informazione<br />
con il fine <strong>di</strong> renderla <strong>di</strong>sponibile a tutti gli interessati per<br />
la fruizione;<br />
• traduzione, operazione che consiste nel trasformare <strong>un</strong>’informazione in<br />
<strong>un</strong> formato <strong>di</strong>verso;<br />
• archiviazione, operazione che consiste nel classificare e memorizzare<br />
opport<strong>un</strong>amente l’informazione con il fine <strong>di</strong> conservarla nel tempo;<br />
• ritiro, operazione effettuata per contrassegnare informazioni obsolete.<br />
Risulta evidente come tutti questi sistemi sono finalizzati al lavoro collaborativo,<br />
pertanto si in<strong>di</strong>viduano varie categorie <strong>di</strong> utenti che intervengono<br />
nel ciclo <strong>di</strong> vita dell’informazione secondo modalità <strong>di</strong>verse. Le categorie più<br />
importanti sono le seguenti:<br />
5
Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo<br />
• autore, responsabile della creazione dell’informazione;<br />
• redattore, responsabile dell’aspetto formale dell’informazione (come ad<br />
esempio l’applicazione <strong>di</strong> <strong>un</strong>o stile grafico standar<strong>di</strong>zzato) con il fine <strong>di</strong><br />
garantirne l’<strong>un</strong>iformità e la <strong>di</strong>ffusione;<br />
• e<strong>di</strong>tore, responsabile del rilascio e dell’utilizzo dell’informazione;<br />
• amministratore, responsabile della gestione delle versioni dell’informazione<br />
e in generale degli archivi.<br />
1.2 Il lavoro collaborativo<br />
Nella maggior parte delle situazioni in cui esiste collaborazione gli utenti<br />
sono quasi sempre <strong>di</strong>stribuiti nel tempo e nello spazio: molti sistemi multiutente<br />
sono da considerarsi <strong>di</strong>stribuiti. Questa ipotesi mette in luce il fatto<br />
che sia i dati che il controllo sono decentralizzati. Le azioni effettuate sulle<br />
proprietà globali del sistema ed il mantenimento della consistenza dello stato<br />
globale vengono effettuate grazie ad agenti che trattano e manipolano risorse<br />
locali [ESG91].<br />
Per comprendere i tratti caratteristici del lavoro collaborativo è necessario<br />
analizzare la realtà sociale con <strong>un</strong>a prospettiva globale su contesti e con<strong>di</strong>zioni<br />
in cui gli in<strong>di</strong>vidui operano: attività quoti<strong>di</strong>ane, relazioni interpersonali,<br />
conoscenza e risorse (incluse le tecnologie).<br />
La società acquista la maggior parte delle sue caratteristiche dal modo<br />
e dai mezzi con cui le persone si relazionano. Ed esempio la <strong>di</strong>ffusione<br />
dei computer e delle reti telematiche, avvenuta prima in ambienti lavorativi<br />
e successivamente in quelli domestici, ha mutato e sta mutando profondamente<br />
la società. Lo stu<strong>di</strong>o <strong>di</strong> questi sistemi, come pure delle conseguenze<br />
psicologiche, sociali e organizzative, appartiene ad <strong>un</strong> settore <strong>di</strong> ricerca multi<strong>di</strong>sciplinare<br />
denominato Computer-Supported Cooperative Work (CSCW ).<br />
Le tecnologie e gli strumenti che facilitano la collaborazione ad <strong>un</strong> gruppo<br />
<strong>di</strong> in<strong>di</strong>vidui sono in<strong>di</strong>cate con la parola groupware. CSCW può anche essere<br />
considerato come metodologia <strong>di</strong> lavoro, fondata sul principio che le reti<br />
<strong>di</strong> computer sono capaci <strong>di</strong> agevolare, aumentare e ridefinire le interazioni<br />
all’interno <strong>di</strong> <strong>un</strong> gruppo e tra gruppi.<br />
Un aspetto molto importante da mettere in evidenza del lavoro collaborativo<br />
è che i soggetti interessati devono avere <strong>un</strong>a visione globale del progetto<br />
6
Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo<br />
(o parziale, ma che com<strong>un</strong>que comprenda il lavoro svolto da altri). Questo<br />
perché, nella maggior parte dei casi, non è possibile riuscire a <strong>di</strong>videre il progetto<br />
fra i vari soggetti in compartimenti stagni: restano sempre dei p<strong>un</strong>ti <strong>di</strong><br />
contatto o <strong>di</strong> sovrapposizione delle mansioni. Molte realtà sono organizzate<br />
gerarchicamente ed è ovvio che i soggetti che si trovano ai livelli più alti della<br />
gerarchia devono conoscere il lavoro svolto da quelli che si trovano più in<br />
basso. Il grado <strong>di</strong> conoscenza che ogni in<strong>di</strong>viduo ha sul lavoro <strong>di</strong> altri ed in<br />
generale sullo stato globale del progetto è definito awareness.<br />
Tipicamente le tecnologie groupware sono classificate l<strong>un</strong>go due <strong>di</strong>mensioni<br />
principali: lo spazio ed il tempo. Il <strong>modello</strong> Johansen [Kap97], conosciuto<br />
anche col nome <strong>di</strong> <strong>modello</strong> dei 4 quadranti, in<strong>di</strong>vidua 4 categorie e le riporta<br />
in <strong>un</strong>a matrice 2×2 come mostrato in tabella 1.1. Tale <strong>modello</strong> fa riferimento<br />
a due tipologie <strong>di</strong> interazione, asincrona e sincrona, <strong>di</strong> seguito definite:<br />
• interazione asincrona: si intende <strong>un</strong>a situazione <strong>di</strong> relazione fra due<br />
o più soggetti in cui la com<strong>un</strong>icazione avviene in tempi <strong>di</strong>versi; l’interazione<br />
è ovviamente limitata. In questa modalità vengono utilizzate<br />
varie tipologie <strong>di</strong> strumenti: e-mail, forum, au<strong>di</strong>o e/o video messaggi,<br />
frasi scritte su lavagne con<strong>di</strong>vise;<br />
• interazione sincrona: si intende <strong>un</strong>a situazione <strong>di</strong> relazione fra due<br />
o più soggetti in cui la com<strong>un</strong>icazione avviene in tempo reale; l’interazione,<br />
eventualmente me<strong>di</strong>ata da <strong>un</strong>o strumento informatico, è contemporanea.<br />
Alc<strong>un</strong>i strumenti utilizzati per la modalità sincrona, oltre<br />
all’interazione faccia a faccia o telefonica, sono le chat e le au<strong>di</strong>o/video<br />
conferenze.<br />
Spazio<br />
Stesso luogo<br />
Luoghi <strong>di</strong>versi<br />
Tempo Stesso intervallo<br />
temporale<br />
Interazione<br />
faccia a faccia<br />
Interazione sincrona<br />
<strong>di</strong>stribuita<br />
Tabella 1.1: Modello Johansen.<br />
Intervalli temporali<br />
<strong>di</strong>sgi<strong>un</strong>ti<br />
Interazione<br />
asincrona<br />
Interazione asincrona<br />
<strong>di</strong>stribuita<br />
Gli utenti che si trovano a collaborare all’interno dello stesso ambiente<br />
7
Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo<br />
(collaborazione locale) e nello stesso intervallo <strong>di</strong> tempo hanno la possibilità<br />
<strong>di</strong> interagire faccia a faccia. In questo caso il grado <strong>di</strong> awareness è ragionevolmente<br />
alto in quanto sono normali ri<strong>un</strong>ioni perio<strong>di</strong>che, prefissate o<br />
improvvisate, incontri informali (ad esempio nella pausa caffè o durante il<br />
pranzo), eccetera. Non è necessario che gli strumenti informatici <strong>di</strong> supporto<br />
favoriscano lo scambio <strong>di</strong> informazioni. Nel caso in cui l’intervallo <strong>di</strong> tempo<br />
non coincida gli utenti possono ricorrere all’interazione asincrona ad esempio<br />
inserendo degli app<strong>un</strong>ti destinati ai colleghi nell’area <strong>di</strong> lavoro (come <strong>un</strong>a<br />
nota a margine <strong>di</strong> <strong>un</strong> documento, o <strong>un</strong> frase su <strong>un</strong>a lavagna). Può risultare<br />
utile l’utilizzo della posta elettronica e/o <strong>di</strong> <strong>un</strong> forum.<br />
Nel caso in cui i luoghi siano <strong>di</strong>versi <strong>di</strong>ventano necessari strumenti per le<br />
com<strong>un</strong>icazioni remote. Questi devono prevedere la possibilità <strong>di</strong> interagire<br />
in modo sincrono o asincrono. È opport<strong>un</strong>o analizzare le casistiche <strong>di</strong> collaborazione<br />
<strong>di</strong>stribuita che possono presentarsi: lavoro a <strong>di</strong>stanza, lavoro in<br />
appalto, gruppi localizzati e gruppi <strong>di</strong>stribuiti [Ask02].<br />
Lavoro a <strong>di</strong>stanza. Si verifica quando <strong>un</strong> <strong>di</strong>pendente effettua delle brevi<br />
operazioni al <strong>di</strong> fuori del normale ambiente <strong>di</strong> lavoro, spesso come complemento<br />
al lavoro giornaliero. Un esempio può essere <strong>un</strong>a breve operazione<br />
svolta a casa necessaria per il giorno dopo. Se tale operazione richiede <strong>un</strong><br />
l<strong>un</strong>go periodo <strong>di</strong> tempo si crea <strong>un</strong>a situazione simile a quella dei gruppi<br />
<strong>di</strong>stribuiti.<br />
Date le circostanze è auspicabile che l’utente sia in grado <strong>di</strong> mettersi nelle<br />
con<strong>di</strong>zioni <strong>di</strong> operare in breve tempo in quanto ha poche ore a <strong>di</strong>sposizione.<br />
Gli approcci usati, se il materiale sul quale operare è in formato elettronico,<br />
sono:<br />
• lavoro “off-line”: l’utente opera su <strong>un</strong>a copia dei documenti. Questo<br />
presuppone che l’utente abbia a <strong>di</strong>sposizione tutto il pacchetto <strong>di</strong><br />
applicativi necessario per trattare le copie dei file che ha creato;<br />
• lavoro “on-line”: l’utente ha a <strong>di</strong>sposizione la possibilità <strong>di</strong> effettuare<br />
<strong>un</strong> login remoto sulla sua postazione <strong>di</strong> lavoro or<strong>di</strong>naria.<br />
Dal p<strong>un</strong>to <strong>di</strong> vista del sistema groupware la prima possibilità implica<br />
che il lavoro svolto resti temporaneamente fuori dal sistema e che l’utente<br />
non abbia modo <strong>di</strong> interagire con il sistema stesso, pregiu<strong>di</strong>cando l’awareness<br />
8
Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo<br />
complessivo. Il secondo approccio risulta migliore (equivale alla collaborazione<br />
locale), ma presuppone che l’utente abbia a <strong>di</strong>sposizione <strong>un</strong>a connessione<br />
alla rete sufficientemente veloce.<br />
Lavoro in appalto. Si verifica quando viene commissionata <strong>un</strong>a parte <strong>di</strong><br />
lavoro ad <strong>un</strong>a entità esterna. È basato su <strong>un</strong>a collaborazione stretta fra committente<br />
e commissionario. Il committente è il responsabile del prodotto finale<br />
ed eventuali errori/cambiamenti devono essere convertiti in <strong>un</strong>a richiesta<br />
<strong>di</strong> mo<strong>di</strong>fica verso il commissionario.<br />
Dal p<strong>un</strong>to <strong>di</strong> vista del sistema groupware il committente deve essere in<br />
grado <strong>di</strong> integrare le nuove versioni nel prodotto, operazione che può risultare<br />
complessa in quanto committente e commissionario potrebbero non avere a<br />
<strong>di</strong>sposizione gli stessi strumenti informatici.<br />
Lavoro in gruppi localizzati. Quando il lavoro è svolto all’interno <strong>di</strong><br />
<strong>un</strong>a compagnia che ha varie se<strong>di</strong> ed in ogni sede operano <strong>un</strong>o o più gruppi<br />
<strong>di</strong>stinti (ogn<strong>un</strong>o dei quali svolge <strong>un</strong>a parte del lavoro complessivo), si parla<br />
<strong>di</strong> gruppi localizzati. Le interazioni che si hanno all’interno <strong>di</strong> <strong>un</strong> gruppo o<br />
tra gruppi che operano nella stessa sede rientrano nella collaborazione locale.<br />
La collaborazione fra gruppi che operano in luoghi <strong>di</strong>versi è complessa ed è<br />
facilitata se il lavoro viene correttamente pianificato e sud<strong>di</strong>viso in varie fasi.<br />
Dal p<strong>un</strong>to <strong>di</strong> vista del sistema groupware è importante mettere a <strong>di</strong>sposizione<br />
tecnologie che permettano ai gruppi <strong>di</strong> interagire nel miglior modo<br />
possibile compatibilmente con le esigenze del momento in modo tale che sia<br />
possibile garantire <strong>un</strong> buon livello <strong>di</strong> awareness.<br />
Lavoro in gruppi <strong>di</strong>stribuiti. Quando si creano gruppi i cui membri<br />
appartengono a se<strong>di</strong> <strong>di</strong>verse della stessa compagnia o a compagnie <strong>di</strong>verse e<br />
sono quin<strong>di</strong> geograficamente <strong>di</strong>spersi, si parla <strong>di</strong> gruppi <strong>di</strong>stribuiti. Questa<br />
situazione normalmente non viene creata in modo intenzionale, ma si verifica<br />
nel momento in cui alc<strong>un</strong>i <strong>di</strong>pendenti vengono destinati a lavorare su più<br />
progetti.<br />
Dal p<strong>un</strong>to <strong>di</strong> vista del sistema groupware è importante che i membri del<br />
gruppo abbiano la possibilità <strong>di</strong> com<strong>un</strong>icare in modo da poter ricevere informazioni<br />
che riguardano il lavoro svolto dagli altri. È importante che siano<br />
presenti meccanismi che permettano <strong>un</strong>a agevole ripartizione dei compiti e<br />
che il sistema permetta l’accesso concorrente, sia per la lettura che per la<br />
9
Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo<br />
mo<strong>di</strong>fica, alle risorse <strong>di</strong>sponibili. A riguardo è opport<strong>un</strong>o che il sistema operi<br />
senza permettere il blocco esclusivo delle risorse: è <strong>di</strong>fficile gestire situazioni<br />
in cui alc<strong>un</strong>i utenti siano costretti ad attendere il rilascio <strong>di</strong> risorse in quel<br />
momento necessarie per loro, ma non utilizzabili poiché bloccate da altri.<br />
Molte sono le caratteristiche dei groupware [Bul05] che spingono le organizzazioni<br />
alla loro adozione; qui <strong>di</strong> seguito vengono riportate le più importanti<br />
ed evidenti:<br />
• facilitazione del <strong>di</strong>alogo che viene reso più veloce, più chiaro e più<br />
convincente;<br />
• presenza <strong>di</strong> com<strong>un</strong>icazione dove altrimenti non sarebbe possibile;<br />
• possibilità <strong>di</strong> utilizzo della telecom<strong>un</strong>icazione;<br />
• riduzione dei costi degli spostamenti;<br />
• promozione <strong>di</strong> esperienze com<strong>un</strong>i con prospettive multiple;<br />
• favoreggiamento della formazione <strong>di</strong> gruppi con interessi com<strong>un</strong>i là dove<br />
non sarebbe possibile con meto<strong>di</strong> tra<strong>di</strong>zionali;<br />
• riduzione <strong>di</strong> tempi e costi nelle coor<strong>di</strong>nazione del lavoro;<br />
• facilitazione nella risoluzione dei problemi;<br />
• utilizzo <strong>di</strong> nuove modalità per com<strong>un</strong>icare (ad esempio interazioni strutturate<br />
ed anonime).<br />
1.2.1 Progettazione <strong>di</strong> groupware<br />
Per progettare <strong>un</strong> sistema groupware è conveniente analizzare e comprendere<br />
i problemi con la prospettiva dell’utente, delle sue mansioni e dei suoi<br />
obiettivi. Per applicazioni groupware <strong>di</strong> larga scala l’analisi dell’utenza conduce<br />
imme<strong>di</strong>atamente all’analisi dei meccanismi com<strong>un</strong>icativi. Il problema<br />
è significativamente più <strong>di</strong>fficoltoso rispetto al caso <strong>di</strong> sistemi basati su <strong>un</strong><br />
singolo utente per i seguenti principali motivi:<br />
• è più <strong>di</strong>fficile organizzare e programmare i gruppi piuttosto che <strong>un</strong><br />
singolo in<strong>di</strong>viduo;<br />
10
Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo<br />
• non si può scegliere in anticipo il para<strong>di</strong>gma <strong>di</strong> interazione;<br />
• i gruppi cambiano continuamente il loro stile <strong>di</strong> interazione e la durata<br />
temporale della loro partecipazione;<br />
• i nuovi gruppi evolvono velocemente durante il processo <strong>di</strong> formazione.<br />
In molti casi è meglio iniziare lo stu<strong>di</strong>o partendo da <strong>un</strong> campo ristretto,<br />
cercando <strong>di</strong> comprendere le particolari esigenze <strong>di</strong> <strong>un</strong> tipico gruppo (o piccola<br />
organizzazione) che userà il sistema. Dovrà essere realizzata <strong>un</strong>a documentazione<br />
attraverso interviste, sopralluoghi, analisi degli strumenti usati, dei<br />
processi e procedure <strong>di</strong> lavoro, per determinare la struttura organizzativa e i<br />
ruoli degli utenti.<br />
1.2.2 I gruppi e la collaborazione<br />
L’analisi inter<strong>di</strong>sciplinare condotta sul lavoro <strong>di</strong> gruppo conduce ad <strong>un</strong><br />
<strong>modello</strong> stratificato, come <strong>di</strong>mostrato da vari stu<strong>di</strong> scientifici [MO94]. In<br />
figura 1.1 è evidenziata graficamente la definizione della collaborazione come<br />
attività fondata sul backgro<strong>un</strong>d sociale, supportato da infrastrutture<br />
economiche.<br />
Le tre <strong>di</strong>mensioni, collaborativa, sociale ed economica, sono poste rispettivamente<br />
su tre livelli, in cui la collaborazione occupa la posizione più alta,<br />
<strong>di</strong>rettamente sopra il substrato sociale, il quale a sua volta giace su <strong>un</strong>o strato<br />
economico.<br />
La collaborazione è caratterizzata da <strong>un</strong>’ evoluzione ciclica nel tempo.<br />
Inizia con incontri ufficiosi e attività in<strong>di</strong>viduali per poi allargarsi e formalizzarsi<br />
in incontri <strong>di</strong> gruppo sempre più interattivi (eventualmente ripetuti)<br />
e si conclude con la produzione dei risultati (prodotto finito, intellettuale o<br />
materiale). La con<strong>di</strong>visione dell’informazione avviene in forma orale e scritta,<br />
supportata da vari mezzi com<strong>un</strong>icativi tramite i quali avviene lo scambio <strong>di</strong><br />
informazione. La collaborazione può avvenire con proce<strong>di</strong>menti sequenziali,<br />
paralleli o <strong>di</strong> reciprocità [CM03].<br />
La <strong>di</strong>mensione sociale corrisponde all’aspetto comportamentale del lavoro<br />
collaborativo che inizia a livello in<strong>di</strong>viduale per poi crescere gradualmente<br />
fino a coinvolgere intere organizzazioni. Le interazioni avvengono su scala<br />
<strong>di</strong>versa, monotona crescente rispetto al numero <strong>di</strong> in<strong>di</strong>vidui coinvolti. Le<br />
organizzazioni hanno <strong>un</strong>a struttura piramidale e sono la massima espressione<br />
<strong>di</strong> <strong>un</strong> gruppo (massima entità che li contiene).<br />
11
Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo<br />
Incontro <strong>di</strong><br />
corridoio<br />
Lavoro<br />
in<strong>di</strong>viduale<br />
In<strong>di</strong>viduo Nel gruppo Il gruppo<br />
come <strong>un</strong><br />
tutt'<strong>un</strong>o<br />
Risorse<br />
umane<br />
Attività <strong>di</strong><br />
prassi<br />
Ri<strong>un</strong>ione Interazione<br />
in corso<br />
Tempo<br />
Collaborazione Nelle Organizzazioni<br />
Ri<strong>un</strong>ione<br />
successiva<br />
Tra gruppi Nella stessa<br />
organizzazione<br />
Substrato Sociale<br />
Proce<strong>di</strong>menti Ambiente fisico Risorse<br />
temporali<br />
Substrato Economico<br />
Figura 1.1: Gli strati <strong>di</strong> supporto alla collaborazione.<br />
Con<strong>di</strong>visione<br />
dei documenti<br />
Fra<br />
organizzazioni<br />
<strong>di</strong>verse<br />
Information<br />
Comm<strong>un</strong>ication<br />
Technologies<br />
La <strong>di</strong>mensione economica corrisponde alla parte organizzativa del contesto<br />
ed è costituita dalle risorse <strong>di</strong>sponibili (forza lavoro, infrastrutture, tecnologie<br />
e informazioni) e dalle restrizioni esistenti all’interno dell’organizzazione<br />
(mansioni, compiti, professionalità, risorse temporali).<br />
La principale implicazione del lavoro <strong>di</strong> gruppo è che il gruppo esegue dei<br />
compiti stabiliti dal contesto, dal tempo, dalle caratteristiche comportamentali,<br />
dall’uso dei meto<strong>di</strong> <strong>di</strong> interazione e dalle abitu<strong>di</strong>ni lavorative (prassi).<br />
Il gruppo ha <strong>un</strong>a propria evoluzione, conseguentemente molti fattori relativi<br />
alle sue necessità sono impreve<strong>di</strong>bili.<br />
12
Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo<br />
1.2.3 Requisiti generali per sistemi groupware<br />
In tabella 1.2 sono presentati sette requisiti generali <strong>di</strong> cui <strong>un</strong> sistema<br />
groupware può essere dotato; tale elenco può essere anche visto come criterio<br />
<strong>di</strong> classificazione <strong>di</strong> specifici requisiti, che devono essere dedotti dalle esigenze<br />
dell’utenza [MO94].<br />
R1<br />
R2<br />
R3<br />
R4<br />
R5<br />
R6<br />
R7<br />
Consentire molteplici processi<br />
Consentire molteplici metodologie <strong>di</strong> lavoro<br />
Consentire lo sviluppo del gruppo<br />
Permettere meto<strong>di</strong> <strong>di</strong> interazione interscambiabili<br />
Sostenere molteplici caratteristiche comportamentali<br />
Regolare ed adattare il contesto del gruppo<br />
Favorire permeabilità alle barriere del gruppo<br />
Tabella 1.2: Requisiti per sistemi groupware.<br />
R1 - Consentire molteplici processi. I gruppi vengono creati con la<br />
finalità <strong>di</strong> svolgere dei compiti. Il sistema groupware deve permettere molteplici<br />
processi dato che i gruppi possono ridefinire i propri obiettivi in risposta<br />
a mutamenti socio-economici. Eventuali sotto requisiti in<strong>di</strong>rizzano f<strong>un</strong>zionalità<br />
<strong>di</strong> produzione. Una strategia implementativa consiste nella realizzazione<br />
modulare <strong>di</strong> ogni processo in modo da tenere separati i vari compiti.<br />
R2 - Consentire molteplici metodologie <strong>di</strong> lavoro. Un particolare<br />
lavoro può essere scomposto in lavori minori o far parte <strong>di</strong> <strong>un</strong> processo più<br />
ampio. Ciasc<strong>un</strong>o <strong>di</strong> essi sarà completato usando opport<strong>un</strong>e ed appropriate<br />
tecniche che il sistema groupware deve essere in grado <strong>di</strong> fornire.<br />
Alc<strong>un</strong>i membri del gruppo potrebbero preferire <strong>un</strong> lavoro più solitario o<br />
isolato, altri invece ricercare l’influenza del gruppo, preferendo la vigilanza<br />
della collettività. Inoltre i mezzi <strong>di</strong> com<strong>un</strong>icazione, le tecniche e gli strumenti<br />
offrono <strong>un</strong> numeroso insieme <strong>di</strong> varianti. L’evoluzione <strong>di</strong> queste infrastrutture<br />
non può essere predetto, quin<strong>di</strong> è necessario che il sistema sia aperto alle<br />
innovazioni. Anche in questo caso <strong>un</strong> approccio modulare può essere efficace<br />
nella realizzazione e nell’aggiornamento del sistema.<br />
13
Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo<br />
R3 - Consentire lo sviluppo del gruppo. I gruppi sono influenzati dalla<br />
<strong>di</strong>namica dell’ambiente e delle interazioni. Ad esempio a livello sociale<br />
la composizione del gruppo cambia all’entrata e all’uscita <strong>di</strong> <strong>un</strong> membro. I<br />
confini cambiano al costituirsi o al <strong>di</strong>sgregarsi <strong>di</strong> relazioni all’interno dell’organizzazione,<br />
inoltre la cultura organizzativa cambia in risposta a cambiamenti<br />
ambientali. Un <strong>modello</strong> per lo sviluppo <strong>di</strong> gruppi è basato sul concetto<br />
<strong>di</strong> equilibrio interrotto il quale afferma che “il lavoro <strong>di</strong> gruppo progre<strong>di</strong>sce<br />
con l<strong>un</strong>ghi perio<strong>di</strong> <strong>di</strong> inerzia, interrotti da rivoluzionari e limitati perio<strong>di</strong> <strong>di</strong><br />
mutamenti quantici” [MO94].<br />
Esistono almeno due aree concrete nelle quali i groupware sono <strong>di</strong> aiuto<br />
nello sviluppo e nella creazione dei gruppi: influenzano il comportamento<br />
dei processi che governano la crescita del gruppo e ne gestiscono gli aspetti<br />
strutturali.<br />
Influenzare il comportamento implica l’uso <strong>di</strong> tecniche per incrementare<br />
il consenso, definire ruoli, ri<strong>di</strong>stribuire il potere e incrementare l’interazione.<br />
Questi obiettivi possono essere raggi<strong>un</strong>ti attraverso <strong>un</strong>a sincronizzazione<br />
con<strong>di</strong>visa delle vedute, oppure consentendo anonimato, imponendo scadenze<br />
temporali o stabilendo livelli <strong>di</strong> accesso all’informazione.<br />
D’altronde è importante anche la gestione strutturale: il gruppo deve essere<br />
amministrato e deve conservare memoria delle passate attività in modo<br />
da poter programmare le future evoluzioni e pianificare la crescita. La consapevolezza<br />
(awareness) del lavoro svolto all’interno del gruppo consente <strong>un</strong>a<br />
migliore integrazione tra membri e favorisce maggiori risultati in<strong>di</strong>viduali.<br />
R4 - Permettere meto<strong>di</strong> <strong>di</strong> interazione interscambiabili. La com<strong>un</strong>icazione<br />
all’interno delle organizzazioni avviene attraverso varie modalità<br />
(faccia a faccia, ri<strong>un</strong>ioni, scrittura etc.). Il sistema groupware deve essere in<br />
grado <strong>di</strong> coprire la maggior parte dei quattro quadranti del <strong>modello</strong> Johansen<br />
(tabella 1.1 a pagina 7) e <strong>di</strong> consentire in modo integrato il passaggio delle<br />
interazioni da <strong>un</strong> quadrante all’altro al mutare delle con<strong>di</strong>zioni ambientali.<br />
R5 - Sostenere molteplici caratteristiche comportamentali. I gruppi<br />
assumono vari comportamenti nel prendere parte all’interazione e nel completare<br />
e svolgere i propri compiti. Ciò è dovuto al grado <strong>di</strong> coesione, agli<br />
impegni da sostenere, allo stress, ai ruoli assegnati all’interno dell’organizzazione.<br />
Queste caratteristiche governano le modalità con cui il gruppo per-<br />
14
Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo<br />
cepisce e usa il sistema groupware, quin<strong>di</strong> il sistema deve farsi carico anche<br />
della <strong>di</strong>mensione sociale del lavoro collaborativo.<br />
È <strong>di</strong>fficile, potrebbe essere impossibile, valutare l’importanza dei vari comportamenti;<br />
si possono com<strong>un</strong>que identificare tre approcci complementari che<br />
ne facilitano la classificazione:<br />
• comportamenti chiave: identificano solamente i principali comportamenti<br />
in <strong>un</strong> particolare dominio. Re<strong>di</strong>gere la tassonomia dei compiti<br />
può essere il p<strong>un</strong>to <strong>di</strong> partenza;<br />
• elementi catalizzanti: identificano le variabili del sistema che regolano i<br />
comportamenti. Ad esempio il tempo <strong>di</strong>sponibile ha <strong>un</strong> grosso impatto<br />
sulla concentrazione e la coesione tra in<strong>di</strong>vidui. Intervenendo su queste<br />
variabili si controlla il comportamento del gruppo;<br />
• prospettive dell’utente: identificano gli aspetti che potrebbero consentire<br />
all’utente l’automazione del lavoro, la mo<strong>di</strong>fica flessibile e la<br />
personalizzazione degli strumenti, che altrimenti lo potrebbero rendere<br />
frustrato.<br />
R6 - Favorire permeabilità alle barriere del gruppo. I limiti fisici<br />
spazio-temporali possono creare <strong>di</strong>visioni che a loro volta determinano <strong>di</strong>fferenze<br />
penalizzanti tra in<strong>di</strong>vidui. I confini del gruppo devono essere permeabili<br />
nel senso che devono consentire meccanismi <strong>di</strong> ingresso ed uscita delle informazioni,<br />
abbattendo i limiti fisici. Questa necessità è determinata da fattori<br />
economici e sociali come ad esempio la presenza <strong>di</strong> <strong>un</strong>a autorità esterna e la<br />
<strong>di</strong>pendenza da altri gruppi.<br />
Dovranno essere en<strong>un</strong>ciate appropriate specifiche per delineare il modo<br />
in cui saranno stabiliti e gestiti i confini del gruppo. È necessario risolvere<br />
quanto prima il problema dell’interoperabilità, poiché, prima o poi, il gruppo<br />
si dovrà scontrare col mondo esterno.<br />
R7 - Regolare ed adattare il contesto del gruppo. È conveniente<br />
vedere il contesto come <strong>un</strong>’opport<strong>un</strong>ità piuttosto che come <strong>un</strong> ostacolo alla<br />
adattabilità del gruppo. Ogni gruppo ha <strong>un</strong>a dettagliata conoscenza <strong>di</strong> sé<br />
e probabilmente ha idee chiare su ciò <strong>di</strong> cui ha bisogno. Questa conoscenza<br />
può essere usata per personalizzare il groupware.<br />
15
Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo<br />
La personalizzazione è soggettiva, ma le scelte in<strong>di</strong>viduali si riflettono su<br />
tutti i membri. Alc<strong>un</strong>i settaggi, come la selezione del metodo <strong>di</strong> interazione,<br />
dovrebbero essere al <strong>di</strong> fuori della portata del generico utente, mentre altri,<br />
come ad esempio le modalità <strong>di</strong> presentazione dell’informazione, dovrebbero<br />
essere consentiti a tutti. Interventi determinanti sul groupware possono essere<br />
affidati ad <strong>un</strong> amministratore il quale si prende carico delle esigenze <strong>di</strong> base<br />
del proprio gruppo.<br />
1.2.4 Modelli <strong>di</strong> lavoro<br />
Quando più persone operano contemporaneamente sullo stesso sistema<br />
devono sincronizzare il loro lavoro. Normalmente si ha <strong>un</strong>a sud<strong>di</strong>visione dei<br />
compiti fra i vari soggetti, questa operazione può essere ricorsiva per organizzazioni<br />
strutturate in modo gerarchico (per esempio: l’organizzazione <strong>di</strong>vide<br />
il lavoro fra le varie se<strong>di</strong>, ogni sede <strong>di</strong>vide la parte <strong>di</strong> propria competenza fra<br />
i gruppi ivi locati infine ogni gruppo sud<strong>di</strong>vide le mansioni fra i vari membri<br />
<strong>di</strong> appartenenza). Durante il processo <strong>di</strong> sviluppo del sistema è necessario ricombinare<br />
le varie parti almeno <strong>un</strong>a volta, per creare il prodotto finito; molto<br />
probabilmente però, questa operazione sarà effettuata più volte (nel complesso<br />
o per assemblare sottosistemi più gran<strong>di</strong> delle singole parti) per ottenere<br />
le pietre miliari ed i prodotti semi-lavorati previsti dai convenzionali processi<br />
<strong>di</strong> sviluppo. Esistono due approcci <strong>di</strong>versi per effettuare la sud<strong>di</strong>visione:<br />
• architetturale: si effettua <strong>un</strong>a <strong>di</strong>visione fisica del sistema da sviluppare<br />
in sottosistemi o moduli separati e si assegna <strong>un</strong> responsabile ad ogn<strong>un</strong>o<br />
<strong>di</strong> essi. Soltanto il responsabile ha la possibilità <strong>di</strong> operare sulla risorsa;<br />
• anatomico: si <strong>di</strong>vidono le mansioni sulla base dei risultati (o f<strong>un</strong>zionalità)<br />
che si intendono ottenere, lasciando la possibilità a tutti i soggetti<br />
<strong>di</strong> operare su ogni parte del sistema.<br />
Durante le prime fasi <strong>di</strong> sviluppo l’approccio architetturale è quello maggiormente<br />
usato. Si <strong>di</strong>mostra però eccessivamente statico nelle fasi finali, fasi<br />
nelle quali si <strong>un</strong>iscono sottosistemi <strong>di</strong>stinti in <strong>un</strong> prodotto <strong>un</strong>ico, quello finale.<br />
Per risolvere eventuali problemi che sorgono in questa fase è probabile<br />
che sia necessario intervenire su più sottosistemi, rendendo l’approccio anatomico<br />
più conveniente. Il rovescio della medaglia è che sono richiesti sforzi<br />
supplementari per garantire la consistenza del progetto. È necessario che le<br />
16
Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo<br />
<strong>un</strong>ità <strong>di</strong> lavoro siano correttamente or<strong>di</strong>nate ed analizzate affinché possano<br />
essere effettuate in concorrenza.<br />
Un’altra terminologia utilizzata per i modelli <strong>di</strong> lavoro prevede la definizione<br />
<strong>di</strong> tre tipi <strong>di</strong> coor<strong>di</strong>namento:<br />
• turn-taking: <strong>un</strong> singolo in<strong>di</strong>viduo alla volta è abilitato ad apportare<br />
cambiamenti al progetto, gli altri, <strong>di</strong> fatto, non possono operare;<br />
• split-combine: il progetto è partizionato ed ogni in<strong>di</strong>viduo è abilitato ad<br />
operare sulla parte <strong>di</strong> sua competenza (equivalente ad architetturale),<br />
tale approccio potrebbe risultare eccessivamente statico;<br />
• copy-merge: ogni soggetto ha a <strong>di</strong>sposizione <strong>un</strong>a copia <strong>di</strong> tutto il progetto<br />
sulla quale operare e, <strong>di</strong> tanto in tanto, le mo<strong>di</strong>fiche vengono fuse<br />
insieme (equivalente ad anatomico). Per la gestione delle fusione delle<br />
mo<strong>di</strong>fiche occorrono meccanismi complessi, che, in base al contesto,<br />
potrebbero non riuscire nei loro intenti lasciando il sistema in <strong>un</strong>o stato<br />
inconsistente (nel tal caso risulta necessario intervenire manualmente).<br />
Nel caso in cui la compagnia sia organizzata in modo gerarchico è usuale<br />
ricorrere a combinazione <strong>di</strong> modelli. Ad esempio è com<strong>un</strong>e <strong>un</strong>o scenario in cui<br />
agli alti livelli si ricorre al tipo split-combine, in quanto si hanno vari gruppi<br />
responsabili <strong>di</strong> sottosistemi <strong>di</strong>stinti, mentre all’interno dei singoli gruppi si<br />
usa il tipo copy-merge.<br />
In generale la scelta della strategia deve tenere presente due <strong>di</strong>rettive,<br />
in sostanza contrad<strong>di</strong>ttorie. Da <strong>un</strong>a parte esiste la necessità <strong>di</strong> integrare il<br />
più velocemente possibile le mo<strong>di</strong>fiche e le correzioni, dall’altra è preferibile<br />
fornire agli utenti <strong>un</strong> ambiente <strong>di</strong> lavoro il più stabile possibile, affinché ogni<br />
utente non venga esageratamente <strong>di</strong>sturbato dalle attività degli altri. Le<br />
strategie del primo tipo sono dette ottimistiche e le seconde conservative.<br />
Le strategie <strong>di</strong> aggiornamento riguardano le modalità con cui le nuove<br />
informazioni sono messe a <strong>di</strong>sposizione del gruppo <strong>di</strong> lavoro e quando devono<br />
essere recepite ed usate dagli altri. Una strategia <strong>di</strong> aggiornamento ottimistica<br />
consiste nel pubblicare imme<strong>di</strong>atamente tutte le mo<strong>di</strong>fiche, per consentirne<br />
<strong>un</strong> uso imme<strong>di</strong>ato. Questo significa che il problema dell’integrazione dovrà<br />
essere risolto in tempi brevi. Nella strategia <strong>di</strong> aggiornamento conservativo<br />
le mo<strong>di</strong>fiche non hanno effetti imme<strong>di</strong>ati; in altre parole vuol <strong>di</strong>re ritardare<br />
la pubblicazione.<br />
17
Cooperazione e collaborazione nelle organizzazioni Il concetto <strong>di</strong> configurazione<br />
La scelta della strategia si riflette nell’approccio con cui viene gestito il<br />
lavoro concorrente. Per principio <strong>un</strong>a strategia conservativa non consente<br />
mo<strong>di</strong>fiche concorrenti allo stesso documento, mentre <strong>un</strong>a strategia ottimistica<br />
ammette <strong>un</strong>a pianificata integrazione dei dati, con tempi più o meno<br />
rigi<strong>di</strong>. Per impe<strong>di</strong>re mo<strong>di</strong>fiche concorrenti il sistema blocca la risorsa in esame<br />
permettendo al solo utente che l’ha bloccata <strong>di</strong> effettuare mo<strong>di</strong>fiche. In<br />
questo caso si parla <strong>di</strong> blocco (o lock) conservativo o pessimistico. Nei sistemi<br />
in cui viene attuata la strategia ottimistica, per analogia, si parla <strong>di</strong> blocco<br />
(o lock) ottimistico. In questo caso il sistema non attua <strong>un</strong> blocco vero e<br />
proprio della risorsa, ma tiene traccia degli autori che la stanno mo<strong>di</strong>ficando<br />
in concorrenza in modo da permettere <strong>un</strong>’integrazione controllata delle mo<strong>di</strong>fiche.<br />
In questo caso gli utenti devono interpretare il “blocco” come stato<br />
in cui la risorsa è in fase <strong>di</strong> aggiornamento da parte <strong>di</strong> altri; la percezione che<br />
essi hanno del blocco e cosa questo comporti all’atto pratico, varia molto al<br />
variare del contesto.<br />
1.3 Il concetto <strong>di</strong> configurazione<br />
Nel tempo non variano solamente i contenuti <strong>di</strong> <strong>un</strong> documento, ma anche<br />
la relativa struttura. Se la medesima struttura è com<strong>un</strong>e a molti documenti,<br />
definisce <strong>un</strong>a tipologia (per i certificati, per documenti <strong>di</strong> identità, per i referti,<br />
per i verbali, etc.). La mo<strong>di</strong>fica <strong>di</strong> <strong>un</strong>a tipologia comporta la mo<strong>di</strong>fica <strong>di</strong><br />
ciasc<strong>un</strong>o dei documenti associati.<br />
Per esempio, in riferimento al linguaggio com<strong>un</strong>e, la “patente” <strong>di</strong> “Mario<br />
Rossi” è il documento rappresentato dall’insieme <strong>di</strong> informazioni riportate in<br />
tabella 1.3.<br />
Esistono informazioni necessarie per descrivere il documento in quanto<br />
tale e altre che sono i dati che questo contiene. Le informazioni appartenenti<br />
alla prima categoria sono dette metadati associati al documento e, in riferimento<br />
all’esempio riportato in tabella 1.3, sono le informazioni presenti nella<br />
colonna <strong>di</strong> sinistra.<br />
I metadati consentono la gestione dei documenti e, a loro volta, sono rappresentati<br />
tramite <strong>un</strong>o o più documenti oggetto <strong>di</strong> authoring. Una configurazione<br />
(configuration) è l’insieme dei metadati che definiscono la struttura,<br />
il workflow, il comportamento e lo stato interno del documento. In alc<strong>un</strong>i<br />
contesti questo concetto viene esteso fino a comprendere il documento stesso<br />
e, <strong>di</strong> conseguenza, reso più generico. Un’ulteriore generalizzazione è quella <strong>di</strong><br />
18
Cooperazione e collaborazione nelle organizzazioni Il concetto <strong>di</strong> configurazione<br />
Tipo <strong>di</strong> dato<br />
Nome<br />
Cognome<br />
Data e<br />
Luogo <strong>di</strong> Nascita<br />
Valore<br />
Mario<br />
Rossi<br />
20/10/1971<br />
Firenze (FI)<br />
Etc. Etc.<br />
Tabella 1.3: Struttura e dati <strong>di</strong> <strong>un</strong> documento.<br />
considerare prodotti e sistemi oltre a documenti e definire configurazione <strong>un</strong>a<br />
“istantanea” del sistema (documento o prodotto) al tempo corrente t0. Con<br />
“istantanea” si intendono tutte le informazioni necessarie per poter ricreare<br />
il sistema (documento o prodotto) esattamente come si presenta al tempo<br />
t0, nello stesso o in <strong>un</strong> altro luogo, in <strong>un</strong> momento t1 ≥ t0. Infine è utile<br />
menzionare la seguente definizione ricorsiva: <strong>un</strong>a configurazione è <strong>un</strong> insieme<br />
<strong>di</strong> entità atomiche e <strong>di</strong> altre configurazioni. È possibile associare varie interpretazioni<br />
a questa definizione, alc<strong>un</strong>e delle quali permettono <strong>di</strong> mettere in<br />
relazione i contenuti (entità atomiche) con gli aspetti strutturali. Supponendo<br />
che l’insieme sia or<strong>di</strong>nato e che ogni entità atomica abbia come figli tutte<br />
le entità atomiche contenute nella configurazione che precede, applicando la<br />
definizione ricorsiva si ottiene <strong>un</strong> albero. In figura 1.2 è presente <strong>un</strong> esempio<br />
nel quale la configurazione iniziale è costituita da <strong>un</strong>a entità atomica seguita<br />
da <strong>un</strong>a configurazione. Espandendo la configurazione C1 (Passo 1), la ra<strong>di</strong>ce<br />
acquisisce due figli. Al primo <strong>di</strong> essi è associata <strong>un</strong>a nuova configurazione<br />
(C2) la quale, a sua volta, contiene due entità atomiche e <strong>un</strong>a terza configurazione<br />
(C3). Ripetendo l’algoritmo ricorsivo (Passi 2 e 3) si ottiene l’albero<br />
riportato nell’ultimo riquadro a destra della figura.<br />
Non esiste <strong>un</strong>a definizione <strong>un</strong>ivoca <strong>di</strong> configurazione e pertanto, parlando<br />
<strong>di</strong> gestione <strong>di</strong> configurazioni, è possibile intendere cose <strong>di</strong>verse. In letteratura,<br />
a riguardo, è possibile trovare molte definizioni (ve<strong>di</strong> [App05]) e <strong>un</strong>a<br />
fra quelle coerenti con la definizione più generale data <strong>di</strong> configurazione è la<br />
seguente: con CM (Configuration Management) si intendono tutti quei pro-<br />
19
Cooperazione e collaborazione nelle organizzazioni Il concetto <strong>di</strong> configurazione<br />
Configurazione<br />
iniziale<br />
Entità<br />
atomiche<br />
Passo 1 Passo 2 Passo 3<br />
C1<br />
Configurazioni<br />
Figura 1.2: Albero ottenibile dalla definizione ricorsiva <strong>di</strong> configurazione.<br />
cessi atti a gestire lo sviluppo e le mo<strong>di</strong>fiche <strong>di</strong> sistemi, prodotti o documenti<br />
durante il loro intero ciclo <strong>di</strong> vita. I sistemi finalizzati al CM (chiamati anche<br />
Configuration Management Systems, CMS) permettono quin<strong>di</strong> <strong>di</strong> controllare<br />
l’evoluzione temporale delle configurazioni per garantire la loro integrità nel<br />
tempo e la tracciabilità delle mo<strong>di</strong>fiche.<br />
In riferimento alla descrizione dei Content Management Systems riportata<br />
nel paragrafo 1.1 è possibile osservare che esiste <strong>un</strong>a similitu<strong>di</strong>ne nella<br />
definizione <strong>di</strong> questi ultimi e dei Configuration Management Systems. La <strong>di</strong>fferenza<br />
sostanziale consiste nel fatto che i primi sono maggiormente orientati<br />
alla gestione del workflow dell’informazione mettendo a <strong>di</strong>sposizione molte<br />
f<strong>un</strong>zionalità avanzate per questo scopo, i secon<strong>di</strong> sono maggiormente orientati<br />
al tracciamento dell’evoluzione temporale della configurazione (dell’informazione)<br />
mettendo a <strong>di</strong>sposizione strumenti sofisticati e specifici per il<br />
controllo e la gestione delle versioni.<br />
Data la sua <strong>di</strong>ffusione è utile ricordare che con Software Configuration<br />
Management (SCM ) si intendono tutti quei processi atti a gestire lo sviluppo<br />
e le mo<strong>di</strong>fiche <strong>di</strong> co<strong>di</strong>ce sorgente durante il suo intero ciclo <strong>di</strong> vita. È utile<br />
sottolineare che, anche in questo caso, tale definizione non è la sola esistente.<br />
Per quanto riguarda i requisiti che devono essere sod<strong>di</strong>sfatti è possibile<br />
in<strong>di</strong>viduare due macrocategorie, <strong>un</strong>a che comprende gli aspetti relativi alla<br />
gestione, l’altra allo sviluppo delle configurazioni.<br />
C2<br />
C3<br />
20
Cooperazione e collaborazione nelle organizzazioni Il concetto <strong>di</strong> configurazione<br />
Prospettiva della gestione. Assumendo il p<strong>un</strong>to <strong>di</strong> vista della gestione<br />
delle configurazioni si possono identificare quattro aree <strong>di</strong> interesse: identificazione,<br />
controllo, acco<strong>un</strong>ting e verifica.<br />
• Identificazione. Comprende le attività che determinano <strong>un</strong>a configurazione,<br />
la relativa selezione, le caratteristiche f<strong>un</strong>zionali, l’assegnazione<br />
degli identificativi e le relazioni con altri documenti.<br />
• Controllo. Comprende le attività <strong>di</strong> controllo dell’aggiornamento delle<br />
configurazioni. Il controllo include anche la validazione, la coor<strong>di</strong>nazione<br />
degli utenti, l’approvazione e il rilascio.<br />
• Acco<strong>un</strong>ting. Consiste nel memorizzare e riferire le configurazioni, lo<br />
storico e le mo<strong>di</strong>fiche approvate. Lo storico deve tracciare tutta la storia<br />
<strong>di</strong> <strong>un</strong> documento (prodotto o sistema), comprensiva delle eventuali<br />
deviazioni subite nel tempo.<br />
• Verifica. Consiste nel determinare quando <strong>un</strong>a configurazione è ben<br />
formata e valida rispetto ad <strong>un</strong> <strong>modello</strong> <strong>di</strong> riferimento.<br />
Prospettiva dello sviluppo. Assumendo il p<strong>un</strong>to <strong>di</strong> vista dello sviluppo<br />
<strong>di</strong>stribuito si possono identificare sette aree <strong>di</strong> interesse: controllo delle<br />
versioni, selezione della configurazione, controllo della concorrenza, tracciabilità<br />
dello sviluppo, rilascio dei documenti (prodotti o sistemi, <strong>di</strong> seguito è<br />
sottinteso), gestione dell’ambiente <strong>di</strong> lavoro e gestione delle mo<strong>di</strong>fiche.<br />
• Controllo delle versioni. Deve essere possibile memorizzare <strong>di</strong>fferenti<br />
versioni e varianti <strong>di</strong> <strong>un</strong> documento e conseguentemente essere capaci<br />
<strong>di</strong> ottenerle e confrontarle tra loro.<br />
• Selezione della configurazione. Devono essere create e/o selezionate<br />
le configurazioni appropriate alle versioni. È <strong>un</strong>a attività che<br />
definisce e assegna i tipi <strong>di</strong> documento.<br />
• Controllo della concorrenza. L’accesso simultaneo al documento<br />
da parte <strong>di</strong> più utenti deve essere o prevenuto o coor<strong>di</strong>nato.<br />
• Tracciabilità dello sviluppo. È necessario rappresentare le informazioni<br />
relative agli autori del documento ed a coloro che hanno introdotto<br />
note e/o apportato mo<strong>di</strong>fiche alla configurazione.<br />
21
Cooperazione e collaborazione nelle organizzazioni Il concetto <strong>di</strong> configurazione<br />
• Rilascio dei documenti. Deve essere tenuta memoria dei documenti<br />
che lasciano il sistema o che com<strong>un</strong>que vengono com<strong>un</strong>icati all’esterno.<br />
• Gestione dell’ambiente <strong>di</strong> lavoro. Deve essere possibile svolgere le<br />
attività lavorative sia in modo in<strong>di</strong>viduale che collettivo.<br />
• Gestione delle mo<strong>di</strong>fiche. Le mo<strong>di</strong>fiche devono essere applicate secondo<br />
criteri prestabiliti o eventualmente selezionabili tra quelli <strong>di</strong>sponibili.<br />
22
Capitolo<br />
2<br />
Versioning a supporto della<br />
collaborazione<br />
La gestione delle versioni riguarda <strong>un</strong> sottoinsieme delle attività previste<br />
nell’ambito del Document Management. Nello sviluppo del software, il<br />
versioning <strong>di</strong>viene <strong>un</strong> argomento centrale, in<strong>di</strong>pendentemente dalla strategia<br />
adottata. Per questo motivo molti modelli, sistemi e applicazioni sono stati<br />
pensati e realizzati per coor<strong>di</strong>nare la produzione del co<strong>di</strong>ce sorgente, dei<br />
binari e il rilascio dei pacchetti.<br />
La gestione automatizzata delle versioni aiuta nello sviluppo e nella manutenzione<br />
dei dati, incrementando la qualità dei processi. Se il processo è<br />
efficace, allora permette benefici nel lavoro collaborativo, assicurando fiducia<br />
nel conseguire le finalità.<br />
Nelle organizzazioni la rilevanza del problema si ripropone con le stesse<br />
caratteristiche, ma con maggiore gravità. Non solo c’è bisogno <strong>di</strong> mantenere<br />
<strong>un</strong>’accurata storia dei documenti, per adempiere agli obblighi amministrativi,<br />
ma anche per poter rintracciare ed ottenere, con il minimo errore, i dati più<br />
recenti o relativi ad <strong>un</strong> preciso periodo storico.<br />
È facile comprendere che l’authoring concorrente, e volendo generalizzare<br />
il Document Management, risultano essere strettamente correlati alla gestione<br />
delle versioni. In origine si assumeva implicitamente che le persone, così<br />
come le risorse, fossero localizzate nello stesso sito geografico. Con il successo
Versioning a supporto della collaborazione Il controllo delle versioni<br />
<strong>di</strong> Internet, l’authoring è <strong>di</strong>venuto <strong>un</strong>’attività <strong>di</strong>stribuita. Oggi esiste il bisogno<br />
<strong>di</strong> sviluppare nuovi strumenti, capaci <strong>di</strong> agevolare i processi da luoghi<br />
geograficamente <strong>di</strong>spersi.<br />
In questo capitolo vengono introdotti i concetti legati alla gestione delle<br />
versioni, viene <strong>di</strong>scusso dettagliatamente il <strong>modello</strong> UEVM e vengono descritte,<br />
in or<strong>di</strong>ne cronologico <strong>di</strong> introduzione, alc<strong>un</strong>e delle applicazioni più<br />
note per la gestione delle versioni nell’ambito dello sviluppo del software:<br />
– RCS (paragrafo 2.6);<br />
– CVS (paragrafo 2.7);<br />
– Subversion (paragrafo 2.8).<br />
Dall’evoluzione <strong>di</strong> tali applicazioni si capisce che il mercato si sta <strong>di</strong>rigendo<br />
verso soluzioni che facilitano sempre più il lavoro collaborativo, questo<br />
perché lo sviluppo <strong>di</strong> software è <strong>un</strong>’attività complessa che normalmente viene<br />
effettuata da <strong>un</strong> numero più o meno elevato <strong>di</strong> persone. Attualmente infatti<br />
stanno nascendo ambienti <strong>di</strong> sviluppo integrati (IDE) che non si limitano<br />
ad agevolare il lavoro del singolo programmatore o ad integrare plugin per<br />
interfacciarsi a sistemi <strong>di</strong> versioning come quelli menzionati, ma che mettono<br />
a <strong>di</strong>sposizione dei tool specifici per la collaborazione (come l’interazione<br />
asincrona/sincrona e la gestione integrata delle versioni):<br />
– COOP/Orm (paragrafo 2.9).<br />
Infine vengono introdotti alc<strong>un</strong>i sistemi che non basano il proprio principio<br />
<strong>di</strong> f<strong>un</strong>zionamento sul para<strong>di</strong>gma client/server, ma su quello peer-to-peer:<br />
– BitKeeper, Git, Svk. (paragrafo 2.10).<br />
2.1 Il controllo delle versioni<br />
La possibilità <strong>di</strong> memorizzare, creare e registrare la storia <strong>di</strong> <strong>un</strong> documento<br />
è la caratteristica fondamentale <strong>di</strong> <strong>un</strong> sistema per la gestione delle<br />
versioni. Tra <strong>un</strong>a mo<strong>di</strong>fica e la successiva, l’entità assume <strong>un</strong> certo stato, il<br />
quale viene identificato con <strong>un</strong>a versione. La versione <strong>di</strong> <strong>un</strong>’entità rimane<br />
immutabile nel tempo, dato che non può essere ulteriormente mo<strong>di</strong>ficata.<br />
Se l’authoring avviene in sequenza, l’organizzazione delle versioni è sequenziale,<br />
in questo caso si parla <strong>di</strong> revisioni. Invece se l’authoring avviene<br />
24
Versioning a supporto della collaborazione Modelli <strong>di</strong> sincronizzazione<br />
in parallelo, si parla <strong>di</strong> <strong>di</strong>ramazioni o branch. Ogni <strong>di</strong>ramazione può convergere<br />
verso <strong>un</strong>a nuova versione, la quale ha due o più predecessori (merge).<br />
Nel caso in cui <strong>un</strong>a <strong>di</strong>ramazione non converga mai, si <strong>di</strong>ce che ha originato<br />
<strong>un</strong>a variante (figura 2.1).<br />
Revisione<br />
1 2<br />
Variante<br />
Diramazione<br />
3<br />
Diramazione<br />
5<br />
A<br />
Convergenza<br />
4 7 8<br />
6<br />
Revisione Revisione<br />
Convergenza<br />
B C<br />
Revisione<br />
Figura 2.1: Rappresentazione della storia delle versioni.<br />
Solitamente le revisioni sono create dallo stesso autore, mentre le <strong>di</strong>ramazioni<br />
avvengono quando l’e<strong>di</strong>ting è concorrente. Le <strong>di</strong>ramazioni sono necessarie<br />
almeno per consentire <strong>un</strong>a temporanea elaborazione locale. Una <strong>di</strong>ramazione<br />
consiste in <strong>un</strong>a serie <strong>di</strong> revisioni che a loro volta possono originare<br />
<strong>di</strong>ramazioni.<br />
2.2 Modelli <strong>di</strong> sincronizzazione<br />
Le attività concorrenti degli utenti coinvolgono la mo<strong>di</strong>fica delle configurazioni.<br />
Dovrà quin<strong>di</strong> esistere <strong>un</strong> meccanismo <strong>di</strong> sincronizzazione delle<br />
risorse capace <strong>di</strong> garantirne la consistenza e <strong>di</strong> dare <strong>un</strong>a visione il più possibile<br />
<strong>un</strong>ificata e coerente, valida per tutti gli utenti. I possibili modelli <strong>di</strong><br />
sincronizzazione, descritti in [Fei91], sono: checkout/checkin, composizione,<br />
l<strong>un</strong>ghe transazioni e change set.<br />
25
Versioning a supporto della collaborazione Modelli <strong>di</strong> sincronizzazione<br />
2.2.1 Checkout/Checkin<br />
I documenti sono memorizzati sotto forma <strong>di</strong> file in <strong>un</strong> repository. I file<br />
non sono leggibili o mo<strong>di</strong>ficabili <strong>di</strong>rettamente, se non prima che il checkout<br />
venga applicato. Effettuare il checkout significa che i file vengono copiati nell’area<br />
<strong>di</strong> lavoro dell’utente (<strong>di</strong>rectory locale) e che gli originali nel repository<br />
vengono posti in stato <strong>di</strong> lock. Il lock previene il checkout <strong>di</strong> altri utenti.<br />
Quando il file subisce il checkin le mo<strong>di</strong>fiche apportate in locale vengono<br />
integrate nel repository generando <strong>un</strong>a nuova versione, inoltre viene rilasciato<br />
il lock sul documento <strong>di</strong> origine.<br />
Il tagging è l’operazione che serve per etichettare, con <strong>un</strong> nome simbolico,<br />
le versioni dei file appartenenti ad <strong>un</strong>a data configurazione. Questo permette,<br />
successivamente, l’operazione <strong>di</strong> recupero delle versioni dei file associate a tale<br />
configurazione. Sarà possibile trovare ulteriori dettagli su questo meccanismo<br />
in seguito, dove verrà descritto il sistema RCS (paragrafo 2.6).<br />
Uno dei vantaggi <strong>di</strong> questo <strong>modello</strong> è che risulta estremamente semplice<br />
sia da implementare in sistemi <strong>di</strong> vario tipo che da capire da parte<br />
dell’utilizzatore.<br />
Il principale rovescio della medaglia è che il meccanismo <strong>di</strong> locking penalizza<br />
il lavoro a più mani implementando il para<strong>di</strong>gma turn-taking (paragrafo<br />
1.2.4, pagina 17).<br />
2.2.2 Composizione<br />
La composizione è <strong>un</strong>a estensione del <strong>modello</strong> checkout/checkin rispetto<br />
al quale aggi<strong>un</strong>ge il supporto esplicito alla gestione delle configurazioni, che,<br />
in questo caso, sono entità note al sistema <strong>di</strong> gestione delle versioni. Per<br />
quanto riguarda la gestione del repository, delle fasi <strong>di</strong> checkout e <strong>di</strong> checkin,<br />
del concetto <strong>di</strong> <strong>di</strong>rectory <strong>di</strong> lavoro locale e del concetto <strong>di</strong> sincronizzazione<br />
tramite locking, il <strong>modello</strong> è del tutto simile a quello precedente.<br />
La necessità <strong>di</strong> introdurre <strong>un</strong> <strong>modello</strong> più evoluto del checkout/checkin<br />
è dettata dal fatto che il tagging può non essere sufficiente per recuperare<br />
<strong>un</strong>a configurazione. Questo perché le configurazioni hanno natura <strong>di</strong>namica<br />
in quanto la loro struttura può variare nel tempo. Inoltre l’utente potrebbe<br />
essere interessato ad accedere ad <strong>un</strong> sottoinsieme del sistema, operazione<br />
possibile solo se il <strong>modello</strong> è in grado <strong>di</strong> stabilire se <strong>un</strong>a data entità appartiene<br />
o meno al sottoinsieme <strong>di</strong> interesse, il che equivale a richiedere che esso<br />
sia in grado <strong>di</strong> comprendere la struttura del sistema. In questo caso, fissato<br />
26
Versioning a supporto della collaborazione Modelli <strong>di</strong> sincronizzazione<br />
l’insieme dei file presi in carico dal sistema <strong>di</strong> versioning (tutti i file che sono<br />
stati interessati da <strong>un</strong>a o più operazioni <strong>di</strong> checkin), occorre definire <strong>un</strong> meccanismo<br />
che permetta, per prima cosa, <strong>di</strong> selezionare quali file appartengono<br />
alla configurazione <strong>di</strong> interesse e, successivamente, in quale versione. Considerando<br />
che <strong>un</strong> sistema può essere definito come <strong>un</strong> insieme <strong>di</strong> sottosistemi,<br />
i quali a loro volta possono essere scomposti fino al raggi<strong>un</strong>gimento <strong>di</strong> entità<br />
non ulteriormente <strong>di</strong>visibili, è semplice descrivere tale meccanismo in termini<br />
ricorsivi.<br />
La definizione <strong>di</strong> <strong>un</strong>a configurazione, pertanto, avviene in due passi:<br />
1. tramite <strong>un</strong> opport<strong>un</strong>o <strong>modello</strong> del sistema vengono selezionati i documenti<br />
che devono essere inclusi nella configurazione;<br />
2. vengono stabilite le regole per determinare la versione <strong>di</strong> ogni documento<br />
incluso.<br />
2.2.3 Transazioni estese nel tempo<br />
Questo <strong>modello</strong> si presta ad essere adottato quando lo sviluppo dell’intero<br />
sistema coinvolge molti utenti e procede per integrazione <strong>di</strong> mo<strong>di</strong>fiche che<br />
possono essere anche <strong>di</strong> grande entità. Ogni utente <strong>di</strong>spone <strong>di</strong> <strong>un</strong>’area <strong>di</strong><br />
lavoro personale per creare le proprie mo<strong>di</strong>fiche e solo ad operazioni concluse<br />
provvede ad aggiornare l’area <strong>di</strong> lavoro com<strong>un</strong>e.<br />
Area <strong>di</strong> lavoro con<strong>di</strong>visa<br />
1 3 2 4<br />
5 6<br />
Area <strong>di</strong> lavoro personale A Area <strong>di</strong> lavoro personale B<br />
Figura 2.2: Para<strong>di</strong>gma <strong>di</strong> interazione.<br />
27
Versioning a supporto della collaborazione Modelli <strong>di</strong> sincronizzazione<br />
I singoli file possono essere gestiti con il <strong>modello</strong> checkout/checkin e il<br />
ciclo canonico <strong>di</strong> lavoro prevede la copia, la mo<strong>di</strong>fica e l’aggiornamento dei<br />
dati. Cicli <strong>di</strong> questo tipo, nel contesto dei database, sono noti con il nome <strong>di</strong><br />
l<strong>un</strong>ga transazione e questo fatto ha dato origine al nome del <strong>modello</strong>.<br />
In figura 2.2 è riportato <strong>un</strong>o scenario, abbastanza generico, che può presentarsi<br />
durante l’uso <strong>di</strong> CM che basano il loro principio <strong>di</strong> f<strong>un</strong>zionamento<br />
su questo <strong>modello</strong> (ad esempio CVS e Subversion descritti, rispettivamente,<br />
nel paragrafo 2.7 e nel paragrafo 2.8). Gli utenti A e B aggiornano il proprio<br />
ambiente <strong>di</strong> lavoro locale (fasi 1 e 2). A apporta nel proprio ambiente<br />
<strong>di</strong> lavoro mo<strong>di</strong>fiche che, a loro volta, possono essere gestite tramite <strong>un</strong> CM<br />
locale e B fa altrettanto. Quin<strong>di</strong> A decide <strong>di</strong> aggiornare l’ambiente <strong>di</strong> lavoro<br />
con<strong>di</strong>viso: siccome l’ultima versione presente nell’area con<strong>di</strong>visa coincide con<br />
quella che l’utente A ha utilizzato per apportare le mo<strong>di</strong>fiche, l’integrazione<br />
è imme<strong>di</strong>ata (passo 3). L’utente B decide <strong>di</strong> integrare le proprie mo<strong>di</strong>fiche<br />
(passo 4). Il sistema rileva che la copia presente nell’area com<strong>un</strong>e e quella<br />
utilizzata da B come base <strong>di</strong> partenza per le proprie mo<strong>di</strong>fiche <strong>di</strong>fferiscono,<br />
conseguentemente il sistema impe<strong>di</strong>sce a B <strong>di</strong> portare a termine l’operazione.<br />
L’utente B è obbligato ad aggiornare la propria copia locale per integrare le<br />
mo<strong>di</strong>fiche più recenti apportate al sistema, in questo caso quelle apportate<br />
da A (passo 5). In questa fase B deve, nel caso si fossero presentati, risolvere<br />
i conflitti, ovvero aggiornare le eventuali parti del sistema mo<strong>di</strong>ficate sia da<br />
lui che da altri sviluppatori. Solo a questo p<strong>un</strong>to B potrà integrare le proprie<br />
mo<strong>di</strong>fiche nella copia con<strong>di</strong>visa (passo 6).<br />
Il <strong>modello</strong> è da considerarsi ottimistico in quanto non prevede mai il<br />
blocco del lavoro concorrente. È sempre possibile creare nuovi ambienti <strong>di</strong><br />
sviluppo personali (paralleli a quelli esistenti) sui quali non è possibile evitare,<br />
preventivamente, la nascita <strong>di</strong> conflitti. Fort<strong>un</strong>atamente i dati derivanti da<br />
vari anni <strong>di</strong> esperienza nel settore dei CM evidenziano che i casi in cui la<br />
risoluzione dei conflitti è <strong>di</strong>fficoltosa risultano molto rari.<br />
Il <strong>modello</strong> può essere generalizzato per prevedere che l’area <strong>di</strong> lavoro locale<br />
possa essere utilizzata contemporaneamente da più sviluppatori e, in tal caso,<br />
occorre gestirne l’accesso concorrente con <strong>un</strong> CM specifico.<br />
2.2.4 Change set<br />
Questo <strong>modello</strong> permette <strong>di</strong> gestire i cambiamenti logici del documento.<br />
Ad esempio, nello sviluppo <strong>di</strong> software, <strong>un</strong> cambiamento logico potrebbe es-<br />
28
Versioning a supporto della collaborazione Modelli <strong>di</strong> sincronizzazione<br />
sere la correzione <strong>di</strong> <strong>un</strong> bug oppure l’aggi<strong>un</strong>ta <strong>di</strong> <strong>un</strong>a nuova f<strong>un</strong>zionalità nel<br />
programma. Queste operazioni richiedono la mo<strong>di</strong>fica <strong>di</strong> alc<strong>un</strong>i file ed eventualmente<br />
varie mo<strong>di</strong>fiche, in sezioni <strong>di</strong>verse, dello stesso file. È importante<br />
mantenere l’informazione che tutte le mo<strong>di</strong>fiche sono correlate e finalizzate al<br />
raggi<strong>un</strong>gimento del medesimo cambiamento logico. Il mantenimento <strong>di</strong> tali<br />
corrispondenze è alla base del <strong>modello</strong> (la filosofia è la stessa dell’approccio<br />
anatomico descritto nel paragrafo 1.2.4 a pagina 16).<br />
In questo <strong>modello</strong> le versioni sono organizzate partendo da <strong>un</strong> insieme <strong>di</strong><br />
configurazioni predeterminate, utilizzate come base <strong>di</strong> partenza, rispetto alle<br />
quali vengono aggi<strong>un</strong>ti <strong>un</strong> certo numero <strong>di</strong> cambiamenti logici non correlati.<br />
Ogni aggi<strong>un</strong>ta genera <strong>un</strong>a nuova configurazione. Il meccanismo che gestisce<br />
l’aggi<strong>un</strong>ta dei cambiamenti logici fa sì che due cambiamenti logici mutuamente<br />
esclusivi non vengano applicati contemporaneamente oppure che, qualora<br />
alc<strong>un</strong>i cambiamenti ne richiedano altri, questi ultimi debbano essere applicati<br />
per primi.<br />
Questo <strong>modello</strong> viene tipicamente utilizzato nella fase <strong>di</strong> manutenzione<br />
dei sistemi operativi che sono organizzati in “release” con <strong>un</strong> largo numero <strong>di</strong><br />
“patch”.<br />
Il <strong>modello</strong> incoraggia <strong>un</strong>a strategia conservativa <strong>di</strong> integrazione delle mo<strong>di</strong>fiche<br />
e, in ogni caso, non ottimistica nel senso che forza l’integrazione solo<br />
quando è realmente necessaria.<br />
Sotto certi p<strong>un</strong>ti <strong>di</strong> vista il <strong>modello</strong> change set è simile al <strong>modello</strong> basato<br />
sulle transazioni estese nel tempo. La <strong>di</strong>fferenza sostanziale è che nel <strong>modello</strong><br />
basato sulle transazioni estese nel tempo la sequenza con cui vengono integrate<br />
le mo<strong>di</strong>fiche è la stessa sequenza con cui vengono effettuate le transazioni.<br />
Nel <strong>modello</strong> change set questo vincolo è meno rigido in quanto è possibile<br />
integrare le mo<strong>di</strong>fiche in qual<strong>un</strong>que or<strong>di</strong>ne (a patto <strong>di</strong> rispettare gli eventuali<br />
vincoli).<br />
Il <strong>modello</strong> change set è vantaggioso nella gestione <strong>di</strong> sistemi con <strong>un</strong> grande<br />
numero <strong>di</strong> varianti (come i già citati sistemi operativi) in quanto garantisce<br />
<strong>un</strong>a maggiore flessibilità permettendo <strong>di</strong> creare tutte le permutazioni possibili<br />
<strong>di</strong> configurazioni (vincoli permettendo). Lo svantaggio è che può essere<br />
<strong>di</strong>fficile <strong>di</strong>stinguere quali sono le configurazioni realmente utili dalle altre.<br />
29
Versioning a supporto della collaborazione Modelli <strong>di</strong> versioning<br />
2.3 Modelli <strong>di</strong> versioning<br />
Un <strong>modello</strong> per il configuration management (paragrafo 1.3 a pagina 19)<br />
definisce gli oggetti che devono essere trattati, il loro identificativo, la loro<br />
organizzazione, le operazioni per creare nuove versioni e riceverle.<br />
Molti modelli assumono che esista <strong>un</strong>a netta separazione fra come essi<br />
gestiscono le informazioni atomiche (o elementari, che non possono essere<br />
ulteriormente scisse) e l’eventuale concetto <strong>di</strong> composizione che può esistere<br />
fra le stesse. In questi modelli le informazioni atomiche vengono versionate<br />
in<strong>di</strong>vidualmente e, andando a considerare tutte le informazioni contemporaneamente,<br />
il numero delle possibili combinazioni delle versioni e/o varianti<br />
è solitamente molto elevato e, normalmente, non tutte le combinazioni sono<br />
significative.<br />
Uno dei problemi fondamentali che si incontra quando si ha a che fare<br />
con le configurazioni è che, anche in presenza <strong>di</strong> <strong>un</strong> limitato numero <strong>di</strong><br />
componenti, ogn<strong>un</strong>a con le proprie versioni e varianti, il numero <strong>di</strong> combinazioni<br />
possibili (e quin<strong>di</strong> il numero <strong>di</strong> configurazioni possibili) può essere<br />
molto grande. Da <strong>un</strong> p<strong>un</strong>to <strong>di</strong> vista matematico cresce esponenzialmente<br />
con il numero delle componenti e delle versioni e, nei reali contesti applicativi,<br />
risulta impossibile gestire le configurazioni manualmente. Questo obbliga<br />
ogni <strong>modello</strong> a dover affrontare tale problema.<br />
Esistono due categorie <strong>di</strong> modelli <strong>di</strong> versioning: “versioning intensionale”<br />
e “versioning estensionale”.<br />
2.3.1 Modello intensionale<br />
Molti modelli e CM attuali si basano su <strong>un</strong> sistema che viene chiamato<br />
“versioning intensionale” delle relazioni strutturali per tenere sotto controllo<br />
il problema dell’esplosione esponenziale della complessità. Questo approccio<br />
si basa sulla formulazione <strong>di</strong> regole <strong>di</strong> selezione che vengono usate per<br />
scegliere la particolare variante o versione <strong>di</strong> <strong>un</strong>a determinata informazione<br />
atomica. Spesso queste regole vengono calcolate su richiesta, quando sorge<br />
la necessità <strong>di</strong> accedere all’informazione atomica per la visualizzazione o la<br />
mo<strong>di</strong>fica. Sebbene questo approccio permetta <strong>di</strong> ridurre la complessità del<br />
problema <strong>di</strong> selezione delle varie versioni, ha alc<strong>un</strong>i inconvenienti:<br />
• la rappresentazione della struttura è in<strong>di</strong>retta, impressa nella definizione<br />
delle regole stesse. Per scoprire quali informazioni atomiche, e in<br />
30
Versioning a supporto della collaborazione Modelli <strong>di</strong> versioning<br />
quali versioni, costituiscono <strong>un</strong>a certa entità, non c’è altra strada se non<br />
quella <strong>di</strong> applicare tutte le regole necessarie ed analizzare il risultato<br />
ottenuto;<br />
• è molto complesso confrontare entità <strong>di</strong>verse in base alle informazioni<br />
atomiche che le costituiscono ed alle versioni in cui compaiono. Questo<br />
perché occorre applicare tutte le regole necessarie per entrambe le entità<br />
e confrontare i risultati ottenuti;<br />
• la consistenza è <strong>di</strong>fficile da garantire perché alc<strong>un</strong>i errori nelle regole<br />
potrebbero rimanere latenti per molto tempo e manifestarsi solo con la<br />
creazione <strong>di</strong> <strong>un</strong>a nuova versione <strong>di</strong> qualche informazione atomica che<br />
genera <strong>un</strong>a struttura non valida. Come conseguenza non c’è la garanzia<br />
che <strong>un</strong> dato insieme <strong>di</strong> regole permetta <strong>di</strong> ottenere lo stesso insieme <strong>di</strong><br />
informazioni atomiche, nelle stesse versioni se applicate in istanti <strong>di</strong><br />
tempo <strong>di</strong>versi. Questo inconveniente è reale e noto, tanto è vero che<br />
nello sviluppo del software è uso com<strong>un</strong>e salvare i sorgenti relativi a<br />
versioni <strong>di</strong> particolare importanza (come le major release) al <strong>di</strong> fuori<br />
del sistema <strong>di</strong> versioning per essere certi che in qual<strong>un</strong>que istante futuro<br />
possa essere possibile ottenere i sorgenti corretti relativi alla versione<br />
<strong>di</strong> interesse con probabilità <strong>di</strong> errore nulla;<br />
• il “tagging” prevede l’uso <strong>di</strong> etichette da applicare in<strong>di</strong>vidualmente ad<br />
ogni file per la memorizzazione della relativa versione. Sfort<strong>un</strong>atamente<br />
questo è <strong>un</strong> meccanismo primitivo in quanto non c’è ness<strong>un</strong>a garanzia<br />
che queste etichette non vengano mo<strong>di</strong>ficate per errore (o in modo<br />
fraudolento). Questo non permette <strong>di</strong> mettere <strong>di</strong>rettamente in relazione<br />
versioni <strong>di</strong>verse l’<strong>un</strong>a con l’altra oppure <strong>di</strong> calcolare le <strong>di</strong>fferenze fra <strong>di</strong><br />
esse;<br />
• le regole possono includere facilitazioni per l’accesso a particolari versioni<br />
<strong>di</strong> <strong>un</strong>’informazione atomica come la “Ultima” (che cambia ogni<br />
volta). Regole come questa generano ogni volta risultati <strong>di</strong>versi. Questo<br />
meccanismo può essere visto come <strong>un</strong> modo per limitare gli effetti<br />
legati al problema della crescita esponenziale della complessità, ma rende<br />
più <strong>di</strong>fficoltosa la tracciabilità in quanto è impossibile garantire che<br />
lo stesso risultato venga ottenuto applicando le stesse regole in istanti<br />
<strong>di</strong> tempo <strong>di</strong>versi.<br />
31
Versioning a supporto della collaborazione Modelli <strong>di</strong> versioning<br />
2.3.2 Modello estensionale<br />
Nel “versioning estensionale” tutte le versioni della stessa entità sono singolarmente<br />
identificabili ed appartengono ad <strong>un</strong> insieme numerabile. L’utente<br />
ottiene la versione Vj, effettua le mo<strong>di</strong>fiche e con<strong>di</strong>vide con gli altri la nuova<br />
versione Vj+1. Tra Vj e Vj+1 esiste <strong>un</strong>a relazione <strong>di</strong> “derivazione”.<br />
Una data versione può essere recuperata in tempi successivi, in modo<br />
identico a come è stata creata. Le versioni della stessa entità possono essere<br />
confrontate e relazionate attraverso l’or<strong>di</strong>namento parziale della relazione <strong>di</strong><br />
“derivazione”. Le versioni e le relazioni sono tipicamente rappresentate con<br />
<strong>un</strong> grafo simile al quello <strong>di</strong> figura 2.1 (a pagina 25).<br />
2.3.3 Valutazione dei modelli<br />
Si chiamano sistemi basati sulle variazioni quelli che si focalizzano sulle<br />
<strong>di</strong>fferenze fra due versioni <strong>di</strong>verse <strong>di</strong> <strong>un</strong>a data informazione invece che sulle<br />
versioni stesse. Un vantaggio <strong>di</strong> questo meccanismo è che le <strong>di</strong>fferenze possono<br />
essere combinate anche in molti mo<strong>di</strong> che non corrispondono alle versioni<br />
dei sistemi basati sullo stato (nei quali l’attenzione viene concentrata proprio<br />
sulle singole versioni e non sulle <strong>di</strong>fferenze fra le stesse) in quanto è possibile<br />
scegliere anche mo<strong>di</strong> non previsti durante la fase <strong>di</strong> creazione delle singole<br />
<strong>di</strong>fferenze. Le combinazioni ammissibili non sono tutte quelle possibili (alc<strong>un</strong>e<br />
<strong>di</strong>fferenze possono essere legate ad altre), ma la <strong>di</strong>fferenza rispetto ai<br />
sistemi basati sullo stato è com<strong>un</strong>que notevole (ve<strong>di</strong> il <strong>modello</strong> Change set,<br />
paragrafo 2.2.4). Questo perché tutte le versioni <strong>di</strong>stinte <strong>di</strong>scriminate dai<br />
sistemi basati sullo stato, possono essere ottenute attraverso <strong>un</strong> banale meccanismo<br />
<strong>di</strong> fusione fra la versione iniziale e la sequenza or<strong>di</strong>nata <strong>di</strong> <strong>di</strong>fferenze<br />
prese in esame in questi sitemi che è solo <strong>un</strong>a delle possibili permutazioni.<br />
Una specifica versione <strong>di</strong> <strong>un</strong>a informazione atomica viene generata attraverso<br />
il meccanismo <strong>di</strong> fusione, appena citato, ogni volta che serve. Nei sistemi<br />
basati sulle variazioni questa operazione viene effettuata attraverso regole<br />
ben precise ovvero viene usato versioning intensionale anche per le entità<br />
atomiche.<br />
Nei sistemi basati sulle variazioni il numero <strong>di</strong> possibili versioni <strong>di</strong> ogni<br />
entità atomica è elevato e, conseguentemente, il numero delle combinazioni<br />
possibili fra le varie versioni delle varie entità che possono dar vita a configurazioni<br />
è enorme. Il problema della complessità è ancora più evidente in questi<br />
32
Versioning a supporto della collaborazione Unified Extensional Versioning Model<br />
sistemi. Nei sistemi esistenti viene affrontato tramite versioning intensionale<br />
e in generale valgono tutte le considerazioni riportate precedentemente.<br />
Si chiamano sistemi basati sullo stato quelli che usano versioning estensionale<br />
quando hanno a che fare con entità atomiche, pertanto, per queste<br />
ultime, tutte le possibili versioni vengono rappresentate esplicitamente. Tali<br />
versioni possono, per esempio, essere rappresentate in <strong>un</strong> grafo e <strong>un</strong>a data<br />
versione può essere in<strong>di</strong>viduata <strong>un</strong>ivocamente in ogni momento <strong>un</strong>a volta fissato<br />
il cammino nel grafo. Le versioni delle entità possono essere confrontate<br />
e messe in relazione le <strong>un</strong>e con le altre grazie ad <strong>un</strong>a relazione parziale <strong>di</strong><br />
“derivazione”. I problemi relativi all’uso del versioning intensionale, in questo<br />
caso, non si verificano per le entità atomiche in quanto per esse viene<br />
utilizzato il versioning estensionale.<br />
Una critica fondamentale ai sistemi basati sullo stato è che questi offrono<br />
meccanismi molto <strong>di</strong>versi per trattare le entità atomiche e le relazioni strutturali.<br />
Sfort<strong>un</strong>atamente questo porta ad <strong>un</strong>a proliferazione <strong>di</strong> concetti senza<br />
risolvere i problemi del versioning intensionale in quanto lo si ritrova per la<br />
gestione degli aspetti strutturali.<br />
2.3.4 Una nuova alternativa: UEVM<br />
I sistemi tra<strong>di</strong>zionali, sia basati sullo stato che sulle variazioni, si comportano<br />
in modo simile (versioning intensionale) per la gestione degli aspetti<br />
strutturali.<br />
Nel paragrafo successivo verrà descritto il <strong>modello</strong> Unified Extensional<br />
Versioning Model (UEVM ). Questo <strong>modello</strong> rappresenta <strong>un</strong> nuovo approccio<br />
che permette <strong>di</strong> utilizzare versioning esplicito anche per le relazioni strutturali.<br />
Viene mostrato come viene minimizzato il problema dell’esplosione della<br />
complessità e come risolve i problemi relativi al versioning intensionale per<br />
le relazioni strutturali. Infine ha il vantaggio <strong>di</strong> offrire <strong>un</strong> approccio <strong>un</strong>ificato<br />
sia per il versioning delle entità atomiche che per le relazioni strutturali.<br />
2.4 Unified Extensional Versioning Model<br />
Unified Extensional Versioning Model (UEVM) è <strong>un</strong> nuovo approccio che<br />
tratta allo stesso modo i documenti e le configurazioni. Nell’ambito della<br />
ricerca sono state realizzate alc<strong>un</strong>e implementazioni parziali e/o prototipi<br />
basati su tale <strong>modello</strong>:<br />
33
Versioning a supporto della collaborazione Unified Extensional Versioning Model<br />
Versioning<br />
Intensionale<br />
Versioning<br />
Estensionale<br />
Entità atomiche<br />
(file)<br />
Sistemi basati<br />
sulle variazioni<br />
Sistemi basati sullo<br />
stato o su UEVM<br />
Configurazioni<br />
Sistemi basati sulle<br />
variazioni o sullo stato<br />
Sistemi basati<br />
su UEVM<br />
Tabella 2.1: Approcci <strong>di</strong> versioning adottati dai CM sui vari tipi <strong>di</strong> entità.<br />
• COOP/Orm: ambiente <strong>di</strong> programmazione multiutente;<br />
• CoEd: e<strong>di</strong>tor collaborativo;<br />
• Ragnarok: tool per lo sviluppo <strong>di</strong> architetture software.<br />
UEVM definisce <strong>un</strong> proprio <strong>modello</strong> per il documento sul quale stabilisce<br />
i criteri per il versioning. Nella paragrafo successivo verrà descritto il <strong>modello</strong><br />
adottato [ABCM99].<br />
2.4.1 Il <strong>modello</strong><br />
Il <strong>modello</strong> del documento<br />
Il documento è <strong>un</strong>’entità strutturata la cui struttura può essere definita,<br />
in modo molto conveniente, con la grammatica riportata in tabella 2.2. Sostanzialmente<br />
il documento è <strong>un</strong>a struttura gerarchica, ad albero. Eventuali<br />
legami fra documenti <strong>di</strong>stinti vengono modellati tramite il concetto <strong>di</strong> link.<br />
Il termine documento è da intendersi nel senso più generale possibile: può<br />
essere <strong>un</strong> file, <strong>un</strong> dataset contenente qual<strong>un</strong>que tipo <strong>di</strong> informazione, <strong>un</strong> testo<br />
in italiano, in inglese, eccetera.<br />
Di seguito viene introdotto il significato che ha ogni nodo del <strong>modello</strong><br />
UEVM, in relazione alla struttura del documento:<br />
D: rappresentazione astratta del documento.<br />
grammatica (assioma).<br />
È il simbolo iniziale della<br />
A: albero. È <strong>un</strong> simbolo astratto, non terminale, che quin<strong>di</strong> non compare<br />
nella stringa dei terminali che rappresenta il documento. Il nome del<br />
34
Versioning a supporto della collaborazione Unified Extensional Versioning Model<br />
D ::= A<br />
A ::= C|L|N<br />
C ::= A*[“dati”]<br />
L ::= “nome”-“ver.”<br />
N ::= “dati”<br />
D: documento. Nodo astratto non terminale.<br />
A: albero. Nodo astratto non terminale.<br />
C: composizione. Nodo concreto, produzione.<br />
L: link. Nodo concreto, produzione.<br />
N: informazione atomica. Nodo concreto, produzione.<br />
Tabella 2.2: Grammatica che definisce la struttura del documento.<br />
simbolo non è stato scelto casualmente in quanto, a partire da ogni<br />
nodo <strong>di</strong> tipo A, la grammatica produce <strong>un</strong> albero che, oltre ad essere<br />
proprio della sequenza delle produzioni, modella anche la struttura del<br />
documento.<br />
N: no<strong>di</strong> concreti, terminali, nei quali avviene l’archiviazione delle informazioni<br />
proprie del documento. Possono contenere co<strong>di</strong>ce sorgente,<br />
pagine web, immagini, filmati, file eseguibili oppure qual<strong>un</strong>que altra<br />
informazione che non abbia a che fare con il <strong>modello</strong> del documento.<br />
No<strong>di</strong> <strong>di</strong>fferenti possono contenere informazioni <strong>di</strong> tipo <strong>di</strong>verso: il <strong>modello</strong><br />
supporta nativamente documenti costituiti da informazioni <strong>di</strong> tipo<br />
eterogeneo.<br />
L: link, rappresentano relazioni arbitrarie fra documenti o parti <strong>di</strong> essi.<br />
Il “nome” è l’informazione che serve per identificare <strong>un</strong>ivocamente il<br />
documento e “ver.” è la particolare versione dello stesso alla quale il<br />
link si riferisce. Si pensi, per esempio, ad <strong>un</strong> riferimento bibliografico.<br />
Il “nome” potrebbe essere l’insieme delle informazioni:<br />
– nome e cognome dell’autore;<br />
– titolo dell’opera;<br />
– casa e<strong>di</strong>trice.<br />
La versione potrebbe essere rappresentata dall’e<strong>di</strong>zione. Un link con<br />
queste caratteristiche permette <strong>di</strong> identificare <strong>un</strong>ivocamente la risorsa<br />
<strong>di</strong> interesse lasciando le due entità (documento nel quale compare la voce<br />
in bibliografia e libro a cui fa riferimento) del tutto in<strong>di</strong>pendenti. Il<br />
libro può essere aggiornato (nuove e<strong>di</strong>zioni) senza pregiu<strong>di</strong>care la comprensione<br />
del documento che lo riferisce. Questo perché il lettore può<br />
35
Versioning a supporto della collaborazione Unified Extensional Versioning Model<br />
com<strong>un</strong>que accedere alla versione esatta del libro che l’autore del documento<br />
ha utilizzato per la stesura dello stesso. L’autore del documento<br />
può, a sua volta, aggiornarlo e, se lo ritiene opport<strong>un</strong>o, mo<strong>di</strong>ficare la<br />
bibliografia in modo da riferire l’ultima versione del libro, come <strong>un</strong>a<br />
qual<strong>un</strong>que altra.<br />
C: relazioni <strong>di</strong> composizione fra l’intero documento e le parti <strong>di</strong> esso. Il<br />
concetto <strong>di</strong> composizione è quello che dà vita alle relazioni genitorefiglio<br />
nell’albero del documento. Si pensi alle relazioni che si hanno<br />
fra <strong>un</strong> libro e l’insieme dei capitoli che lo costituiscono, fra <strong>un</strong> capitolo<br />
e l’insieme <strong>di</strong> paragrafi che lo costituiscono, eccetera. Queste<br />
relazioni trasformano <strong>un</strong> insieme “piatto” 1 <strong>di</strong> informazioni in <strong>un</strong>’entità<br />
strutturata. In <strong>un</strong> libro, se cambia <strong>un</strong>a frase, cambia il paragrafo<br />
che la contiene e cambia anche il capitolo contenente il paragrafo. In<br />
ultima analisi cambia tutto il libro. Questo tipo <strong>di</strong> relazione è ben <strong>di</strong>verso<br />
dal collegamento modellato attraverso i no<strong>di</strong> <strong>di</strong> tipo L descritto<br />
in precedenza.<br />
Documenti <strong>di</strong> tipo tra<strong>di</strong>zionale, ovvero che non supportano internamente<br />
informazioni strutturate e collegamenti verso altri documenti, possono essere<br />
inquadrati nel <strong>modello</strong>: sono schematizzabili tramite <strong>un</strong> <strong>un</strong>ico nodo <strong>di</strong> tipo<br />
N.<br />
Un esempio <strong>di</strong> applicazione della grammatica, che permette <strong>di</strong> vedere<br />
come questa generi <strong>un</strong> documento strutturato ad albero, è riportato in<br />
figura 2.3:<br />
• l’assioma della grammatica è D, il documento;<br />
• la prima produzione genera A: questo risultato sottolinea il fatto che il<br />
documento è strutturato come <strong>un</strong> albero;<br />
• la seconda produzione, a partire da A, genera C (avrebbe potuto generare<br />
anche <strong>un</strong> nodo <strong>di</strong> tipo N oppure L): l’entità astratta albero ha C<br />
come ra<strong>di</strong>ce;<br />
• la produzione seguente, applicata a C, permette, opzionalmente 2 , <strong>di</strong><br />
1 La struttura gerarchica libro→capitoli→paragrafi→. . . , è astratta e prettamente <strong>di</strong><br />
convenienza, il libro, <strong>di</strong> fatto, è <strong>un</strong>a successione <strong>di</strong> parole.<br />
2 L’opzionalità è in<strong>di</strong>cata tramite parentesi quadre.<br />
36
Versioning a supporto della collaborazione Unified Extensional Versioning Model<br />
D<br />
D A<br />
D<br />
A<br />
D<br />
[data]<br />
A<br />
C<br />
A A<br />
[data] N<br />
A<br />
A<br />
N L<br />
D<br />
A<br />
[data]<br />
A A<br />
D<br />
D<br />
A<br />
[data]<br />
N L<br />
A<br />
C<br />
[data]<br />
[data]<br />
A<br />
N<br />
Figura 2.3: Esempi <strong>di</strong> applicazione della grammatica.<br />
associargli dei dati ed <strong>un</strong> numero <strong>di</strong> figli che va da zero a infinito 3 . I<br />
figli, a loro volta, sono strutturati ad albero e, nell’esempio, sono due;<br />
• le produzioni associate a tali alberi generano <strong>un</strong> nodo C ed <strong>un</strong> nodo N;<br />
• andando avanti si ottiene la struttura mostrata in basso a sinistra nella<br />
figura (che è solo <strong>un</strong>a fra quelle che sarebbe stato possibile ottenere).<br />
A tale struttura corrispondono solo simboli terminali e pertanto non è<br />
possibile applicare ulteriori produzioni.<br />
La figura riportata in basso a destra evidenzia ulteriormente come il documento<br />
generato dalla grammatica abbia <strong>un</strong>a struttura ad albero.<br />
Si osservi che sono le relazioni genitore-figlio che nascono dalle produzioni<br />
applicate a no<strong>di</strong> concreti a modellare la struttura del documento.<br />
3 Come per le espressioni regolari: il simbolo asterisco in<strong>di</strong>ca <strong>un</strong>a qual<strong>un</strong>que quantità<br />
fra zero ed infinito, estremi inclusi.<br />
N<br />
37
Versioning a supporto della collaborazione Unified Extensional Versioning Model<br />
C<br />
C<br />
N C<br />
N N N N<br />
N<br />
C<br />
N N<br />
L<br />
N<br />
C<br />
C L<br />
Figura 2.4: Esempi <strong>di</strong> documento.<br />
Esempio <strong>di</strong> documento strutturato<br />
N<br />
L<br />
C<br />
N N<br />
La figura 2.4 mostra <strong>un</strong> esempio <strong>di</strong> documento strutturato. Nella sezione<br />
sinistra della figura è presente <strong>un</strong> singolo documento strutturato ad albero.<br />
In quella <strong>di</strong> destra tre documenti strutturati ad albero sono collegati l’<strong>un</strong>o con<br />
l’altro. Le linee in<strong>di</strong>cano le relazioni <strong>di</strong> composizione interne al documento,<br />
mentre le frecce rappresentano riferimenti (link) fra documenti <strong>di</strong>versi.<br />
Riprendendo l’esempio del libro, precedentemente menzionato, è possibile<br />
mostrare questi concetti più concretamente.<br />
La sezione <strong>di</strong> sinistra della figura 2.5 mostra come <strong>un</strong> libro sia costituito da<br />
tre capitoli dove il primo e il terzo contengono, a loro volta, due paragrafi. Le<br />
relazioni fra il libro, i capitoli e i paragrafi sono, rispettivamente, “costituito<br />
da” e “contiene” e la struttura totale rappresenta <strong>un</strong>’<strong>un</strong>ica entità.<br />
Un altro esempio <strong>di</strong> documento strutturato che include anche no<strong>di</strong> <strong>di</strong><br />
tipo L può essere rappresentato da <strong>un</strong>’applicazione Java costituita da classi<br />
e package. La sezione <strong>di</strong> destra della figura 2.5 mostra come l’applicazione<br />
sia costituita da <strong>un</strong>a classe che ne importa altre due: A e B. Le relazioni<br />
38
Versioning a supporto della collaborazione Unified Extensional Versioning Model<br />
Libro<br />
Cap.1 Cap.2 Cap.3<br />
Par.1 Par.2 Par.1 Par.2<br />
Membro 1<br />
Import<br />
Classe A<br />
Membro 2<br />
Applicazione<br />
Classe 1<br />
Membro 1 Membro 2<br />
Super C.<br />
Membro 3<br />
Membro 1<br />
Import<br />
Classe B<br />
Membro 2<br />
Figura 2.5: Altri esempi <strong>di</strong> documenti strutturati: <strong>un</strong> libro e del co<strong>di</strong>ce Java.<br />
fra i membri della classe e la classe stessa sono dello stesso tipo <strong>di</strong> quelle<br />
del libro: “costituito da” e/o “contiene”. Viceversa le relazioni “Import” e<br />
“Super Class” sono concettualmente <strong>di</strong>verse e sono modellate tramite link.<br />
Che siano <strong>di</strong>verse si capisce semplicemente provando ad asserire: la classe<br />
B “è costituita da” la classe A il che è, ovviamente, errato. In ogni modo le<br />
classi A e B potrebbero venire incluse in altre applicazioni.<br />
Versioning<br />
In generale sia la struttura che il contenuto <strong>di</strong> <strong>un</strong> documento possono<br />
variare nel tempo. In UEVM tutti i tipi <strong>di</strong> nodo vengono esplicitamente<br />
versionati. La creazione <strong>di</strong> <strong>un</strong>a nuova versione <strong>di</strong> <strong>un</strong> nodo avviene in<br />
corrispondenza <strong>di</strong> <strong>un</strong>o dei seguenti eventi:<br />
• per i no<strong>di</strong> N o C quando cambiano i dati locali (interni al nodo stesso);<br />
• per i no<strong>di</strong> C anche quando viene aggi<strong>un</strong>to, rimosso o mo<strong>di</strong>ficato <strong>un</strong><br />
qual<strong>un</strong>que figlio;<br />
39
Versioning a supporto della collaborazione Unified Extensional Versioning Model<br />
• per i no<strong>di</strong> L quando cambia o il “nome” o la versione (“ver.”).<br />
Le mo<strong>di</strong>fiche al documento avvengono durante <strong>un</strong>a sessione ovvero <strong>un</strong>a l<strong>un</strong>ga<br />
transazione. La durata <strong>di</strong> <strong>un</strong>a sessione <strong>di</strong>pende dall’utente il quale, esplicitamente<br />
o implicitamente, la avvia e la termina. Durante <strong>un</strong>a sessione può<br />
essere creata al più <strong>un</strong>a nuova versione <strong>di</strong> ogni nodo, compatibilmente con le<br />
regole riportate precedentemente. Più mo<strong>di</strong>fiche ai dati <strong>di</strong> <strong>un</strong> nodo all’interno<br />
della solita sessione equivalgono ad <strong>un</strong>a sola mo<strong>di</strong>fica che le comprende tutte.<br />
Equivalentemente più operazioni <strong>di</strong> aggi<strong>un</strong>ta, rimozione o mo<strong>di</strong>fica <strong>di</strong> <strong>un</strong>o o<br />
più figli <strong>di</strong> <strong>un</strong> nodo <strong>di</strong> tipo C (all’interno della medesima sessione) danno vita<br />
ad <strong>un</strong>a sola nuova versione. La l<strong>un</strong>ghezza della sessione, ovvero il numero<br />
<strong>di</strong> cambiamenti che confluiscono nella nuova versione, è <strong>un</strong> parametro che<br />
può essere usato per controllare la granularità del versioning. Quando <strong>un</strong>a<br />
sessione termina la versione che viene creata <strong>di</strong> <strong>un</strong> nodo non può più essere<br />
mo<strong>di</strong>ficata.<br />
Le versioni sono legate tramite la relazione “derivato-da” e possono essere<br />
rappresentate da <strong>un</strong> arbitrario DAG 4 . Il meccanismo che gestisce il versioning<br />
può gestire lo sviluppo concorrente ed effettuare la fusione delle mo<strong>di</strong>fiche<br />
sul documento, sia per quel che riguarda le informazioni atomiche che quelle<br />
strutturali.<br />
Rispetto al singolo documento <strong>un</strong>a sessione può portare alla nascita <strong>di</strong><br />
<strong>un</strong>a nuova versione <strong>di</strong> tutto il documento. Alla fine della sessione si hanno<br />
zero o <strong>un</strong>a nuova versione <strong>di</strong> ogni nodo. Come messo in evidenza dall’elenco<br />
sopra riportato, i no<strong>di</strong> <strong>di</strong> tipo C vengono considerati mo<strong>di</strong>ficati anche quando<br />
viene aggi<strong>un</strong>to, rimosso o mo<strong>di</strong>ficato <strong>un</strong> qual<strong>un</strong>que figlio: questo genera <strong>un</strong><br />
effetto conosciuto come “propagazione dei cambiamenti” [Kat90]. Ogni mo<strong>di</strong>fica<br />
darà vita ad <strong>un</strong>a nuova versione <strong>di</strong> tutti gli antenati (genitore, nonno,<br />
bisnonno, etc.) e si propagherà verso la ra<strong>di</strong>ce. Il fatto che solo <strong>un</strong>a nuova<br />
versione <strong>di</strong> <strong>un</strong> genitore può nascere all’interno della stessa sessione, può<br />
essere visto come <strong>un</strong> meccanismo utile a concentrare le versioni.<br />
Questo meccanismo automatico <strong>di</strong> propagazione è consistente con la percezione<br />
che si ha delle mo<strong>di</strong>fiche architetturali in <strong>un</strong>’informazione strutturata.<br />
Come è già stato anticipato la mo<strong>di</strong>fica <strong>di</strong> <strong>un</strong> capitolo in <strong>un</strong> libro fa in modo<br />
che tutto il libro sia <strong>di</strong>verso. In altre parole la versione <strong>di</strong> <strong>un</strong> documento<br />
determina <strong>un</strong>ivocamente quali no<strong>di</strong> interni questo contiene e in quali versioni.<br />
4 Directed Acyclic Graph: grafo aciclico orientato.<br />
40
Versioning a supporto della collaborazione Unified Extensional Versioning Model<br />
Rispetto alle relazioni fra documenti il parametro <strong>di</strong> versione (“ver.”),<br />
memorizzato all’interno <strong>di</strong> <strong>un</strong> nodo L, identifica la versione del documento<br />
referenziato. Se si intende riferire <strong>un</strong>a versione <strong>di</strong>versa rispetto a quella memorizzata<br />
nel nodo L occorre creare <strong>un</strong>a nuova versione <strong>di</strong> L che la contenga<br />
(in ultima analisi, per propagazione, viene generata <strong>un</strong>a nuova versione <strong>di</strong><br />
tutto il documento che contiene L). Il <strong>modello</strong> impone che l’aggiornamento<br />
<strong>di</strong> <strong>un</strong> link, in modo che referenzi <strong>un</strong>a versione <strong>di</strong>versa del documento al<br />
quale si riferisce, generi <strong>un</strong>a nuova versione del documento che lo contiene.<br />
Quando e come questo avvenga non viene specificato dal <strong>modello</strong>: la politica<br />
verrà scelta in base alle singole esigenze del contesto applicativo nel quale<br />
si intende utilizzare UEVM. In generale com<strong>un</strong>que è importante ricordare<br />
che il meccanismo <strong>di</strong> gestione della sessione può essere usato per gestire la<br />
granularità del versioning.<br />
Versioning <strong>di</strong> <strong>un</strong> singolo documento<br />
La figura 2.6 mostra come evolve la struttura <strong>di</strong> <strong>un</strong> documento sottoposto<br />
a mo<strong>di</strong>fiche.<br />
C<br />
C<br />
1 2 3<br />
N C<br />
1 2 1 2<br />
N N N N<br />
a) Struttura iniziale del<br />
documento<br />
C<br />
C<br />
C<br />
N C<br />
N<br />
N N N<br />
3.1<br />
b) Il nodo 3.1 è stato<br />
mo<strong>di</strong>ficato<br />
C<br />
2<br />
C<br />
N<br />
C<br />
N<br />
N N N<br />
c) Anche il nodo 2 è stato<br />
mo<strong>di</strong>ficato<br />
Figura 2.6: Alc<strong>un</strong>i cambiamenti all’interno della stessa sessione.<br />
In figura 2.6.b i dati locali del nodo 3.1 sono stati mo<strong>di</strong>ficati e quin<strong>di</strong> si<br />
ha la nascita <strong>di</strong> <strong>un</strong>a nuova versione <strong>di</strong> tale nodo. Per propagazione viene<br />
creata <strong>un</strong>a nuova versione anche del padre (nodo 3) e quin<strong>di</strong> della ra<strong>di</strong>ce (si<br />
ha <strong>un</strong>a nuova versione del documento). In figura 2.6.c l’utente ha mo<strong>di</strong>ficato<br />
anche il nodo 2. Questo evento non innesca la propagazione perché è già<br />
41
Versioning a supporto della collaborazione Unified Extensional Versioning Model<br />
stata creata <strong>un</strong>a nuova versione della ra<strong>di</strong>ce (che in questo caso coincide con<br />
il genitore del nodo mo<strong>di</strong>ficato) all’interno della stessa sessione. Tale versione,<br />
quando verrà resa persistente con la chiusura della sessione, includerà<br />
entrambe le mo<strong>di</strong>fiche. Questo fenomeno permette all’utente <strong>di</strong> controllare<br />
quando generare nuove versioni oltre a quali mo<strong>di</strong>fiche debbano contenere.<br />
È possibile associare al documento in figura 2.6 il significato <strong>di</strong> libro con<br />
tre capitoli, come mostrato in figura 2.5. La mo<strong>di</strong>fica <strong>di</strong> <strong>un</strong>o dei paragrafi<br />
genera <strong>un</strong>a nuova versione del libro così come varie mo<strong>di</strong>fiche apportate tutte<br />
all’interno della stessa sessione. Questo comportamento equivale a quello che<br />
si avrebbe se il <strong>modello</strong> ignorasse gli aspetti strutturali e tutti i paragrafi<br />
del libro fossero memorizzati all’interno <strong>di</strong> <strong>un</strong> <strong>un</strong>ico file. Il versioning degli<br />
aspetti strutturali che si basa sulla propagazione delle mo<strong>di</strong>fiche si comporta<br />
come se fosse in uso <strong>un</strong>a gestione della struttura molto più primitiva (quin<strong>di</strong><br />
semplice ed imme<strong>di</strong>ata da comprendere).<br />
Versioning <strong>di</strong> più documenti legati fra loro<br />
D1 D1 D1<br />
C<br />
C<br />
L<br />
N<br />
C L<br />
N<br />
D3 D3 C<br />
D3<br />
C<br />
N<br />
N N<br />
D2 D2 C<br />
D2<br />
C<br />
L<br />
N N<br />
N<br />
L<br />
N<br />
C L<br />
L<br />
N N<br />
N<br />
N<br />
N<br />
N<br />
L<br />
C<br />
N<br />
C<br />
C<br />
N N<br />
Figura 2.7: La mo<strong>di</strong>fica <strong>di</strong> <strong>un</strong> link genera la nascita <strong>di</strong> <strong>un</strong>a nuova versione<br />
del documento.<br />
L<br />
N<br />
L<br />
N<br />
C<br />
N<br />
42
Versioning a supporto della collaborazione Unified Extensional Versioning Model<br />
In questo esempio viene considerato il caso <strong>di</strong> tre documenti legati fra<br />
loro, come mostrato in figura 2.7. Eventuali mo<strong>di</strong>fiche a D2 e D3 generano<br />
nuove versioni <strong>di</strong> essi, ma non si ripercuotono, per propagazione, a D1. Nella<br />
sezione centrale della figura viene mostrata la situazione dopo <strong>un</strong>a sessione<br />
<strong>di</strong> mo<strong>di</strong>fica sul documento D2 e <strong>un</strong>a sul documento D3. La sezione <strong>di</strong> destra<br />
mostra lo stato dopo <strong>un</strong>’altra sessione su D2 e <strong>un</strong>a su D1 che è risultata<br />
necessaria per poter riferire le ultime versioni degli altri due documenti. Occorre<br />
notare che è l’utente a decidere <strong>di</strong> effettuare tale aggiornamento su D1:<br />
avrebbe potuto decidere <strong>di</strong> non intervenire o <strong>di</strong> intervenire collegando <strong>un</strong>a<br />
qual<strong>un</strong>que altra versione <strong>di</strong> tali documenti <strong>di</strong>versa dall’ultima. La struttura<br />
in questo caso è <strong>un</strong> piccolo grafo, ma, applicando gli stessi meccanismi, è possibile<br />
utilizzare i link per creare DAG più complessi. La figura 2.7 potrebbe<br />
riferirsi ad <strong>un</strong> software in fase <strong>di</strong> sviluppo nel quale i sorgenti <strong>di</strong>pendono l’<strong>un</strong>o<br />
dall’altro come raffigurato in figura 2.5.<br />
2.4.2 Conclusioni<br />
In questo paragrafo vengono <strong>di</strong>scusse alc<strong>un</strong>e conseguenze legate all’uso<br />
del <strong>modello</strong> UEVM ed effettuati alc<strong>un</strong>i confronti con il <strong>modello</strong> intensionale.<br />
UEVM dal p<strong>un</strong>to <strong>di</strong> vista dell’utente<br />
Dal p<strong>un</strong>to <strong>di</strong> vista dell’utente UEVM <strong>un</strong>ifica i concetti relativi alla gestione<br />
delle versioni delle entità atomiche con quelle delle configurazioni. L’utente<br />
ha la possibilità <strong>di</strong> identificare, ispezionare, comparare e ragionare sulle<br />
proprietà delle configurazioni sia in termini <strong>di</strong> contenuti che strutturali.<br />
Il versioning intensionale, in confronto, è molto più complesso da comprendere.<br />
Infatti, per poter estrarre le configurazioni, l’utente è obbligato a<br />
capire il meccanismo delle regole e ad imparare <strong>un</strong> determinato linguaggio<br />
necessario alla loro descrizione.<br />
Gestione dell’esplosione combinatoria<br />
L’esplosione combinatoria del numero possibile delle configurazioni è <strong>un</strong><br />
problema fondamentale che ogni <strong>modello</strong> si trova a dover risolvere. In riferimento<br />
all’esempio, molto semplice, mostrato in figura 2.7 nel documento D3<br />
si hanno 2 3 = 8 possibili configurazioni ottenibili permutando le varie versioni<br />
dei no<strong>di</strong> presenti. In realtà solo 3 <strong>di</strong> queste sono state create ed hanno<br />
43
Versioning a supporto della collaborazione WebDAV<br />
senso per l’utente. Dal p<strong>un</strong>to <strong>di</strong> vista dei link esterni esistono 3 versioni del<br />
documento D2 e 2 versioni <strong>di</strong> D3 per <strong>un</strong> totale <strong>di</strong> 6 possibili combinazioni,<br />
ma, anche in questo caso, non tutte sono necessarie. Il <strong>modello</strong> UEVM riesce<br />
a minimizzare il problema creando esplicitamente solo le permutazioni<br />
necessarie.<br />
2.5 WebDAV<br />
World Wide Web Distributed Authoring and Versioning (WebDAV) fornisce<br />
le specifiche per <strong>un</strong> sistema <strong>di</strong> authoring collaborativo asincrono basato<br />
sull’utilizzo <strong>di</strong> Internet [WCJRg03]. WebDAV estende il protocollo Http,<br />
garantendo l’interoperabilità attraverso <strong>un</strong>’interfaccia com<strong>un</strong>e per l’accesso<br />
ai dati. L’obiettivo <strong>di</strong> WebDAV è <strong>di</strong> consentire l’elaborazione delle risorse<br />
attraverso il Web, come se fosse <strong>un</strong> file system.<br />
Importanti software house come ad esempio Microsoft, Netscape, Xerox,<br />
IBM e Novell hanno contribuito allo sviluppo <strong>di</strong> WebDAV. Attualmente<br />
esistono <strong>di</strong>verse soluzioni commerciali ed open source che lo implementano,<br />
ad esempio Sharepoint Portal Server (Microsoft), Netware 6 (Novell), Zope,<br />
Moddav. La tipologia dei client è molto varia, possono essere integrati in<br />
com<strong>un</strong>i browser web o essere client de<strong>di</strong>cati, con o senza interfaccia grafica.<br />
Gli sviluppatori <strong>di</strong> WebDAV (Internet Engineering Task Force) hanno<br />
stabilito le seguenti sei estensioni al protocollo Http.<br />
Version Management. Permette il salvataggio delle revisioni effettuate<br />
sui documenti e la collaborazione <strong>di</strong> più utenti nella stesura <strong>di</strong> questi.<br />
Advance Collections. Le collection forniscono <strong>un</strong> meccanismo per l’organizzazione<br />
gerarchica delle risorse. Una collection è <strong>un</strong>a lista <strong>di</strong> URI. Il ruolo<br />
è simile a quello delle <strong>di</strong>rectory <strong>di</strong> <strong>un</strong> file system. Una risorsa può avere più<br />
URI e quin<strong>di</strong> appartenere a più collezioni. A loro volta le collezioni possono<br />
essere or<strong>di</strong>nate anche in<strong>di</strong>pendentemente dalla proprietà.<br />
Access Control. Controlla gli accessi ai documenti attraverso il principio<br />
dell’autenticazione. Le applicazioni WebDAV devono supportare Http Digest<br />
Authentication, appartenente alle specifiche del protocollo Http 1.1.<br />
44
Versioning a supporto della collaborazione Revision Control System (RCS)<br />
Overwrite Prevention. Le operazioni <strong>di</strong> scrittura, quando consentite,<br />
prevedono <strong>un</strong> meccanismo <strong>di</strong> lock dei documenti. Esistono due tipologie<br />
<strong>di</strong> blocco: exclusive write lock e shared write lock. Il primo consente la scrittura<br />
solo a colui che l’ha bloccata, mentre il secondo permette l’authoring<br />
multiutente. È anche presente <strong>un</strong> meccanismo <strong>di</strong> notifica del rilascio delle<br />
risorse verso gli utenti interessati.<br />
Properties. Ogni documento ha <strong>un</strong> insieme <strong>di</strong> informazioni correlate (metadati),<br />
come ad esempio autore, data <strong>di</strong> creazione, soggetto, eccetera. Tali<br />
informazioni sono rappresentate con coppie “”. Il nome è <strong>un</strong>a<br />
URI e il valore è co<strong>di</strong>ficato in XML. Le proprietà possono essere live o<br />
dead. Nel primo caso è il server a gestire la coerenza sintattica e semantica,<br />
mentre nel secondo è il client e il server si limita a registrare il valore delle<br />
proprietà parola per parola. In generale l’approccio <strong>di</strong> WebDAV è orientato<br />
alla memorizzazione e ricerca delle informazioni, piuttosto che alla loro<br />
semantica.<br />
Namespace Management. WebDAV offre la possibilità <strong>di</strong> copiare, spostare<br />
e ricevere la lista dei documenti nelle collection. La copia consente<br />
anche <strong>di</strong> cambiare i permessi associati alla risorsa. Il recupero delle informazioni<br />
può avvenire sia rispettando l’or<strong>di</strong>namento gerarchico delle collection<br />
sia applicando filtri <strong>di</strong> ricerca sulle proprietà.<br />
2.6 Revision Control System (RCS)<br />
RCS permette <strong>di</strong> gestire il versioning <strong>di</strong> file automatizzando le operazioni<br />
<strong>di</strong> salvataggio, recupero, registrazione (logging), identificazione e fusione<br />
delle varie revisioni. RCS è utile per documenti testuali che devono essere<br />
revisionati spesso come co<strong>di</strong>ce sorgente, documentazione, eccetera. Basa il<br />
proprio principio <strong>di</strong> f<strong>un</strong>zionamento sul <strong>modello</strong> checkout/checkin (sotto paragrafo<br />
2.2.1), è <strong>un</strong> sistema basato sullo stato ed utilizza il <strong>modello</strong> estensionale<br />
per il versioning dei singoli file (che, in questo caso, corrispondono alle entità<br />
atomiche, paragrafo 2.3).<br />
RCS fu introdotto da Walter Tichy (Purdue University) all’inizio degli<br />
anni ottanta come evoluzione <strong>di</strong> SCCS (Source Code Control System) migliorandone<br />
l’interfaccia utente e il sistema <strong>di</strong> salvataggio delle versioni in<br />
45
Versioning a supporto della collaborazione Revision Control System (RCS)<br />
modo da rendere più efficiente l’accesso ai dati. RCS salva la versione più<br />
recente in modo integrale mentre per quelle precedenti memorizza soltanto<br />
le <strong>di</strong>fferenze (delta). RCS è parte del progetto GNU [Gnu03] e utilizza il<br />
pacchetto GNU Diffutils per la gestione delle <strong>di</strong>fferenze.<br />
Le f<strong>un</strong>zionalità che mette a <strong>di</strong>sposizione (descritte in [Gnu93]) non sono<br />
molte e risulta utile elencarle:<br />
1. permette <strong>di</strong> salvare e recuperare varie revisioni <strong>di</strong> documenti testuali.<br />
Le revisioni possono essere recuperate sulla base <strong>di</strong>: numero <strong>di</strong><br />
revisione, nome simbolico, data, autore e stato del documento;<br />
2. mantiene la completa storia dei cambiamenti. Ad ogni mo<strong>di</strong>fica salva<br />
l’autore e la data, inoltre impone all’autore <strong>di</strong> riportare <strong>un</strong>a descrizione<br />
della mo<strong>di</strong>fica utile per tracciare lo sviluppo del documento senza<br />
ricorrere a confronti espliciti fra le revisioni;<br />
3. evita i conflitti <strong>di</strong> accesso. Impe<strong>di</strong>sce a due o più sviluppatori <strong>di</strong> intervenire<br />
contemporaneamente sullo stesso documento evitando così che<br />
alc<strong>un</strong>e mo<strong>di</strong>fiche ne corrompano altre (strategia conservativa);<br />
4. modella attraverso <strong>un</strong> albero le relazioni fra le revisioni. Questo permette<br />
<strong>di</strong> creare vari branch a partire da <strong>un</strong>a <strong>di</strong> esse;<br />
5. permette <strong>di</strong> fondere revisioni (appartenenti a branch <strong>di</strong>versi) segnalando<br />
all’utente eventuali conflitti (che, quin<strong>di</strong>, possono essere risolti);<br />
6. permette <strong>di</strong> assegnare alla varie revisioni opport<strong>un</strong>i nomi simbolici<br />
(come: “stable”, “experimental”, etc.) con lo scopo <strong>di</strong> descrivere le<br />
configurazioni in modo semplice e <strong>di</strong>retto;<br />
7. minimizza lo spazio su <strong>di</strong>sco memorizzando solo le <strong>di</strong>fferenze fra le varie<br />
revisioni e ricorrendo ad opport<strong>un</strong>i algoritmi <strong>di</strong> compressione. È utile<br />
osservare che memorizzare le <strong>di</strong>fferenze per minimizzare lo spazio su<br />
<strong>di</strong>sco non fa <strong>di</strong> RCS <strong>un</strong> sistema basato sulle variazioni;<br />
Altrettanto utile risulta la descrizione del para<strong>di</strong>gma <strong>di</strong> interazione fra<br />
l’utente ed RCS [Kie94]. Per prima cosa occorre mettere in evidenza che<br />
l’utente opera su copie locali dei file e non <strong>di</strong>rettamente sul repository (copia<br />
principale dei dati contenente tutte le informazioni relative allo storico; l’accesso<br />
al repository è subor<strong>di</strong>nato al sistema <strong>di</strong> gestione delle versioni). La<br />
46
Versioning a supporto della collaborazione Revision Control System (RCS)<br />
fase <strong>di</strong> checkout serve per creare la copia locale mentre la fase <strong>di</strong> checkin (o<br />
commit) permette <strong>di</strong> aggiornare il repository (generando <strong>un</strong>a nuova revisione).<br />
La gestione degli accessi concorrenti avviene tramite il locking (blocco)<br />
dei file.<br />
Supponendo <strong>di</strong> voler iniziare a gestire le revisioni <strong>di</strong> <strong>un</strong> file, la prima cosa<br />
che occorre effettuare è il checkin del file, operazione che permette ad RCS <strong>di</strong><br />
copiare il documento nel repository e partire con la numerazione delle revisioni.<br />
Quando l’utente intende recuperare il file effettua il checkout. Il checkout,<br />
se non esplicitamente specificato, fornisce il documento all’utente per la sola<br />
lettura. In questo caso, se l’utente mo<strong>di</strong>ficasse la propria copia locale e cercasse<br />
<strong>di</strong> effettuare il checkin, otterrebbe <strong>un</strong> messaggio <strong>di</strong> errore. Per poter<br />
effettuare mo<strong>di</strong>fiche è necessario acquisire il file attraverso <strong>un</strong> checkout con<br />
lock che garantisce all’utente il <strong>di</strong>ritto esclusivo <strong>di</strong> mo<strong>di</strong>fica del file. RCS non<br />
permette, ovviamente, a due utenti <strong>di</strong>stinti <strong>di</strong> acquisire contemporaneamente<br />
il blocco sullo stesso file: il secondo utente viene avvertito con <strong>un</strong> messaggio<br />
che mostra il nome dell’utente che ha il lock in modo da poterlo contattare,<br />
se necessario.<br />
Fase 1<br />
Fase 2<br />
Fase 4<br />
File1 File2 File3<br />
r1.1 r1.1 r1.1<br />
r1.2 r1.2<br />
r1.3<br />
Fase 5<br />
Fase 3<br />
Configurazione con<br />
etichetta: stabile1.0<br />
Configurazione con<br />
etichetta: beta1<br />
Figura 2.8: Gestione delle configurazioni in RCS.<br />
47
Versioning a supporto della collaborazione Revision Control System (RCS)<br />
La gestione degli aspetti strutturali è a carico dell’utente (il <strong>modello</strong> adottato<br />
è intensionale) il quale, se intende mantenere le revisioni <strong>di</strong> <strong>un</strong> progetto<br />
costituito da più file, deve raggruppare le varie versioni appartenenti ad <strong>un</strong>a<br />
data configurazione etichettandole durante la fase <strong>di</strong> checkin (“tagging”, sotto<br />
paragrafo 2.2.1). Un esempio è utile per chiarire il concetto (figura 2.8). Si<br />
ipotizzi <strong>di</strong> dover operare con <strong>un</strong> progetto <strong>di</strong> sviluppo <strong>di</strong> <strong>un</strong> software costituito<br />
da tre file e che, al raggi<strong>un</strong>gimento della prima versione beta, lo sviluppatore<br />
decida <strong>di</strong> utilizzare RCS per tracciare le mo<strong>di</strong>fiche durante la fase <strong>di</strong> bug-fix 5 .<br />
Di seguito viene riportato l’andamento temporale degli eventi:<br />
• Fase 1: viene effettuato il checkin dei tre file etichettando la configurazione<br />
come “beta1”;<br />
• Fase 2: viene scoperto e corretto <strong>un</strong> bug su File1, il sistema, al checkin,<br />
associa il numero <strong>di</strong> versione 1.2 al file corretto;<br />
• Fase 3: viene scoperto e corretto <strong>un</strong> bug su File2, il sistema, al checkin,<br />
associa il numero <strong>di</strong> versione 1.2 al secondo file corretto;<br />
• Fase 4: viene scoperto e corretto <strong>un</strong> secondo bug su File1 : nasce in<br />
questo modo la versione 1.3 del primo file;<br />
• Fase 5: viene ritenuto che il programma sia pronto per il rilascio e<br />
l’ultima versione <strong>di</strong> ogni file viene etichettata come appartenente alla<br />
configurazione “stabile1.0”.<br />
Con il meccanismo delle etichette l’utente ha sempre la possibilità <strong>di</strong> accedere<br />
alle configurazioni marcate senza ambiguità (in questo esempio “stabile1.0” e<br />
“beta1”) anche se il sistema si limita a versionare i file singolarmente.<br />
RCS permette <strong>di</strong> effettuare il checkout sulla base della data <strong>di</strong> mo<strong>di</strong>fica<br />
dei file. Questa operazione permette <strong>di</strong> scegliere <strong>un</strong>a data ed estrarre tutti i<br />
file mo<strong>di</strong>ficati entro e non oltre tale data. In questo modo è possibile navigare<br />
manualmente nello storico delle configurazioni anche se queste non sono state<br />
precedentemente etichettate.<br />
Entrambi i meccanismi descritti, sia quello basato su tagging che quello<br />
basato su data, permettono <strong>di</strong> navigare nello storico delle configurazioni a<br />
patto che la struttura delle stesse non vari nel tempo. Questo aspetto è stato<br />
5 Fase <strong>di</strong> sviluppo nella quale non vengono aggi<strong>un</strong>te nuove f<strong>un</strong>zionalità al programma,<br />
ma vengono ricercati e corretti eventuali problemi nell’implementazione delle f<strong>un</strong>zionalità<br />
correnti.<br />
48
Versioning a supporto della collaborazione Concurrent Versions System (CVS)<br />
messo in evidenza descrivendo il <strong>modello</strong> basato su composizione, descritto<br />
nel sotto paragrafo 2.2.2.<br />
2.7 Concurrent Versions System (CVS)<br />
CVS è stato rilasciato da Dick Gr<strong>un</strong>e nel 1986, come collezione <strong>di</strong> script,<br />
con la finalità <strong>di</strong> superare i limiti ben noti <strong>di</strong> RCS, sistema dal quale deriva.<br />
Inizialmente CVS usava RCS per gestire le versioni dei singoli file<br />
(ve<strong>di</strong> [FB03]) e tutt’oggi continua ad usare il formato <strong>di</strong> salvataggio dei dati<br />
<strong>di</strong> RCS. Tre anni dopo Brian Berliner riscrisse CVS con il linguaggio <strong>di</strong><br />
programmazione C e successivamente Jeff Polk e Jim Kingdon aggi<strong>un</strong>sero<br />
ulteriori caratteristiche importanti.<br />
2.7.1 CVS, evoluzione <strong>di</strong> RCS<br />
CVS è a tutti gli effetti il successore <strong>di</strong> RCS da cui si <strong>di</strong>fferenzia per le<br />
seguenti caratteristiche:<br />
• ha la capacità <strong>di</strong> gestire le <strong>di</strong>rectory. Questo permette <strong>di</strong> operare su<br />
progetti complessi, così come su singoli file;<br />
• permette la mo<strong>di</strong>fica <strong>di</strong> file senza che questi debbano essere bloccati, a<br />
tutto vantaggio del lavoro <strong>di</strong> gruppo. Nel caso si verifichino situazioni<br />
<strong>di</strong> conflitto le rileva e ne permette la gestione (strategia ottimistica);<br />
• è capace <strong>di</strong> operare in ambienti <strong>di</strong>stribuiti permettendo agli sviluppatori<br />
<strong>di</strong> accedere al co<strong>di</strong>ce sorgente del progetto attraverso interconnessioni<br />
<strong>di</strong> rete.<br />
2.7.2 Concetti <strong>di</strong> base<br />
CVS richiede che ci sia <strong>un</strong>a certa coor<strong>di</strong>nazione fra gli sviluppatori 6 in<br />
quanto non permette (o meglio scoraggia visto che tale strategia è com<strong>un</strong>que<br />
applicabile) il blocco dei file, basando il proprio principio <strong>di</strong> f<strong>un</strong>zionamento<br />
sul para<strong>di</strong>gma copy-merge (sotto paragrafo 1.2.4, pagina 17) e sul <strong>modello</strong><br />
relativo alle transazioni estese nel tempo (sotto paragrafo 2.2.3).<br />
6 Per questo mette a <strong>di</strong>sposizione, oltre all’infrastruttura necessaria alla gestione<br />
delle versioni, alc<strong>un</strong>e f<strong>un</strong>zionalità tipiche dei sistemi groupware atte ad agevolare la<br />
cooperazione.<br />
49
Versioning a supporto della collaborazione Concurrent Versions System (CVS)<br />
Le fasi chiave che normalmente vengono percorse nell’uso <strong>di</strong> CVS sono le<br />
seguenti:<br />
1. lo sviluppatore crea <strong>un</strong>a propria copia <strong>di</strong> lavoro locale (contenente tutti<br />
i file relativi al progetto). Questa operazione è chiamata checkout;<br />
2. lo sviluppatore opera liberamente sulla propria copia <strong>di</strong> lavoro. Contemporaneamente<br />
altri sviluppatori possono fare lo stesso e, operando<br />
su copie <strong>di</strong> lavoro separate e quin<strong>di</strong> in<strong>di</strong>pendenti, senza interferire l’<strong>un</strong>o<br />
con l’altro;<br />
3. lo sviluppatore, <strong>un</strong>a volta completate le mo<strong>di</strong>fiche, effettua il commit<br />
(o checkin). Tale operazione prevede l’aggiornamento del repository,<br />
accompagnato da <strong>un</strong> messaggio utile per comprendere l’entità delle<br />
mo<strong>di</strong>fiche apportate;<br />
4. gli sviluppatori possono chiedere al server CVS se sono state apportate<br />
variazioni rispetto alla propria copia locale. In caso affermativo il sistema<br />
permette loro <strong>di</strong> ri-sincronizzare la propria copia con il repository<br />
in modo automatico.<br />
Si verifica <strong>un</strong> conflitto quando due sviluppatori apportano mo<strong>di</strong>fiche nello<br />
stesso p<strong>un</strong>to <strong>di</strong> <strong>un</strong> certo file ed entrambi intendono effettuare il commit:<br />
il primo <strong>di</strong> essi effettuerà l’aggiornamento del repository normalmente (il<br />
sistema non può sapere che <strong>un</strong> altro ha effettuato mo<strong>di</strong>fiche nello stesso p<strong>un</strong>to<br />
finché questo non glielo com<strong>un</strong>icherà) mentre il secondo verrà avvertito dal<br />
sistema che si è verificato il conflitto. In tal caso il sistema mostra l’entità<br />
del problema (mostrando le righe <strong>di</strong> co<strong>di</strong>ce interessate) mettendo il secondo<br />
sviluppatore nelle con<strong>di</strong>zioni <strong>di</strong> poterlo risolvere. Solo a questo p<strong>un</strong>to CVS<br />
permetterà al secondo sviluppatore <strong>di</strong> portare a termine il commit.<br />
Esiste <strong>un</strong>’altra situazione che può verificarsi come conseguenza dell’utilizzo<br />
del para<strong>di</strong>gma copy-merge. Tale scenario viene introdotto come <strong>un</strong>a<br />
rivisitazione dell’esempio descritto nel sotto paragrafo 2.2.3. A e B sono due<br />
sviluppatori, la sequenza temporale degli eventi è la seguente:<br />
1. A effettua il checkout;<br />
2. B effettua il checkout;<br />
3. A apporta delle mo<strong>di</strong>fiche ed effettua il commit;<br />
50
Versioning a supporto della collaborazione Concurrent Versions System (CVS)<br />
4. A apporta ulteriori mo<strong>di</strong>fiche ed effettua <strong>un</strong> secondo commit;<br />
5. B inizia a lavorare (è importante osservare che la sua copia non è<br />
aggiornata);<br />
6. B vuole effettuare il commit.<br />
Lo sviluppatore B può trovarsi <strong>di</strong> fronte a tre situazioni possibili:<br />
• ha operato su dei file che non sono stati mo<strong>di</strong>ficati anche da A. In tal<br />
caso il commit avviene con successo;<br />
• <strong>un</strong>o o più file mo<strong>di</strong>ficati (da B) sono stati mo<strong>di</strong>ficati anche da A, ma<br />
senza conflitti. In tal caso il sistema non permette il commit in<strong>di</strong>cando<br />
a B che, per poter procedere, deve prima effettuare <strong>un</strong> update. Questa<br />
operazione consiste nell’integrare le mo<strong>di</strong>fiche <strong>di</strong> A nella propria copia<br />
<strong>di</strong> lavoro e, in questo caso, il sistema è in grado <strong>di</strong> portare a termine<br />
l’operazione in autonomia. A questo p<strong>un</strong>to il sistema permette a B <strong>di</strong><br />
effettuare il commit;<br />
• è presente almeno <strong>un</strong> conflitto con le mo<strong>di</strong>fiche <strong>di</strong> A. In tal caso il<br />
sistema non permette il commit in<strong>di</strong>cando a B che, per poter procedere,<br />
deve effettuare <strong>un</strong> update che però, in questo caso, richiede l’intervento<br />
manuale per la risoluzione dei conflitti. Solo dopo tale risoluzione il<br />
sistema permette a B <strong>di</strong> effettuare il commit.<br />
Revisioni, branch e configurazioni<br />
Come in RCS ogni file del progetto ha <strong>un</strong> proprio numero <strong>di</strong> revisione,<br />
in<strong>di</strong>pendente dagli altri file. Se due file hanno numero <strong>di</strong> revisione <strong>di</strong>verso<br />
significa semplicemente che <strong>un</strong>o è stato mo<strong>di</strong>ficato (con relativa operazione<br />
<strong>di</strong> commit) più volte dell’altro.<br />
Il problema della gestione delle configurazioni viene affrontato come in<br />
RCS (paragrafo 2.6 e figura 2.8). Da <strong>un</strong> lato è possibile selezionare i file associati<br />
ad <strong>un</strong>a certa configurazione conoscendo l’istante temporale nel quale<br />
è stata creata, dall’altro assegnando esplicitamente delle etichette alle configurazioni<br />
<strong>di</strong> maggior rilievo (come le release pubbliche). Lo sviluppatore<br />
può quin<strong>di</strong> richiedere a CVS i file appartenenti ad <strong>un</strong>a configurazione in due<br />
mo<strong>di</strong> possibili:<br />
• richiedendo la configurazione creata nel giorno “dd/mm/yy”;<br />
51
Versioning a supporto della collaborazione Concurrent Versions System (CVS)<br />
• richiedendo la configurazione con nome “nome”.<br />
Entrambi gli approcci hanno vantaggi e svantaggi. Il primo permette <strong>di</strong><br />
accedere a tutte le configurazioni create (se due o più configurazioni sono<br />
state create lo stesso giorno il sistema mette a <strong>di</strong>sposizione la possibilità <strong>di</strong><br />
inserire anche l’ora) con lo svantaggio <strong>di</strong> non aver altri riferimenti eccetto la<br />
data. Il secondo permette l’accesso <strong>di</strong>retto alle configurazioni più importanti<br />
tramite etichette, che essendo testuali possono essere auto-esplicative, con lo<br />
svantaggio che queste devono essere applicate a priori dagli sviluppatori.<br />
In CVS con branch si intende <strong>un</strong>a linea <strong>di</strong> sviluppo parallela rispetto al<br />
ramo principale. Con CVS è possibile creare <strong>un</strong> numero arbitrario <strong>di</strong> branch,<br />
anche se, normalmente, è <strong>un</strong>’operazione poco consigliabile (la gestione <strong>di</strong><br />
molti rami <strong>di</strong> sviluppo paralleli è complessa). È possibile creare derivazioni<br />
a partire da branch esistenti (in tal caso il ramo dal quale il branch deriva si<br />
considera il principale).<br />
Un’operazione legata al branching è merge: consiste nell’integrare le mo<strong>di</strong>fiche<br />
apportate su <strong>un</strong> ramo in <strong>un</strong> altro. Questa operazione può essere del<br />
tutto automatica in caso <strong>di</strong> assenza <strong>di</strong> conflitti o assistita, nel caso in cui questi<br />
si verifichino, per la loro risoluzione. In riferimento all’esempio mostrato<br />
in figura 2.1 (a pagina 25) la nascita <strong>di</strong> <strong>un</strong> nuovo branch coincide con la creazione<br />
<strong>di</strong> <strong>un</strong>a nuova <strong>di</strong>ramazione, mentre l’operazione <strong>di</strong> merge corrisponde al<br />
concetto <strong>di</strong> convergenza.<br />
Creare branch può essere utile per vari motivi, <strong>un</strong> caso tipico è quello<br />
relativo alla risoluzione <strong>di</strong> bug. Uno scenario usuale è quello in cui tali bug<br />
vengono segnalati dagli utenti. È ragionevole pensare che questi abbiano a<br />
<strong>di</strong>sposizione l’ultima release pubblica che, nell’ipotesi in cui lo sviluppo del<br />
software continui ininterrotto, sarà antecedente all’ultima release presente nel<br />
repository. In tal caso alc<strong>un</strong>i sviluppatori creeranno <strong>un</strong> branch a partire dalla<br />
configurazione relativa alla release in questione in modo da poter operare, al<br />
fine <strong>di</strong> risolvere il problema, in autonomia dagli altri che stanno portando<br />
avanti lo sviluppo sul ramo principale. Non appena il bug è stato risolto è<br />
utile effettuare <strong>un</strong> merge delle mo<strong>di</strong>fiche sul ramo principale per eliminare il<br />
problema anche dal ramo <strong>di</strong> sviluppo.<br />
52
Versioning a supporto della collaborazione Subversion<br />
2.8 Subversion<br />
Subversion è <strong>un</strong> sistema <strong>di</strong> controllo delle versioni open source ed è in<br />
grado <strong>di</strong> gestire allo stesso modo file e <strong>di</strong>rectory [Lin05, CSFP04, Col05b].<br />
Permette l’accesso al repository tramite rete e, in generale, ha tutte le caratteristiche<br />
interessanti <strong>di</strong> CVS. Questo perché il software per la collaborazione<br />
“SourceCast”, prodotto e <strong>di</strong>stribuito da “CollabNet, Inc.”, inizialmente integrava<br />
CVS per la gestione delle versioni anche se non era ritenuto all’altezza<br />
della situazione per bug noti e alc<strong>un</strong>e caratteristiche mancanti. Pertanto,<br />
nel 2000, fu deciso <strong>di</strong> introdurre <strong>un</strong> nuovo sistema <strong>di</strong> gestione delle versioni<br />
ispirato a CVS (standard <strong>di</strong> fatto nel settore del software open source). Fu<br />
riscritto da zero e ha <strong>un</strong>a serie <strong>di</strong> caratteristiche <strong>di</strong> rilievo, descritte <strong>di</strong> seguito<br />
(ve<strong>di</strong> [Col05a]).<br />
Versioning delle <strong>di</strong>rectory. CVS traccia soltanto la storia dei file in<strong>di</strong>vidualmente,<br />
viceversa Subversion implementa <strong>un</strong>a sorta <strong>di</strong> file system virtuale<br />
versionato nel quale viene applicato il versioning all’intero albero ra<strong>di</strong>cato su<br />
<strong>un</strong>a <strong>di</strong>rectory.<br />
Storico esplicito delle configurazioni. CVS si limita al versioning del<br />
contenuto dei file e non è possibile tener traccia <strong>di</strong> operazioni come l’aggi<strong>un</strong>ta,<br />
lo spostamento o la cancellazione <strong>di</strong> alc<strong>un</strong>i <strong>di</strong> essi. Inoltre in CVS non è<br />
possibile rimuovere <strong>un</strong> file, crearne <strong>un</strong>o nuovo con lo stesso nome e far sì<br />
che questo abbia <strong>un</strong>o storico proprio: quello che succede è che il nuovo file<br />
ere<strong>di</strong>ta lo storico <strong>di</strong> quello vecchio. Con Subversion è possibile effettuare<br />
queste operazioni in modo del tutto trasparente con la garanzia che saranno<br />
versionate esattamente come le mo<strong>di</strong>fiche interne ai file.<br />
Commit atomici. L’aggiornamento del repository in Subversion avviene<br />
in modo atomico. Un’operazione <strong>di</strong> commit può andare a buon fine (e in tal<br />
caso il repository viene aggiornato sulla base <strong>di</strong> tutte le mo<strong>di</strong>fiche effettuate)<br />
oppure no. In questo secondo caso il repository non viene mo<strong>di</strong>ficato. In CVS<br />
questo non succede e può accadere che finiscano nel repository solo <strong>un</strong>a parte<br />
delle mo<strong>di</strong>fiche apportate con gli inconvenienti che questo può generare.<br />
53
Versioning a supporto della collaborazione Subversion<br />
Versioning dei metadati. È possibile associare ad ogni file e ad ogni<br />
<strong>di</strong>rectory <strong>un</strong> set arbitrario <strong>di</strong> metadati (nella forma chiave-valore). Tali<br />
metadati sono versionati da Subversion esattamente come i contenuti.<br />
Vari meto<strong>di</strong> per l’accesso al repository. Subversion permette l’accesso<br />
al repository in vari mo<strong>di</strong> <strong>di</strong>versi, <strong>un</strong>o dei più importanti è attraverso il protocollo<br />
WebDAV (paragrafo 2.5) con <strong>un</strong>a estensione per il server web Apache<br />
(ve<strong>di</strong> [Fou05c]). Questo porta vantaggi in termini <strong>di</strong> stabilità e interoperabilità<br />
per non parlare del fatto che molte caratteristiche come l’autenticazione<br />
lato server, la gestione delle autorizzazioni, la compressione dei dati in fase<br />
<strong>di</strong> trasmissione e tante altre sono supportate nativamente dalla struttura.<br />
Subversion mette a <strong>di</strong>sposizione anche <strong>un</strong> server e <strong>un</strong> protocollo proprietario<br />
più “leggeri” utilizzabili, se necessario, attraverso <strong>un</strong> t<strong>un</strong>nel SSH 7 . Infine è in<br />
grado <strong>di</strong> gestire il repository <strong>di</strong>rettamente su file system, approccio utile per<br />
versionare progetti in locale.<br />
Gestione dei dati <strong>un</strong>ificata. Subversion gestisce le <strong>di</strong>fferenze in formato<br />
binario e quin<strong>di</strong> opera efficientemente su file in formato testuale o non<br />
testuale.<br />
Gestione efficiente <strong>di</strong> Tag e Branch. Il tempo necessario per creare nuovi<br />
branch e tag non è proporzionale alla <strong>di</strong>mensione del progetto. Subversion<br />
effettua tali operazioni in <strong>un</strong> tempo costante.<br />
Manutenzione, sviluppo e integrazione. Subversion è stato progettato<br />
in modo estremamente modulare, è costituito da <strong>un</strong>a collezione <strong>di</strong> librerie C<br />
con<strong>di</strong>vise e da <strong>un</strong> insieme ben documentato <strong>di</strong> API (Application Program<br />
Interface). La manutenzione e l’aggi<strong>un</strong>ta <strong>di</strong> nuove f<strong>un</strong>zionalità sono operazioni<br />
effettuabili semplicemente ed inoltre è possibile integrare agevolmente<br />
Subversion all’interno <strong>di</strong> altre applicazioni.<br />
Portabilità. Subversion è stato scritto utilizzando APR (Apache Portable<br />
R<strong>un</strong>time project, ve<strong>di</strong> [Fou05b]). Questo significa che Subversion può operare<br />
su ogni sistema operativo nel quale è in grado <strong>di</strong> operare il server Http<br />
Apache: Linux, tutti i sistemi della famiglia BSD, Mac OS X, Windows,<br />
Netware ed altri.<br />
7 Per reperire dettagli su SSH, la shell sicura, <strong>un</strong> buon p<strong>un</strong>to <strong>di</strong> partenza è [Ope05].<br />
54
Versioning a supporto della collaborazione Subversion<br />
2.8.1 Concetti <strong>di</strong> base<br />
Il para<strong>di</strong>gma utilizzato per la gestione dell’accesso concorrente è il medesimo<br />
<strong>di</strong> CVS: copy-merge (descritto nel paragrafo 2.7). Il para<strong>di</strong>gma che<br />
prevede il lock delle risorse (descritto nel sotto paragrafo 1.2.4 a pagina 17)<br />
è sconveniente per vari motivi:<br />
• possono sorgere problemi <strong>di</strong> amministrazione. Si pensi al caso in cui <strong>un</strong><br />
utente blocchi <strong>un</strong> file e si <strong>di</strong>mentichi <strong>di</strong> averlo fatto. Un altro utente,<br />
interessato alla mo<strong>di</strong>fica <strong>di</strong> quel file, può perdere varie ore <strong>di</strong> lavoro per<br />
risolvere la questione;<br />
• si crea <strong>un</strong>a serializzazione del lavoro non necessaria. Se due utenti intendono<br />
mo<strong>di</strong>ficare parti <strong>di</strong>verse dello stesso file (senza conflitti per ipotesi)<br />
non possono farlo e l’<strong>un</strong>o deve attendere il termine della mo<strong>di</strong>fica<br />
dell’altro;<br />
• genera <strong>un</strong>a falsa sensazione <strong>di</strong> sicurezza. Siano A e B due file <strong>di</strong>pendenti<br />
l’<strong>un</strong>o dall’altro e S1 e S2 due sviluppatori. Si supponga che S1<br />
abbia acquisito il blocco su A e S2 su B. In questo caso S1 e S2<br />
potrebbero sentirsi autorizzati a mo<strong>di</strong>ficare i file come meglio credono,<br />
avendone acquisito il lock, ma le mo<strong>di</strong>fiche apportate potrebbero essere<br />
incompatibili dato che i due file <strong>di</strong>pendono l’<strong>un</strong>o dall’altro.<br />
Per quanto riguarda l’interazione con il sistema ed i concetti branch e merge<br />
è possibile, seppur con qualche <strong>di</strong>fferenza, fare riferimento al paragrafo 2.7<br />
nel quale tali argomenti vengono trattati per CVS in quanto le <strong>di</strong>fferenze, tra<br />
i due sistemi, non sono significative ai fini <strong>di</strong> questo lavoro.<br />
Numerazione esplicita delle configurazioni<br />
La numerazione delle versioni viene gestita a livello globale e non relativamente<br />
a singoli file. Questo vuol <strong>di</strong>re che le varie configurazioni, che nascono<br />
durante l’evoluzione del progetto, hanno <strong>un</strong> proprio numero <strong>di</strong> versione.<br />
Il meccanismo <strong>di</strong> assegnazione dei numeri <strong>di</strong> versione viene mostrato con<br />
<strong>un</strong> esempio in figura 2.9. È stato ipotizzato che il progetto venga versionato<br />
fin dall’inizio, come conseguenza la prima configurazione, contenente soltanto<br />
<strong>un</strong>a <strong>di</strong>rectory vuota, ha numero <strong>di</strong> versione 0. In seguito viene aggi<strong>un</strong>ta <strong>un</strong>a<br />
nuova <strong>di</strong>rectory contenente due file ed eseguito il commit. Il sistema assegna<br />
numero <strong>di</strong> versione 1 alla nuova configurazione. Lo sviluppo continua e, <strong>di</strong><br />
55
Versioning a supporto della collaborazione L’ambiente integrato COOP/Orm<br />
0 1 2 3<br />
Figura 2.9: Evoluzione delle versioni in Subversion.<br />
commit in commit, vengono create nuove versioni associate a configurazioni<br />
con file nuovi e/o mo<strong>di</strong>ficati.<br />
2.9 L’ambiente integrato COOP/Orm<br />
2.9.1 Ambienti <strong>di</strong> sviluppo integrati<br />
Un ambiente <strong>di</strong> sviluppo è <strong>un</strong> sistema dotato <strong>di</strong> tutti gli strumenti ritenuti<br />
utili per lo sviluppo <strong>di</strong> <strong>un</strong> progetto. Nella prima fase dello sviluppo del<br />
progetto vengono scelti, ed inseriti nell’ambiente <strong>di</strong> sviluppo, tutti gli strumenti<br />
che si prevedono <strong>di</strong> usare. La cosa importante è che tali strumenti non<br />
complichino il lavoro, ma al contrario, lo semplifichino. Per questo occorre<br />
che siano ben integrati gli <strong>un</strong>i con gli altri, cioè è necessario che:<br />
• tutti gli strumenti abbiano la medesima interfaccia grafica;<br />
• tutte le viste 8 si aggiornino automaticamente fra i vari strumenti all’interno<br />
dell’ambiente.<br />
8 Possibile rappresentazione per l’utente <strong>di</strong> <strong>un</strong>a certa entità (come il co<strong>di</strong>ce sorgente<br />
oppure lo stato <strong>di</strong> avanzamento della procedura <strong>di</strong> compilazione).<br />
56
Versioning a supporto della collaborazione L’ambiente integrato COOP/Orm<br />
Com<strong>un</strong>emente ci si riferisce agli ambienti <strong>di</strong> sviluppo integrati con l’acronimo<br />
IDE (dall’inglese Integrated Development Environments, ve<strong>di</strong> [IDE05]).<br />
Affinché tali caratteristiche siano sod<strong>di</strong>sfatte occorre che i vari strumenti<br />
siano in grado <strong>di</strong> com<strong>un</strong>icare fra sé. Tale com<strong>un</strong>icazione può avvenire<br />
sostanzialmente in tre mo<strong>di</strong>:<br />
• realizzando <strong>un</strong> sistema totalmente integrato ed omogeneo, con <strong>un</strong>a interfaccia<br />
utente <strong>un</strong>ica ed in grado <strong>di</strong> svolgere tutte le f<strong>un</strong>zioni necessarie.<br />
Un esempio <strong>di</strong> questo tipo è l’ambiente <strong>di</strong> sviluppo integrato Eclipse;<br />
la potenza <strong>di</strong> questo software consiste nel <strong>di</strong>sporre <strong>di</strong> <strong>un</strong> avanzato meccanismo<br />
<strong>di</strong> plugin che permette a chi<strong>un</strong>que <strong>di</strong> aggi<strong>un</strong>gere ed integrare<br />
f<strong>un</strong>zionalità al pacchetto base che nasce come piattaforma <strong>di</strong> sviluppo<br />
per il linguaggio Java. Esistono plugin che aggi<strong>un</strong>gono il supporto alla<br />
maggior parte dei linguaggi <strong>di</strong> programmazione ed il tutto è <strong>di</strong>sponibile<br />
gratuitamente per la maggior parte <strong>di</strong> sistemi operativi (a riguardo<br />
ve<strong>di</strong> [Fou05a]);<br />
• ricorrendo ad <strong>un</strong>a integrazione più “approssimativa” in cui ogni strumento<br />
è in<strong>di</strong>pendente dagli altri, ma con l’esistenza <strong>di</strong> meccanismi che<br />
permettano l’interscambio <strong>di</strong> informazioni senza complicazioni per l’utente.<br />
Un esempio da citare è il para<strong>di</strong>gma <strong>di</strong> lavoro tipico degli ambiente<br />
Unix-like che prevede l’esistenza <strong>di</strong> tanti tool <strong>di</strong>stinti per svolgere<br />
i vari compiti, ma tutti in grado <strong>di</strong> cooperare senza grosse <strong>di</strong>fficoltà in<br />
quanto basati sugli stessi standard ben definiti;<br />
• lasciando le cose al “caso” ed intervenendo manualmente, se necessario,<br />
con operazioni <strong>di</strong> importa/esporta fra i vari applicativi. Questa operazione<br />
potrebbe ad<strong>di</strong>rittura non essere possibile e in ogni caso è <strong>un</strong><br />
enorme collo <strong>di</strong> bottiglia nel processo <strong>di</strong> sviluppo.<br />
2.9.2 Da Orm a COOP/Orm<br />
COOP/Orm (descritto in [Ask02]) nasce con la finalità <strong>di</strong> aggi<strong>un</strong>gere f<strong>un</strong>zionalità<br />
tipiche degli ambienti groupware ad Orm che è ambiente <strong>di</strong> sviluppo<br />
integrato con le seguenti caratteristiche:<br />
• è interattivo;<br />
• è ottimizzato per linguaggi orientati agli oggetti;<br />
57
Versioning a supporto della collaborazione L’ambiente integrato COOP/Orm<br />
• è basato su compilazione, caricamento ed esecuzione incrementale;<br />
• usa finestre gerarchiche per la gestione del co<strong>di</strong>ce sorgente;<br />
• supporta il versioning e la gestione esplicita delle configurazioni del<br />
progetto (anche se orientati allo sviluppo da parte <strong>di</strong> <strong>un</strong> singolo).<br />
Giu<strong>di</strong>care la gestione delle versioni come <strong>un</strong> aspetto <strong>di</strong> primaria importanza<br />
nello sviluppo <strong>di</strong> software è stato considerato, nella fase <strong>di</strong> progettazione<br />
<strong>di</strong> COOP/Orm, <strong>un</strong> assioma. Per questo motivo è stato scelto <strong>di</strong> rendere<br />
la gestione delle versioni ben ra<strong>di</strong>cata nel sistema e ben visibile all’utente.<br />
Questa filosofia è in contrasto con quella seguita in altri sistemi nei quali<br />
il versioning viene considerato come <strong>un</strong>a f<strong>un</strong>zionalità interna al sistema e<br />
quanto più possibile da mascherare all’utente.<br />
La missione <strong>di</strong> COOP/Orm è quella <strong>di</strong> aggi<strong>un</strong>gere ad Orm:<br />
• la possibilità <strong>di</strong> mettere gli utenti in grado <strong>di</strong> cooperare (fornendo il<br />
massimo awareness <strong>di</strong> gruppo possibile, paragrafo 1.2 a pagina 1.2);<br />
• <strong>un</strong> sistema <strong>di</strong> gestione delle versioni evoluto, granulare, flessibile e<br />
adatto al lavoro <strong>di</strong> gruppo. L’approccio è estensionale (sotto paragrafo<br />
1.2.4) in quanto basato sul <strong>modello</strong> UEVM (paragrafo 2.4).<br />
Secondo i progettisti <strong>di</strong> COOP/Orm il loro sistema ha vantaggi e svantaggi<br />
rispetto ad architetture con integrazione minore.<br />
Vantaggi:<br />
• la gestione dell’evoluzione dei documenti (grafo delle versioni) è stata<br />
integrata nell’e<strong>di</strong>tor del sistema favorendo <strong>un</strong>a visione globale più chiara<br />
dell’avanzamento del progetto;<br />
• la gestione delle versioni è stata ideata per ottimizzare le operazioni <strong>di</strong><br />
confronto fra le stesse;<br />
• la finestra dell’e<strong>di</strong>tor si aggiorna automaticamente se altri utenti mo<strong>di</strong>ficano<br />
<strong>un</strong>a parte del documento in essa presente migliorando l’awareness<br />
dei componenti del gruppo.<br />
58
Versioning a supporto della collaborazione Sistemi <strong>di</strong> versioning peer-to-peer<br />
Svantaggi:<br />
• gli utenti sono obbligati ad usare gli e<strong>di</strong>tor messi a <strong>di</strong>sposizione dal<br />
sistema;<br />
• può essere complesso aggi<strong>un</strong>gere nuovi tool all’ambiente <strong>di</strong> lavoro.<br />
2.10 Sistemi <strong>di</strong> versioning peer-to-peer<br />
BitKeeper. È <strong>un</strong> sistema per la gestione del co<strong>di</strong>ce sorgente che permette<br />
agli sviluppatori <strong>di</strong> lavorare concorrentemente allo stesso progetto. Diversamente<br />
da altri sistemi nati con finalità simili è scalabile (si basa sostanzialmente<br />
su <strong>un</strong>a architettura peer-to-peer e non client/server), agevola il lavoro<br />
completamente <strong>di</strong>stribuito, permette agli utenti <strong>di</strong> lavorare anche se <strong>di</strong>sconnessi<br />
dalla rete, si basa sul para<strong>di</strong>gma change set (sotto paragrafo 2.2.4) ed<br />
è eccellente nella gestione delle operazioni <strong>di</strong> merge ([Bit05]).<br />
Un repository in BitKeeper è <strong>un</strong> insieme <strong>di</strong> file versionati ed ogni repository<br />
è <strong>un</strong>a entità auto-consistente, nel senso che contiene tutto quello che serve<br />
per lavorare. Ogni sviluppatore ha <strong>un</strong> proprio repository che viene creato<br />
da zero oppure tramite copia: in questo caso si parla <strong>di</strong> clone. Il repository<br />
clone che nasce a seguito <strong>di</strong> <strong>un</strong>a operazione <strong>di</strong> copia è legato al repository <strong>di</strong><br />
origine tramite <strong>un</strong>a relazione padre-figlio. Le mo<strong>di</strong>fiche vengono propagate<br />
fra repository attraverso la con<strong>di</strong>visione su file system, oppure tramite Rsh,<br />
Ssh, Smtp, Http oppure Bkd: il “BitKeeper network daemon”.<br />
Il para<strong>di</strong>gma <strong>di</strong> interazione fra l’utente e il proprio repository è simile a<br />
quello <strong>di</strong> altri sistemi <strong>di</strong> versioning: occorre effettuare checkout/checkin dei<br />
file, eccetera. Resta inteso che questa fase risulta semplificata dal fatto che<br />
l’accesso al repository è riservato ad <strong>un</strong> singolo utente. Per rendere le mo<strong>di</strong>fiche<br />
<strong>di</strong> dominio pubblico e per integrare le mo<strong>di</strong>fiche <strong>di</strong> altri nel proprio<br />
repository esistono delle primitive specifiche: push e pull. Queste operazioni<br />
vengono effettuate sulla base <strong>di</strong> cambiamenti logici (change set). Le eventuali<br />
semplificazioni riscontrate in fase <strong>di</strong> checkin vengono meno durante la con<strong>di</strong>visione<br />
dei change set con gli altri sviluppatori e pertanto il sistema mette a<br />
<strong>di</strong>sposizione vari meccanismi per rilevare e risolvere conflitti.<br />
A livello <strong>di</strong> astrazione degli host che ospitano BitKeeper, data la natura<br />
del protocollo peer-to-peer, non c’è <strong>di</strong>stinzione fra quelli che gestiscono<br />
repository padre e quelli che gestiscono repository figlio. Tale <strong>di</strong>fferenza contrad<strong>di</strong>stingue<br />
certamente il comportamento del nodo e può essere vista come<br />
59
Versioning a supporto della collaborazione Sistemi <strong>di</strong> versioning peer-to-peer<br />
conseguenza del fatto che lo stato interno è <strong>di</strong>verso. Tanto è vero che in<br />
BitKeeper le relazioni padre-figlio possono essere create (tramite l’operazione<br />
<strong>di</strong> copia) ed alterate (tramite specifiche primitive) a piacimento. Nel caso<br />
client/server la situazione è ben <strong>di</strong>versa in quanto gli host ospitano processi<br />
<strong>di</strong>versi (client e server app<strong>un</strong>to) e quin<strong>di</strong> risultano ben <strong>di</strong>stinguibili l’<strong>un</strong>o<br />
dall’altro e certamente non interscambiabili.<br />
Figli<br />
Padre<br />
Repository del<br />
responsabile<br />
della partizione<br />
Figli<br />
Figura 2.10: Topologie a stella ed albero.<br />
Padre<br />
Questo meccanismo permette <strong>di</strong> creare topologie <strong>di</strong> qual<strong>un</strong>que tipo anche<br />
se <strong>un</strong>a delle più utilizzate è quella a stella (a sinistra in figura 2.10) nella<br />
quale si ha <strong>un</strong> <strong>un</strong>ico repository padre (ra<strong>di</strong>ce) con vari repository figli. Questa<br />
topologia ricorda i sistemi centralizzati, ma, rispetto a questi ultimi, è<br />
più generale e flessibile: qualora risultasse necessario è possibile apportare<br />
mo<strong>di</strong>fiche <strong>di</strong> vario tipo in modo da adattarla alle nuove esigenze, senza <strong>di</strong>fficoltà.<br />
Questo approccio permette <strong>di</strong> far scalare la struttura al crescere della<br />
complessità del progetto trasformandola, ad esempio, in <strong>un</strong> albero (a destra<br />
in figura): il progetto ha <strong>un</strong> repository padre che viene <strong>di</strong>viso in sotto parti.<br />
Ogn<strong>un</strong>a <strong>di</strong> esse viene assegnata ad <strong>un</strong> responsabile, il cui repository <strong>di</strong>viene,<br />
a sua volta, ra<strong>di</strong>ce del sotto-albero <strong>di</strong> competenza. La procedura <strong>di</strong> sviluppo<br />
delle sotto parti può continuare con la topologia a stella: gli sviluppatori,<br />
che ovviamente operano nel loro repository, fanno capo al responsabile della<br />
sotto parte <strong>di</strong> loro competenza.<br />
60
Versioning a supporto della collaborazione Valutazioni comparative<br />
Git. È il sistema <strong>di</strong> gestione delle versioni utilizzato correntemente per la<br />
manutenzione del kernel Linux ed è stato introdotto specificatamente per<br />
questo scopo [Whe05]. Il sistema <strong>di</strong> gestione utilizzato in precedenza era<br />
BitKeeper ed è stato sostituito in quanto, la nuova licenza <strong>di</strong> rilascio applicata<br />
recentemente, non si adatta alle esigenze della com<strong>un</strong>ità <strong>di</strong> sviluppatori.<br />
Svk. È <strong>un</strong> sistema <strong>di</strong>stribuito che si appoggia a Subversion per la gestione<br />
delle versioni [lK05]. Diversamente da quest’ultimo prevede che ogni sviluppatore<br />
<strong>di</strong>sponga <strong>di</strong> <strong>un</strong>a copia personale (locale) del repository, chiamata<br />
depot. L’interazione avviene fra la copia <strong>di</strong> lavoro locale e il depot, fra il depot<br />
e <strong>un</strong> repository remoto. Questo passaggio interme<strong>di</strong>o permette <strong>di</strong> ricondurre<br />
il para<strong>di</strong>gma <strong>di</strong> interazione a quello <strong>di</strong> BitKeeper guadagnando, rispetto<br />
a Subversion, la capacità <strong>di</strong> operare con topologie più complesse rispetto a<br />
quella a stella, tipica del para<strong>di</strong>gma client/server.<br />
2.11 Valutazioni comparative<br />
I software descritti in questo capitolo non sono, ovviamente, gli <strong>un</strong>ici<br />
presenti nel panorama attuale dei sistemi <strong>di</strong> versioning. Sono stati scelti in<br />
quanto hanno permesso <strong>di</strong> introdurre e descrivere i vari approcci esistenti per<br />
la gestione delle versioni e <strong>di</strong> ripercorrere la storia che ha portato alla loro<br />
definizione.<br />
RCS ha affrontato la risoluzione del problema del versioning considerandolo<br />
<strong>un</strong> passo fondamentale. In seguito CVS ha agevolato il lavoro <strong>di</strong> gruppo<br />
fornendo <strong>un</strong>a semplice infrastruttura client/server per l’accesso da postazioni<br />
remote e sostituendo l’approccio lock/<strong>un</strong>lock con il copy/merge. Subversion<br />
cerca <strong>di</strong> superare alc<strong>un</strong>i limiti <strong>di</strong> CVS, ma senza stravolgerne la struttura.<br />
In certi contesti il para<strong>di</strong>gma client/server risulta inadeguato e i sistemi <strong>di</strong><br />
nuova generazione <strong>di</strong> gestione delle versioni (BitKeeper, Git, Svk, etc.) si<br />
muovono verso il para<strong>di</strong>gma peer-to-peer con il quale l’architettura a stella,<br />
tipica del client/server, è solo <strong>un</strong>a delle possibilità.<br />
I sistemi appena menzionati basano il loro principio <strong>di</strong> f<strong>un</strong>zionamento<br />
sul versioning dei file senza comprenderne il significato. Questo, da <strong>un</strong> lato,<br />
permette l’utilizzo su qual<strong>un</strong>que tipo <strong>di</strong> dato, dall’altro permette <strong>di</strong> asserire<br />
che, in contesti specifici, se i tool fossero in grado <strong>di</strong> comprendere i dati<br />
che stanno manipolando, potrebbe avere comportamenti più evoluti. Tale<br />
61
Versioning a supporto della collaborazione Valutazioni comparative<br />
ottimizzazione è realmente possibile dotando il sistema delle facoltà necessarie<br />
a comprendere la struttura dei dati che sta trattando ad <strong>un</strong> livello <strong>di</strong><br />
astrazione <strong>di</strong>verso del file o <strong>di</strong>rectory su file system. Questo è ben messo in<br />
evidenza dal <strong>modello</strong> UEVM. Inoltre, le problematiche tipiche del lavoro <strong>di</strong><br />
gruppo messe in relazione con i vantaggi percepiti dall’utente me<strong>di</strong>o nell’uso<br />
<strong>di</strong> sistemi integrati, stanno portando verso ambienti <strong>di</strong> lavoro complessi nei<br />
quali il controllo delle versioni è solo <strong>un</strong>a delle f<strong>un</strong>zionalità e molto spesso è<br />
ottimizzata per lo specifico campo applicativo (COOP/Orm).<br />
La seguente lista (non esaustiva) cita alc<strong>un</strong>i dei prodotti non menzionati<br />
in precedenza presenti nello scenario attuale dei sistemi <strong>di</strong> controllo delle<br />
versioni:<br />
• Aegis, [Mil05];<br />
• Bazaar-NG, [Ltd05a];<br />
• ClearCase, [RS05];<br />
• Co-Op, [Sof05];<br />
• Darcs, [Rou05];<br />
• GNU Arch, [Gnu05];<br />
• Monotone, [Mon05];<br />
• OpenCM, [SVLF05];<br />
• Perforce, [Inc05];<br />
• PureCM, [Ltd05b];<br />
• Superversion, [Rei05];<br />
• Vesta, [Com05];<br />
• Visual SourceSafe, [Mic05].<br />
62
Parte II<br />
Ambiente virtuale e <strong>modello</strong><br />
dell’informazione
Capitolo<br />
3<br />
Modello dell’ambiente virtuale<br />
Nel mondo reale <strong>un</strong>a qualsiasi istituzione è tra<strong>di</strong>zionalmente organizzata<br />
in modo gerarchico. Non è questo il luogo per illustrare ed analizzare<br />
gli aspetti sociali, storici, economici e politici che hanno portato la società<br />
moderna ad <strong>un</strong> simile or<strong>di</strong>namento. Ciò che è rilevante è il dato <strong>di</strong> fatto:<br />
la società è costituita da insiemi <strong>di</strong> organizzazioni o associazioni <strong>di</strong> persone,<br />
strutturate piramidalmente, in cui agiscono in<strong>di</strong>vidui con ruoli più o meno<br />
predeterminati (morali o professionali).<br />
Ogni in<strong>di</strong>viduo può essere inquadrato in vari contesti (ad esempio lavorativo,<br />
familiare, politico, sportivo, etc.) nei quali svolge le proprie mansioni<br />
o attitu<strong>di</strong>ni mettendosi in relazione con gli altri. A sua volta ogni contesto<br />
è inquadrato in <strong>un</strong> ambiente più globale, che generalmente ne è autoritativo.<br />
Non è poi <strong>un</strong>a rarità che organizzazioni paritarie o in<strong>di</strong>pendenti ne controllino<br />
altre o si controllino a vicenda, stabilendo delle relazioni trasversali.<br />
Nella progettazione <strong>di</strong> <strong>un</strong> ambiente collaborativo risulta naturale informatizzare<br />
il sistema per simulare, nel modo più coerente possibile, queste<br />
relazioni. Un ambiente virtuale consentirà <strong>di</strong> semplificare lo svolgimento delle<br />
attività degli utenti, facilitare l’uso <strong>di</strong> strumenti e risorse a valore aggi<strong>un</strong>to.<br />
Infine tanto maggiore risulta la corrispondenza fra ambiente virtuale e reale<br />
quanto minore sarà la <strong>di</strong>fficoltà degli utenti a comprendere ed utilizzare il<br />
sistema.
Modello dell’ambiente virtuale Rappresentazione dell’ambiente<br />
Proprio partendo dalla prospettiva dell’utente si cercherà <strong>di</strong> trasporre<br />
in termini <strong>di</strong> ICT (Information Comm<strong>un</strong>ication Technology) la percezione<br />
del mondo circostante, con il vantaggio che la maggior parte delle attività<br />
potranno essere automatizzate.<br />
Nel presente capitolo da <strong>un</strong> lato si cercherà <strong>di</strong> identificare <strong>un</strong> insieme <strong>di</strong><br />
entità ed operazioni che simulano l’ambiente reale e dall’altro si introdurranno<br />
delle nuove operazioni a valore aggi<strong>un</strong>to.<br />
3.1 Rappresentazione dell’ambiente<br />
Il <strong>modello</strong> <strong>di</strong> figura 3.1 riassume graficamente la proiezione del mondo<br />
reale nel mondo virtuale, nel quale sono rappresentati gli attori e le risorse<br />
del sistema, che interagiscono tra loro e con l’ambiente reale. Internamente<br />
si in<strong>di</strong>viduano coloro che producono informazione, coloro che ne fruiscono e<br />
coloro che ne gestiscono e stabiliscono le politiche <strong>di</strong> accesso.<br />
• Producer: rappresenta i client o gli utenti che producono l’informazione.<br />
• Consumer: rappresenta i client o gli utenti che interagiscono con l’ambiente<br />
al fine <strong>di</strong> trovare ed ottenere le informazioni <strong>di</strong> interesse.<br />
• Management: coor<strong>di</strong>na consumatori, produttori <strong>di</strong> informazione e risorse<br />
presenti.<br />
Sebbene ciasc<strong>un</strong> ruolo, Producer, Consumer e Management, possa essere<br />
assegnato allo stesso in<strong>di</strong>viduo o sistema esterno, essi risultano singolarmente<br />
in<strong>di</strong>pendenti. Inoltre in base a come <strong>un</strong> utente o sistema si autentica<br />
nell’ambiente alc<strong>un</strong>e operazioni e comportamenti saranno permessi ed altri<br />
negati.<br />
3.1.1 Le entità<br />
L’ambiente è costituito da mon<strong>di</strong> (World) organizzati gerarchicamente.<br />
Ogni World può identificare <strong>un</strong> luogo o <strong>un</strong> Ente virtuale al quale corrisponde<br />
<strong>un</strong> luogo o Ente reale (ad esempio <strong>un</strong> ufficio, <strong>un</strong> reparto, <strong>un</strong>a stanza, etc.).<br />
Ciasc<strong>un</strong> World è in<strong>di</strong>rettamente abitato dagli utenti. La proiezione dell’utente<br />
nel World è in<strong>di</strong>cata col nome Avatar: <strong>un</strong>’entità capace <strong>di</strong> esporre<br />
<strong>un</strong> sottoinsieme delle proprietà e caratteristiche dell’utente. All’ingresso <strong>di</strong><br />
<strong>un</strong> utente nel luogo reale corrisponde l’ingresso dell’Avatar nel World.<br />
65
Modello dell’ambiente virtuale Rappresentazione dell’ambiente<br />
Virtual<br />
Environment<br />
Real Environment<br />
Resource / Entities<br />
Figura 3.1: Ruoli degli attori dell’ambiente virtuale.<br />
Gli Avatar sono organizzati in gruppi (Group), com<strong>un</strong>ità virtuali <strong>di</strong> in<strong>di</strong>vidui,<br />
accom<strong>un</strong>ati da <strong>un</strong> certo insieme <strong>di</strong> caratteristiche o finalità lavorative.<br />
All’interno <strong>di</strong> <strong>un</strong> World gli Avatar interagiscono attraverso la con<strong>di</strong>visione<br />
delle risorse (Stuff) qui localizzate. Gli Stuff sono documenti elettronici,<br />
capaci <strong>di</strong> incapsulare dati e <strong>di</strong> esporre <strong>un</strong>a serie <strong>di</strong> servizi. In generale possono<br />
essere sia entità statiche che <strong>di</strong>namiche, dotate <strong>di</strong> <strong>un</strong> comportamento legato<br />
non solo ai servizi, inerenti all’informazione che rappresentano, ma anche al<br />
proprio ciclo <strong>di</strong> vita.<br />
66
Modello dell’ambiente virtuale Rappresentazione dell’ambiente<br />
Avatar<br />
L’Avatar è l’entità logica che rappresenta l’utente nell’ambiente virtuale.<br />
Ad ogni utente possono essere associati più Avatar ciasc<strong>un</strong>o dei quali esprime<br />
<strong>un</strong> profilo in <strong>un</strong> contesto. In sostanza <strong>un</strong> Avatar è <strong>un</strong> agente <strong>di</strong> presentazione<br />
dell’utente, capace <strong>di</strong> effettuare o subire operazioni nel World per conto del<br />
suo titolare. Il compito dell’Avatar è <strong>di</strong> seguire le attività collaborative, anche<br />
nel caso in cui l’utente sia fisicamente assente dal sistema (off-line).<br />
Tutte le varie prospettive e sfaccettature, costituite dall’insieme degli Avatar,<br />
determinano l’utente nella sua globalità. Ogni Avatar esprime con<strong>di</strong>zioni<br />
sufficienti all’autenticazione in <strong>un</strong> particolare World o all’appartenenza ad <strong>un</strong><br />
Group. L’<strong>un</strong>ione <strong>di</strong> tutti i profili, in linea <strong>di</strong> principio, permetterebbe <strong>di</strong> ricostruire<br />
l’utente nella sua totalità. In questo modo si tiene in considerazione<br />
sia la legislazione sulla privacy 1 sia l’eventuale volontà dell’utente a rendere<br />
noti solo dei frammenti della sua identità.<br />
La scelta <strong>di</strong> rappresentare l’utente con più Avatar consente <strong>di</strong> simulare ciò<br />
che accade nel mondo reale, dove <strong>un</strong> in<strong>di</strong>viduo viene visto in modo <strong>di</strong>verso<br />
da <strong>di</strong>versi gruppi <strong>di</strong> persone e dal sistema. Infatti ciò accade com<strong>un</strong>emente<br />
quando lo stesso in<strong>di</strong>viduo fornisce parziali informazioni sulla propria identità<br />
ed interagisce in modo <strong>di</strong>verso con gli altri in relazione al contesto. Ad<br />
esempio il profilo esposto da <strong>un</strong>a persona in ambito lavorativo solitamente<br />
non è equivalente a quello in ambito familiare o com<strong>un</strong>que privato. L’utilizzo<br />
<strong>di</strong> più identità non è <strong>un</strong>a novità negli applicativi <strong>di</strong> rete, come chat e forum,<br />
dove il nome reale viene quasi sempre sostituito con <strong>un</strong> nickname o <strong>un</strong> alias.<br />
È opport<strong>un</strong>o osservare che la gestione contemporanea <strong>di</strong> più Avatar e<br />
quin<strong>di</strong> <strong>di</strong> più operazioni sarà possibile solamente se l’utente potrà agire<br />
contemporaneamente con Avatar <strong>di</strong>versi.<br />
Un requisito la cui rilevanza varia in base al contesto, ma che in ogni<br />
caso è importante sod<strong>di</strong>sfare, è certificare l’associazione fra <strong>un</strong>a persona e<br />
relativo Avatar, dato che sarà proprio l’Avatar ad avviare, <strong>di</strong>rettamente o<br />
in<strong>di</strong>rettamente, i proce<strong>di</strong>menti e quin<strong>di</strong> agire nell’ambiente virtuale per conto<br />
del titolare.<br />
1 Occorre garantire il rispetto dei principi <strong>di</strong> protezione dei dati personali. In Europa<br />
la regolamentazione è prevista dalla Convenzione del Consiglio d’Europa n. 108/1981.<br />
In particolare ogni stato membro dell’Unione adotta <strong>un</strong>a propria legislazione, ad esempio<br />
per l’Italia: legge n. 675 del 31/12/1996, per la Finlan<strong>di</strong>a: legge n. 523 del<br />
22/4/1999, per la Grecia: legge n. 2472 10/04/1997, per l’Inghilterra: “The Data<br />
Protection Act” del 16/07/1998, per il Portogallo: legge n. 67 del 26/10/1998.<br />
(http://www.privacy.it/linkpriv1.html)<br />
67
Modello dell’ambiente virtuale Rappresentazione dell’ambiente<br />
Group<br />
I Group sono associazioni <strong>di</strong> utenti accom<strong>un</strong>ati da identici obiettivi o<br />
simili profili. Rappresentano <strong>un</strong>a com<strong>un</strong>ità collaborativa o <strong>un</strong>o status sociale<br />
e permettono <strong>di</strong> agire sulle risorse con<strong>di</strong>vise in modo <strong>un</strong>itario.<br />
Un Avatar, a cui è concessa l’iscrizione ad <strong>un</strong> gruppo, acquisisce i <strong>di</strong>ritti<br />
e i doveri del gruppo. Attraverso la transitività dei permessi, gli Avatar<br />
ere<strong>di</strong>tano le caratteristiche com<strong>un</strong>i al gruppo.<br />
I Group sono organizzati gerarchicamente ed or<strong>di</strong>nati secondo <strong>un</strong>a relazione<br />
<strong>di</strong> contenimento. È possibile rappresentare graficamente la struttura<br />
con <strong>un</strong> albero, in cui i permessi associati ai vari no<strong>di</strong> (Group) crescono al<br />
crescere della profon<strong>di</strong>tà <strong>di</strong> penetrazione.<br />
I permessi dei sottogruppi (gruppi figlio) sono almeno gli stessi <strong>di</strong> quelli<br />
del gruppo che li contiene (gruppo padre). Un Avatar iscritto ad <strong>un</strong> gruppo<br />
ha almeno tutti i permessi <strong>di</strong> quel gruppo. Ovviamente <strong>un</strong> Avatar iscritto<br />
ad <strong>un</strong> gruppo figlio risulta iscritto anche al gruppo padre.<br />
All’espulsione o alla cancellazione <strong>di</strong> <strong>un</strong> Avatar da <strong>un</strong> gruppo corrisponde<br />
<strong>un</strong>a <strong>di</strong>minuzione dei privilegi (permessi).<br />
Visivamente l’iscrizione e la cancellazione <strong>di</strong> <strong>un</strong> Avatar da <strong>un</strong> gruppo<br />
corrispondono a navigazioni in<strong>di</strong>rette dell’albero: si può pensare a queste<br />
due operazioni come, rispettivamente, ad azioni <strong>di</strong> <strong>di</strong>scesa o <strong>di</strong> salita nella<br />
gerarchia.<br />
Ogni Group contiene almeno <strong>un</strong> Avatar e teoricamente ve ne possono<br />
essere iscritti <strong>un</strong> numero indefinito. Potrebbero com<strong>un</strong>que essere previste<br />
eventuali restrizioni, come ad esempio sul numero massimo dei suoi affiliati<br />
o politiche spazio-temporali sull’ingresso e l’uscita, ad esempio basate sulla<br />
residenza <strong>di</strong>chiarata o l’età dell’utente.<br />
World<br />
L’entità World è la rappresentazione virtuale <strong>di</strong> <strong>un</strong> luogo reale. Un World<br />
può contenere altri World (sotto-mon<strong>di</strong>), in modo simile al caso dei Group, e<br />
risorse (Stuff). Ciò permette <strong>di</strong> creare <strong>un</strong>a gerarchia <strong>di</strong> contesti collaborativi<br />
in cui gli Avatar si incontrano e partecipano in attività sincrone o asincrone,<br />
inter-personali o private. Il World <strong>di</strong> più alto livello, che contiene tutti i<br />
World, prende il nome <strong>di</strong> Universe.<br />
Gli Avatar possono utilizzare questa struttura sia per rappresentare organizzazioni<br />
reali, sia luoghi convenzionali <strong>di</strong> ritrovo, intesi come spazi <strong>di</strong><br />
68
Modello dell’ambiente virtuale Rappresentazione dell’ambiente<br />
gi<strong>un</strong>zione tra World, propriamente abitati. Utenti, appartenenti a World <strong>di</strong>stinti,<br />
potrebbero avere com<strong>un</strong>i finalità progettuali per le quali è in<strong>di</strong>cata la<br />
creazione <strong>di</strong> <strong>un</strong> nuovo spazio logico <strong>di</strong> incontro. L’organizzazione degli spazi<br />
avviene per convenienza dell’utente o <strong>di</strong> gruppi <strong>di</strong> utenti.<br />
Solo utenti con opport<strong>un</strong>i profili sono ammessi ad entrare nei World.<br />
Inoltre ai World è possibile associare con<strong>di</strong>zioni intrinseche e strutturali, come<br />
ad esempio orari <strong>di</strong> accesso e numero massimo <strong>di</strong> utenti contemporaneamente<br />
presenti.<br />
Stuff<br />
Con Stuff sono in<strong>di</strong>cati i processi nell’ambiente collaborativo. In generale<br />
sono Stuff gli oggetti dell’ambiente reale come ad esempio <strong>di</strong>spositivi, sensori,<br />
libri, documenti o porzioni <strong>di</strong> essi.<br />
Uno Stuff espone <strong>un</strong>’insieme <strong>di</strong> operazioni ed ha <strong>un</strong> comportamento che<br />
è definito da eventi esterni ed interni e dallo stato ass<strong>un</strong>to.<br />
La raccolta, l’elaborazione e la presentazione delle informazioni sono i<br />
principali compiti <strong>di</strong> alto livello che <strong>un</strong>o Stuff deve assolvere. Gli Stuff non<br />
solo sono oggetto <strong>di</strong> <strong>un</strong> insieme <strong>di</strong> azioni, ma sono anche soggetto <strong>di</strong> azioni<br />
verso l’Avatar. Internamente all’ambiente virtuale hanno l’onere <strong>di</strong> avviare<br />
in modo autonomo l’interazione con gli Avatar, senza che da parte dell’utente<br />
vi sia stata <strong>un</strong>a predeterminata soggettiva intenzione.<br />
Le caratteristiche dei documenti <strong>di</strong>pendono anche dal loro contenuto:<br />
pensiamo ad esempio ad <strong>un</strong> libro <strong>di</strong> narrativa che risulta non mo<strong>di</strong>ficabile,<br />
ma leggibile <strong>un</strong> numero indefinito <strong>di</strong> volte, oppure ad <strong>un</strong> documento <strong>di</strong><br />
identità che dopo essere creato, può essere mo<strong>di</strong>ficato solo attraverso <strong>un</strong>a<br />
procedura <strong>di</strong> rinnovo, oppure ancora ad <strong>un</strong> insieme <strong>di</strong> app<strong>un</strong>ti, sul quale non<br />
c’è limite in scritture e letture.<br />
Le informazioni nel documento trattate dall’Avatar sono filtrate dal documento<br />
stesso: <strong>un</strong>’interfaccia espone le f<strong>un</strong>zionalità che l’entità interna provvede<br />
ad eseguire. In <strong>un</strong>’ottica Object Oriented lo Stuff è assimilabile ad <strong>un</strong><br />
oggetto.<br />
Lo Stuff è per definizione <strong>un</strong>’entità creata dalla collaborazione <strong>di</strong> Avatar,<br />
soggetta ad operazioni da parte <strong>di</strong> coloro che ne detengono i <strong>di</strong>ritti ed è il<br />
risultato dell’aggregazione <strong>di</strong> informazioni correlate, ma in<strong>di</strong>pendenti.<br />
69
Modello dell’ambiente virtuale Il <strong>modello</strong> delle interazioni<br />
3.2 Il <strong>modello</strong> delle interazioni<br />
All’interno dell’ambiente virtuale l’interazione tra Avatar viene filtrata<br />
dagli Stuff. Tali risorse costituiscono i catalizzatori delle attività collaborative,<br />
in quanto oggetto e soggetto <strong>di</strong> elaborazione. Mentre World e Group<br />
assolvono i compiti <strong>di</strong> organizzare lo spazio, le risorse e gli utenti, gli Stuff<br />
rappresentano il mezzo attraverso cui veicolare e controllare l’informazione.<br />
Com<strong>un</strong>que i ragionamenti che seguono sono facilmente esten<strong>di</strong>bili anche alle<br />
entità World, Group ed Avatar.<br />
In figura 3.2 è in<strong>di</strong>cato il <strong>modello</strong> delle interazioni tra Avatar. Si <strong>di</strong>stinguono<br />
quattro tipologie <strong>di</strong> interazione:<br />
• <strong>un</strong>o a <strong>un</strong>o: l’informazione è generata da <strong>un</strong> Avatar che lavora autonomamente<br />
ed è in<strong>di</strong>rizzata o destinata ad <strong>un</strong> altro Avatar;<br />
• <strong>un</strong>o a molti: l’informazione è generata da <strong>un</strong> Avatar che lavora autonomamente<br />
ed è in<strong>di</strong>rizzata o destinata ad <strong>un</strong> Group, a cui può<br />
eventualmente appartenere;<br />
• molti a <strong>un</strong>o: l’informazione è generata da <strong>un</strong> Group in cui gli Avatar<br />
lavorano in collaborazione ed è destinata ad <strong>un</strong> certo Avatar;<br />
• molti a molti: l’informazione è generata da <strong>un</strong> Group in cui i vari<br />
Avatar lavorano in collaborazione ed è destinata ad <strong>un</strong> altro Group,<br />
che eventualmente può contenere il primo o esserne <strong>un</strong> sottoinsieme.<br />
L’attività <strong>di</strong> <strong>un</strong> Avatar è costituita da <strong>un</strong>a sequenza <strong>di</strong> operazioni finalizzate<br />
a coinvolgere <strong>un</strong> solo utente o <strong>un</strong> intero gruppo. Il compito <strong>di</strong> identificare<br />
i destinatari, e quin<strong>di</strong> avviare la <strong>di</strong>ffusione delle informazioni, non è totalmente<br />
affidato al produttore. Anche lo Stuff può avere <strong>un</strong> ruolo attivo. È<br />
bene ricordare che Avatar e Stuff sono entità dello stesso livello.<br />
Leggendo singolarmente i quattro casi <strong>di</strong> figura 3.2, da destra verso sinistra,<br />
si identificano due fasi: nella prima fase la risorsa subisce l’iniziativa<br />
dell’Avatar (o del Group) e nella seconda è prevista la consegna dei risultati<br />
elaborati ai destinatari.<br />
È facile osservare che esiste <strong>un</strong> <strong>di</strong>saccoppiamento degli Avatar per mezzo<br />
degli Stuff. La fase <strong>di</strong> produzione è quella più delicata in quanto coinvolge,<br />
a basso livello, operazioni <strong>di</strong> scrittura, in generale concorrenti, perciò è<br />
auspicabile che tra i Producer Avatar e gli Stuff si realizzi <strong>un</strong> forte accoppiamento<br />
e sincronismo. Ciò non è necessario nella fase <strong>di</strong> consumo in quanto<br />
70
Modello dell’ambiente virtuale Il <strong>modello</strong> delle interazioni<br />
Virtual Environment<br />
Consumer<br />
Avatar<br />
Target<br />
Group<br />
Consumer<br />
Avatar<br />
Target<br />
Group<br />
<strong>un</strong>icast<br />
multicast<br />
<strong>un</strong>icast<br />
multicast<br />
World<br />
World<br />
World<br />
World<br />
Stuff<br />
Stuff<br />
Stuff<br />
Stuff<br />
operation<br />
operation<br />
operation<br />
operation<br />
Figura 3.2: Il <strong>modello</strong> <strong>di</strong> interazione.<br />
Producer<br />
Avatar<br />
Producer<br />
Avatar<br />
Producer<br />
Group<br />
Producer<br />
Group<br />
71
Modello dell’ambiente virtuale Il <strong>modello</strong> delle interazioni<br />
coinvolge le sole operazioni <strong>di</strong> lettura (non <strong>di</strong>struttive). Il vantaggio consiste<br />
da <strong>un</strong>a parte nell’aver separato le fasi critiche da quelle non critiche e dall’altra<br />
nel consentire <strong>un</strong>’interazione asincrona tra produttore e consumatore<br />
nelle attività collaborative. L’awareness è com<strong>un</strong>que ottenibile introducendo<br />
<strong>un</strong> sistema <strong>di</strong> notifica dell’informazione, il quale può essere utilizzato per recuperare,<br />
in certa misura, il sincronismo (a meno dei tempi <strong>di</strong> latenza, che<br />
com<strong>un</strong>que esistono in <strong>un</strong> sistema <strong>di</strong>stribuito). La notifica può essere com<strong>un</strong>icata<br />
prontamente all’Avatar oppure avvenire al primo accesso alla risorsa.<br />
L’importante è che la consegna sia sempre e com<strong>un</strong>que garantita.<br />
Un’ulteriore osservazione riguarda l’impossibilità <strong>di</strong> stabilire a priori il<br />
periodo e la scala dei tempi con cui il produttore accede alla risorsa. L’architettura<br />
deve consentire sia attività perio<strong>di</strong>che che aperio<strong>di</strong>che, sia dal lato<br />
consumatore che produttore.<br />
3.2.1 Prima fase dell’interazione<br />
In primo luogo le entità devono essere in<strong>di</strong>rizzabili: se non avessero <strong>un</strong><br />
nome non sarebbero identificabili e ricercabili. Una volta che il Producer<br />
Avatar ha in<strong>di</strong>rizzato la risorsa può accedervi, sempre che ne abbia <strong>di</strong>ritto,<br />
con <strong>un</strong>a politica tra quelle consentite. L’authoring, soprattutto se concorrente,<br />
deve essere regolato e controllato con opport<strong>un</strong>i meccanismi, tali che<br />
le operazioni invocate non si sovrappongano in<strong>di</strong>sciplinatamente, portando<br />
l’informazione in <strong>un</strong>o stato inconsistente.<br />
Per questa fase si in<strong>di</strong>vidua la necessità <strong>di</strong> ricorrere ai seguenti sistemi <strong>di</strong>:<br />
• rappresentazione e gestione dell’informazione, al fine <strong>di</strong> minimizzare le<br />
attività manuali (workflow e comportamento);<br />
• nomi, al fine <strong>di</strong> in<strong>di</strong>rizzare concettualmente le entità;<br />
• regolazione e controllo dell’accesso concorrente (lock, versioning, atomicità<br />
delle operazioni).<br />
3.2.2 Seconda fase dell’interazione<br />
I Group giocano <strong>un</strong> ruolo fondamentale: consentono <strong>di</strong> in<strong>di</strong>viduare, nella<br />
totalità degli utenti, singoli in<strong>di</strong>vidui o gruppi secondo vari criteri. È possibile<br />
esprimere l’interesse all’informazione con l’operazione <strong>di</strong> sottoscrizione,<br />
oppure possono essere utilizzate delle espressioni logiche collegate alla risorsa.<br />
72
Modello dell’ambiente virtuale Il delivery dell’informazione<br />
Si può pensare <strong>di</strong> in<strong>di</strong>viduare i gruppi just-in-time interpretando delle proposizioni<br />
e applicando dei filtri sui contenuti dei profili oppure si può avere<br />
<strong>un</strong> elenco <strong>di</strong> destinatari (Group) già pronto.<br />
L’interazione Stuff−→Avatar è da 1 a N (<strong>un</strong>icast o multicast). L’identità<br />
dei destinatari è conoscibile con la prospettiva dell’Avatar produttore o con<br />
quella dello Stuff. Nel primo caso è lo stesso Avatar ad in<strong>di</strong>care chi usufruirà<br />
delle nuove informazioni, mentre nel secondo si assume che il Group, a cui<br />
appartiene la risorsa, sia implicitamente anche il Group destinatario.<br />
Ai sistemi precedentemente elencati si deve aggi<strong>un</strong>gere <strong>un</strong> meccanismo per<br />
la consegna dell’informazione. La modalità con cui avviene la notifica può<br />
essere utilizzata per stabilire la qualità del servizio (QoS) complessivamente<br />
erogato dallo Stuff. Ad esempio <strong>un</strong> in<strong>di</strong>ce è definibile come rapporto tra<br />
informazioni consegnate su esplicita richiesta dell’utente rispetto a quelle<br />
notificate preventivamente. Questo permetterebbe <strong>di</strong> valutare la bontà del<br />
servizio e sarebbe applicabile in contesti <strong>di</strong> front-office e back-office.<br />
3.3 Il delivery dell’informazione<br />
Le mo<strong>di</strong>fiche alle entità dell’ambiente virtuale possono essere estremamente<br />
<strong>di</strong>verse sia per effetto della loro tipologia che delle operazioni invocate.<br />
Ogni mo<strong>di</strong>fica deve essere resa nota almeno all’Avatar e al Group a cui appartiene,<br />
altrimenti potrebbe apparire inaspettata, degradando l’awareness<br />
del gruppo e quin<strong>di</strong> la collaborazione. Il messaggio per la consegna dell’informazione<br />
può essere definito in due mo<strong>di</strong>: inviando al destinatario l’intera risorsa<br />
mo<strong>di</strong>ficata (email-based), oppure inviando solo la notifica dell’avvenuto<br />
cambiamento, lasciando all’utente l’onere dell’accesso (web-based).<br />
La definizione dell’ambiente virtuale, abbinata ad <strong>un</strong> authoring fortemente<br />
popolato ed eterogeneo, induce a scartare il primo approccio per i seguenti<br />
principali motivi:<br />
• ha senso solo per entità <strong>di</strong> tipo Stuff;<br />
• la quantità <strong>di</strong> informazione inviata potrebbe non essere proporzionata<br />
all’entità delle mo<strong>di</strong>fiche;<br />
• l’imperizia o le <strong>di</strong>menticanze dell’utente causano effetti collaterali in<br />
cascata.<br />
73
Modello dell’ambiente virtuale Il delivery dell’informazione<br />
L’ultimo p<strong>un</strong>to richiede maggiore dettaglio. Si ricorda che anche agli<br />
Avatar è consentito in<strong>di</strong>care il destinatario dell’informazione e che agisce per<br />
conto del suo utente. L’utente potrebbe inavvertitamente ripetere l’invio <strong>di</strong><br />
messaggi identici, inviare messaggi in ritardo rispetto alla scala dei tempi<br />
lavorativi, i messaggi spe<strong>di</strong>ti potrebbero contenere l’allegato non corretto o<br />
non contenerlo affatto. Tutto ciò degrada l’awareness del gruppo e quin<strong>di</strong> la<br />
collaborazione. Nel caso migliore fa crescere il numero <strong>di</strong> repliche o <strong>di</strong> copie<br />
dello Stuff che non solo penalizzano l’eventuale controllo delle versioni (aumentano<br />
le <strong>di</strong>ramazioni), ma abbassano globalmente il livello <strong>di</strong> automazione<br />
dell’informazione.<br />
Si parta dal principio che tutte le entità esistono nell’ambiente virtuale<br />
e che sono qui identificabili, ricercabili ed ottenibili. Supponendo che <strong>un</strong><br />
utente User B abbia identificato ed ottenuto l’accesso in scrittura, tramite il<br />
rispettivo Avatar, ad <strong>un</strong>o Stuff C e che l’evento debba essere notificato ad <strong>un</strong><br />
utente User A con <strong>un</strong>a certa priorità (figura 3.3).<br />
Discesa lato User B. La mo<strong>di</strong>fica allo Stuff avviene con <strong>un</strong> forte accoppiamento,<br />
in quanto l’attività, dall’inizio alla fine, avviene all’interno <strong>di</strong> <strong>un</strong>a sessione.<br />
L’Avatar B prepara l’operazione, i parametri ed i metadati (ad esempio<br />
Avatar destinatario dell’evento, priorità dell’evento, nome dello Stuff, ricevuta<br />
<strong>di</strong> ritorno etc.). Il tutto viene passato ad <strong>un</strong>’entità che opera ad <strong>un</strong> livello<br />
<strong>di</strong> astrazione più basso e che si preoccupa <strong>di</strong> imbustarlo in <strong>un</strong> messaggio<br />
(marshalling) in<strong>di</strong>rizzato allo Stuff. Quin<strong>di</strong> viene consegnato al sottosistema<br />
che si occupa del trasporto dell’informazione che provvede a recapitarlo al<br />
corrispettivo livello <strong>di</strong> trasporto del lato Stuff.<br />
Salita lato Stuff C. Il livello trasporto della destinazione estrae il corpo<br />
del messaggio e lo cede al livello soprastante. Quest’ultimo in particolare<br />
si occupa <strong>di</strong> in<strong>di</strong>viduare l’operazione da applicare allo Stuff (<strong>un</strong>marshalling).<br />
Sullo Stuff C avvengono le mo<strong>di</strong>fiche e l’interpretazione coerente dei metadati.<br />
Discesa lato Stuff C. Lo Stuff registra le mo<strong>di</strong>fiche e deve informare<br />
l’Avatar A dell’evento, perciò prepara l’informativa sfruttando i metadati e<br />
i dati relativi al tipo <strong>di</strong> operazione. L’informativa è passata al sottostante<br />
servizio <strong>di</strong> notifica (Notification Service X) che lo imbusta in <strong>un</strong> messaggio,<br />
in<strong>di</strong>cando nell’intestazione chi e come dovrà riceverlo. Grazie al livello tra-<br />
74
Modello dell’ambiente virtuale Il delivery dell’informazione<br />
push<br />
World<br />
event<br />
User A User B<br />
Avatar A<br />
Notification<br />
Service X<br />
Transport<br />
pull<br />
Notify<br />
changes<br />
Notification<br />
Service X<br />
Transport<br />
Stuff C<br />
<strong>un</strong>marshalling<br />
Transport<br />
Figura 3.3: La notifica delle mo<strong>di</strong>fiche.<br />
mo<strong>di</strong>fy<br />
operation<br />
+<br />
metadata<br />
Avatar B<br />
marshalling<br />
Transport<br />
sporto, arriva al lato dell’User B. La notifica verso il lato dell’User A avviene<br />
con <strong>un</strong> debole grado <strong>di</strong> accoppiamento.<br />
Salita lato User A. Il Notification Service Y riceve il messaggio dal sottostante<br />
livello trasporto. A questo p<strong>un</strong>to si possono verificare due modalità<br />
<strong>di</strong> interazione, mutuamente esclusive, <strong>di</strong>pendenti dalla priorità in origine<br />
assegnata dall’User A o dallo Stuff C:<br />
• il messaggio rimane memorizzato nel Notification Service Y in attesa <strong>di</strong><br />
75
Modello dell’ambiente virtuale Il delivery dell’informazione<br />
essere prelevato dall’Avatar A su richiesta dell’User A (pull);<br />
• l’informativa viene imme<strong>di</strong>atamente passata all’Avatar A e quin<strong>di</strong> fornita<br />
all’User A (push).<br />
Se lo Stuff C avesse richiesto la ricevuta <strong>di</strong> ritorno all’Avatar A, quest’ultimo<br />
sarebbe stato invitato o obbligato a generare <strong>un</strong> messaggio <strong>di</strong> risposta. Il<br />
percorso è esattamente inverso al precedente fino allo Stuff, solo che questo<br />
verrà sollecitato in modalità push. Lo Stuff registra l’avvenuta consegna e, se<br />
l’iniziativa è partita dall’Avatar B, provvede a notificarla con <strong>un</strong> meccanismo<br />
del tutto analogo a quello precedentemente illustrato.<br />
Il meccanismo è facilmente generalizzabile e scalabile nel caso in cui il<br />
destinatario sia <strong>un</strong> Group: a fronte <strong>di</strong> <strong>un</strong>a mo<strong>di</strong>fica basta che lo Stuff generi<br />
<strong>un</strong>’informativa destinata a tutti i membri del gruppo. Il Notification Service<br />
provvede ad inviare tanti messaggi quanti sono i destinatari.<br />
76
Capitolo<br />
4<br />
Modello dell’informazione<br />
<strong>versionata</strong> D3IM<br />
Lo scopo primario <strong>di</strong> <strong>un</strong> <strong>modello</strong> dell’informazione (Information model,<br />
IM ) è delineare le entità informative a livello concettuale, in<strong>di</strong>pendentemente<br />
da specifiche implementazioni o dai protocolli utilizzati per trasportare i<br />
dati. Un IM deve celare tutti i dettagli implementativi e <strong>di</strong> com<strong>un</strong>icazione<br />
al fine <strong>di</strong> rendere la progettazione la più chiara possibile. L’altro importante<br />
compito dell’IM è modellare le relazioni tra le entità attraverso <strong>un</strong> linguaggio<br />
naturale o <strong>un</strong> linguaggio formale oppure con <strong>un</strong> linguaggio strutturato semi<br />
formale [Pra03].<br />
Viceversa i modelli per i dati (Data Model, DM ) sono definiti ad <strong>un</strong> livello<br />
più concreto ed includono molti dettagli con specifici costrutti. La principale<br />
conseguenza è che lo stesso IM può dare vita a più DM. In pratica però non<br />
è sempre possibile <strong>di</strong>stinguere <strong>un</strong>ivocamente <strong>un</strong> DM dal suo IM. Esiste <strong>un</strong>a<br />
“zona grigia”, dove IM e DM si sovrappongono parzialmente. In molti casi è<br />
veramente <strong>di</strong>fficile stabilire se le astrazioni appartengono all’<strong>un</strong>o o all’altro.<br />
In questo capitolo viene definito <strong>un</strong> Information Model. L’intenzione è<br />
quella <strong>di</strong> renderlo quanto più generico possibile in modo da permetterne l’utilizzo<br />
in vari contesti non necessariamente noti a priori. Per rendere più<br />
concreta tale definizione è utile ricorrere al concetto <strong>di</strong> documento che, rima-
Modello dell’informazione <strong>versionata</strong> D3IM<br />
nendo in <strong>un</strong> contesto molto generale, è possibile definire come <strong>un</strong>’entità che<br />
contiene <strong>un</strong>a serie <strong>di</strong> informazioni.<br />
L’elaborabilità <strong>di</strong> <strong>un</strong> documento assume particolare rilievo quando esso<br />
viene rappresentato all’interno <strong>di</strong> <strong>un</strong> calcolatore ed utilizzato come entità da<br />
trasmettere. Parafrasando Rain, McCue, Slein e Buckland [Inn04], <strong>un</strong>a definizione<br />
estesa e utile per gli argomenti trattati, è la seguente: <strong>un</strong> documento è<br />
la testimonianza <strong>di</strong> <strong>un</strong>a evidenza fisica o intellettuale, memorizzata e strutturata<br />
in <strong>un</strong>a qualsiasi forma materiale, capace <strong>di</strong> essere compresa dall’uomo,<br />
trattabile dalla macchina e com<strong>un</strong>icabile.<br />
Molto spesso quando si considerano più informazioni <strong>di</strong>stinte come <strong>un</strong>’<strong>un</strong>ica<br />
entità (raggruppate all’interno <strong>di</strong> <strong>un</strong> documento) il contenuto informativo<br />
della somma è maggiore della somma delle singole informazioni. Si evidenzia<br />
come l’informazione aggi<strong>un</strong>tiva sia data da correlazioni presenti fra le<br />
varie informazioni e permetta <strong>di</strong> caratterizzare il documento come <strong>un</strong>’entità<br />
strutturata.<br />
Nel caso in cui questo aspetto sia trascurabile si parla <strong>di</strong> informazione<br />
non strutturata che com<strong>un</strong>que può essere vista come <strong>un</strong> caso particolare <strong>di</strong><br />
quella strutturata.<br />
Data l’importanza della tracciabilità delle mo<strong>di</strong>fiche nei contesti nei quali<br />
è previsto che il <strong>modello</strong> proposto venga applicato, la gestione dell’evoluzione<br />
temporale delle informazioni (versioning) è integrata nel <strong>modello</strong> in modo<br />
nativo.<br />
Per rispondere a queste esigenze il <strong>modello</strong> <strong>di</strong> documento in esame, D3IM<br />
(Distributed Delocalized Document Information Model), è stato progettato in<br />
modo da potersi basare su UEVM, descritto nel paragrafo 2.4 (a pagina 33).<br />
Il documento deve essere dotato delle seguenti caratteristiche:<br />
• deve avere <strong>un</strong>a struttura a DAG nella quale siano ben <strong>di</strong>stinguibili e<br />
definiti come entità in<strong>di</strong>viduali i no<strong>di</strong> che la costituiscono;<br />
• devono esistere le seguenti tipologie <strong>di</strong> relazione fra no<strong>di</strong>: link <strong>di</strong> riferimento<br />
e link <strong>di</strong> composizione (terminologia ere<strong>di</strong>tata dal <strong>modello</strong><br />
UEVM 1 .<br />
1 È stato scelto, per convenzione, <strong>di</strong> utilizzare il termine aggregazione per intendere <strong>un</strong>a<br />
qual<strong>un</strong>que relazione fra no<strong>di</strong> (link <strong>di</strong> composizione o <strong>di</strong> riferimento). In questo modo il<br />
concetto <strong>di</strong> composizione è <strong>un</strong> caso particolare <strong>di</strong> quello <strong>di</strong> aggregazione, similmente alla<br />
terminologia utilizzata in UML [RJB99].<br />
78
Modello dell’informazione <strong>versionata</strong> D3IM Principi <strong>di</strong> strutturazione<br />
Le caratteristiche menzionate riguardano soltanto gli aspetti strutturali e<br />
legati al versioning delle informazioni, mentre quelle che seguono sono state<br />
aggi<strong>un</strong>te con la finalità <strong>di</strong> caratterizzare il documento anche sotto i seguenti<br />
p<strong>un</strong>ti <strong>di</strong> vista che riguardano:<br />
• la definizione a più alto livello del concetto <strong>di</strong> informazione;<br />
• l’introduzione del concetto <strong>di</strong> responsabilità associato all’informazione.<br />
4.1 Principi <strong>di</strong> strutturazione<br />
All’interno dei documenti con i quali si interagisce e si tratta quoti<strong>di</strong>anamente<br />
possono essere in<strong>di</strong>viduate alc<strong>un</strong>e categorie <strong>di</strong> informazioni che possono<br />
essere evidenziate analizzando il documento. Tali categorie risultano le<br />
seguenti:<br />
• contenuti: elementi esplicitamente fruibili dall’uomo e che sono <strong>di</strong>rettamente<br />
in<strong>di</strong>viduabili all’interno del documento. Rientrano in questa<br />
categoria i testi, le immagini, le date, i nomi, i contenuti multime<strong>di</strong>ali,<br />
eccetera;<br />
• relazioni: legami fra contenuti che possono essere <strong>di</strong> tipo esplicito o<br />
implicito. Un esempio <strong>di</strong> legame esplicito può essere il riferimento ad<br />
<strong>un</strong>a pagina o paragrafo <strong>di</strong> <strong>un</strong> libro, ad <strong>un</strong> articolo presente in <strong>un</strong>a legge,<br />
eccetera. Dualmente <strong>un</strong> legame implicito può essere quello esistente fra<br />
il titolo <strong>di</strong> <strong>un</strong> capitolo <strong>di</strong> <strong>un</strong> libro e il contenuto del capitolo stesso;<br />
• informazioni aggi<strong>un</strong>tive: ulteriori informazioni associate al documento<br />
e/o che possono essere date per scontate. Ad esempio l’autore <strong>di</strong> <strong>un</strong><br />
brano musicale oppure il fatto che i contenuti presenti nella prima pagina<br />
<strong>di</strong> <strong>un</strong> quoti<strong>di</strong>ano rappresentano <strong>un</strong> s<strong>un</strong>to delle notizie più importanti<br />
del giornale;<br />
• presentazione: informazioni necessarie per mostrare correttamente il<br />
documento all’utente. Rientra a pieno titolo in questa categoria l’aspetto<br />
grafico, ovvero la scelta dei caratteri, dei colori, dell’impaginazione,<br />
eccetera. Questa categoria <strong>di</strong> informazioni fornisce <strong>un</strong> valore aggi<strong>un</strong>to<br />
che in particolari casi è determinante per permettere la fruibilità delle<br />
informazioni contenute nel documento. A tal riguardo si pensi alle linee<br />
guida dettate nel contesto del web accessibile [TS06].<br />
79
Modello dell’informazione <strong>versionata</strong> D3IM Principi <strong>di</strong> strutturazione<br />
Queste categorie <strong>di</strong> informazioni sono state introdotte parlando <strong>di</strong> documento<br />
in senso astratto e/o nel senso convenzionale del termine. Nel momento<br />
in cui si intende co<strong>di</strong>ficare <strong>un</strong> documento per renderlo trattabile dalle<br />
macchine occorre formalizzare al meglio questi concetti al fine <strong>di</strong> poterli<br />
gestire efficacemente ed efficientemente da <strong>un</strong> p<strong>un</strong>to <strong>di</strong> vista informatico.<br />
A tale scopo si può ricorrere ad opport<strong>un</strong>i linguaggi <strong>di</strong> marcatura che<br />
permettono <strong>di</strong> contrassegnare e quin<strong>di</strong> valorizzare i vari elementi contenuti<br />
nel documento. In questo modo si riescono a co<strong>di</strong>ficare tutte le categorie<br />
<strong>di</strong> informazioni e in particolare a rappresentare, esplicitamente o implicitamente,<br />
le relazioni. Un esempio <strong>di</strong> relazione rappresentata esplicitamente è<br />
l’insieme dei link ipertestuali presenti nelle pagine web: il link è presente ed<br />
in<strong>di</strong>viduabile nel documento. Viceversa la modalità implicita si presenta in<br />
<strong>un</strong>o degli esempi menzionati precedentemente ovvero qualora si vada a contrassegnare<br />
il titolo <strong>di</strong> <strong>un</strong> capitolo come tale, in modo da evidenziarlo rispetto<br />
al testo presente nello stesso: non esiste <strong>un</strong>a relazione fra titolo e contenuto<br />
del capitolo esplicitamente in<strong>di</strong>viduabile all’interno del documento, ma tale<br />
marcatura permette <strong>di</strong> separare le due entità e considerarle, se necessario,<br />
come correlate.<br />
Da <strong>un</strong> p<strong>un</strong>to <strong>di</strong> vista informatico i documenti dotati <strong>di</strong> queste caratteristiche<br />
e co<strong>di</strong>ficati opport<strong>un</strong>amente vengono chiamati documenti strutturati.<br />
I vantaggi riscontrati trattando documenti strutturati sono molteplici in<br />
quanto gli aspetti strutturali, oltre a fornire <strong>un</strong> contenuto informativo ad<strong>di</strong>zionale<br />
rispetto al caso non strutturato, permettono <strong>di</strong> garantire anche <strong>un</strong><br />
maggior controllo dei contenuti.<br />
Inoltre tramite il concetto <strong>di</strong> riferimento ad altre informazioni è possibile<br />
realizzare vari documenti che, contenendo riferimenti alle medesime<br />
informazioni, <strong>di</strong> fatto le con<strong>di</strong>vidono.<br />
Le macchine, in questo modo, <strong>di</strong>ventano sistemi in grado <strong>di</strong> interpretare<br />
e comprendere 2 il contenuto informativo dei documenti e ciò permette <strong>di</strong><br />
sfruttarne agevolmente le potenzialità in termini <strong>di</strong> velocità elaborativa, <strong>di</strong><br />
memorizzazione e com<strong>un</strong>icazione per supportare efficientemente l’uomo nella<br />
loro trattazione.<br />
Quin<strong>di</strong> il lavoro dell’uomo risulta agevolato in quanto può essere velocizzato<br />
e facilitato nell’immissione, nella ricerca, nella consultazione delle<br />
informazioni.<br />
2 Si intende che, sulla base dei documenti co<strong>di</strong>ficati opport<strong>un</strong>amente, risulta possibile<br />
scrivere algoritmi in grado <strong>di</strong> elaborare le informazioni in modo efficiente.<br />
80
Modello dell’informazione <strong>versionata</strong> D3IM I no<strong>di</strong> informativi del documento<br />
4.1.1 Il concetto <strong>di</strong> responsabilità<br />
Un aspetto estremamente importante, in modo particolare se si trattano<br />
informazioni sensibili, è quello relativo al concetto <strong>di</strong> responsabilità sull’informazione.<br />
Il responsabile è colui il quale ha la consapevolezza <strong>di</strong> dover<br />
rispondere degli effetti che possono scaturire a seguito della <strong>di</strong>vulgazione<br />
dell’informazione. Il responsabile può essere <strong>un</strong>a persona fisica oppure<br />
giuri<strong>di</strong>ca.<br />
Prendendo ad esempio <strong>un</strong> giornale, l’autore <strong>di</strong> <strong>un</strong> articolo è responsabile <strong>di</strong><br />
ciò che vi ha scritto e il <strong>di</strong>rettore è anch’esso responsabile, in modo in<strong>di</strong>retto,<br />
in quanto ne autorizza la pubblicazione.<br />
Si osservi che a questo riguardo esistono normative, sia a livello italiano<br />
(legge 675/1996 [Ita96], decreto legislativo n.196 del 6 Giugno 2003 [Ita03],<br />
etc.) che internazionale, che regolamentano le modalità attraverso le quali<br />
devono essere trattati i dati sensibili. In questo contesto la legge prevede<br />
in modo formale l’in<strong>di</strong>viduazione <strong>di</strong> <strong>un</strong>o o più persone fisiche o giuri<strong>di</strong>che<br />
che hanno la responsabilità civile e penale del trattamento dei dati sensibili<br />
dell’interessato 3 secondo i termini <strong>di</strong> legge.<br />
4.2 I no<strong>di</strong> informativi del documento<br />
Il documento D3IM, essendo <strong>un</strong>’entità strutturata, è costituito da informazioni<br />
che ne rappresentano il contenuto (i veri e propri dati) e da informazioni<br />
che ne rappresentano la struttura (le relazioni fra i dati). Nel <strong>modello</strong><br />
introdotto le informazioni che rappresentano il contenuto sono dette informazioni<br />
atomiche mentre quelle che rappresentano gli aspetti strutturali sono<br />
dette informazioni primitive.<br />
L’informazione atomica è <strong>un</strong>a coppia“”: essendo il“valore”<br />
<strong>di</strong> qual<strong>un</strong>que natura e potendo associare più informazioni atomiche ad <strong>un</strong><br />
documento è possibile osservare che i documenti D3IM possono contenere <strong>un</strong><br />
qual<strong>un</strong>que insieme <strong>di</strong> informazioni eterogenee.<br />
L’informazione primitiva modella gli aspetti strutturali: introduce delle<br />
relazioni <strong>di</strong> tipo “genitore-figli” in cui essa è genitore e i figli sono informazioni<br />
atomiche o primitive. L’<strong>un</strong>ico vincolo esistente è che non devono nascere<br />
cicli nella struttura ovvero non deve esistere alc<strong>un</strong> cammino (sequenza <strong>di</strong> no-<br />
3 La legge 675/1996 [Ita96] definisce l’interessato come la persona fisica, la persona<br />
giuri<strong>di</strong>ca, l’ente o l’associazione cui si riferiscono i dati personali.<br />
81
Modello dell’informazione <strong>versionata</strong> D3IM I no<strong>di</strong> informativi del documento<br />
<strong>di</strong> ottenuta seguendo le relazioni “genitore-figlio”) che partendo da <strong>un</strong> nodo<br />
permetta <strong>di</strong> ritornare al nodo stesso. Si noti come questo fatto derivi implicitamente<br />
dall’aver definito la struttura tramite relazioni <strong>di</strong> parentela fra no<strong>di</strong>:<br />
dati due no<strong>di</strong> qual<strong>un</strong>que deve essere sempre possibile <strong>di</strong>stinguere l’antenato<br />
dal successore, operazione non effettuabile in caso <strong>di</strong> cicli.<br />
Come già anticipato il documento definito in questi termini assume <strong>un</strong>a<br />
struttura a DAG (grafo aciclico ed orientato) visibile in figura 4.1.a.<br />
Aver modellato il documento come DAG non preclude la possibilità <strong>di</strong><br />
presentarlo all’utente come albero 4 , figura 4.1.b. Questa rappresentazione<br />
può essere ottenuta applicando il seguente algoritmo:<br />
• si parte dal nodo <strong>di</strong> interesse nel DAG (A) e si inserisce nella ra<strong>di</strong>ce<br />
dell’albero;<br />
• ricorsivamente, per ogni nodo dell’albero, si inseriscono come figli i<br />
corrispondenti figli del nodo nel DAG.<br />
Si osservi che, in questo modo, no<strong>di</strong> con n genitori nel DAG figurano almeno<br />
n volte nell’albero associato (ra<strong>di</strong>ce esclusa che è <strong>un</strong>ica per definizione).<br />
L’<strong>un</strong>ico vincolo che occorre considerare nel presentare il documento all’utente<br />
in questa forma, è che no<strong>di</strong> del DAG che compaiono più <strong>di</strong> <strong>un</strong>a volta (D, 4 e<br />
5) devono essere contrassegnati e mantenuti identici durante tutto il ciclo <strong>di</strong><br />
vita del documento, pena la per<strong>di</strong>ta della sua vali<strong>di</strong>tà.<br />
La struttura ad albero (più in generale a foresta 5 ) rientra a pieno titolo fra<br />
quelle gestibili con DOM (Document Object Model): le operazioni <strong>di</strong> accesso<br />
e <strong>di</strong> manipolazione <strong>di</strong> documenti D3IM possono essere effettuate tramite tale<br />
API (per ulteriori dettagli si faccia riferimento a [ABC + 04]).<br />
4.2.1 Identificazione dei no<strong>di</strong> e relativo accesso<br />
Nel <strong>modello</strong> D3IM l’identificazione dei no<strong>di</strong> è <strong>un</strong>’operazione che deve<br />
essere mantenuta in<strong>di</strong>pendente dall’accesso fisico.<br />
Questo è conseguenza della percezione che ha l’uomo <strong>di</strong> “documento”:<br />
ad esempio con “categoria della patente <strong>di</strong> guida <strong>di</strong> Mario Rossi” si intende<br />
4 Si definisce albero <strong>un</strong> grafo aciclico non orientato e connesso. In realtà la struttura in<br />
esame è <strong>un</strong> polytree (versione orientata <strong>di</strong> albero) che, fissato <strong>un</strong> albero, nasce nel momento<br />
in cui viene scelto <strong>un</strong>o nodo come ra<strong>di</strong>ce. L’abuso <strong>di</strong> nomenclatura è stato effettuato in<br />
quanto il termine “albero” è <strong>di</strong> più imme<strong>di</strong>ata comprensione e nella trattazione corrente<br />
non c’è rischio <strong>di</strong> ambiguità.<br />
5 Si definisce foresta <strong>un</strong> grafo aciclico non orientato.<br />
82
Modello dell’informazione <strong>versionata</strong> D3IM I no<strong>di</strong> informativi del documento<br />
Documento<br />
D3IM<br />
B<br />
Informazione astratta<br />
associata a B<br />
a<br />
A<br />
1<br />
4 5<br />
C<br />
2 3<br />
D<br />
Associata<br />
a D<br />
Informazione astratta<br />
associata ad A<br />
Informazione<br />
Primitiva<br />
Informazione<br />
Atomica<br />
Associata<br />
a C<br />
Legenda<br />
Albero<br />
associato<br />
B<br />
b<br />
A<br />
1<br />
Aggregazione<br />
Incapsulamento<br />
C<br />
2 3<br />
D D<br />
4 5<br />
4 5<br />
Figura 4.1: Documento D3IM: DAG ed albero associato.<br />
<strong>un</strong>’informazione ben precisa ed in<strong>di</strong>pendente dal luogo e dal formato in cui<br />
viene conservata. In pratica la categoria è la stessa informazione sia che<br />
questa venga memorizzata negli archivi elettronici della Motorizzazione Civile<br />
che stampata sul documento in formato cartaceo in possesso del titolare della<br />
patente.<br />
È utile osservare che nel web questa proprietà non è verificata: gli URL 6<br />
servono sia per identificare la risorsa che il luogo in cui questa viene memorizzata<br />
ovvero per accedervi.<br />
L’esempio relativo alla patente <strong>di</strong> guida evidenzia come l’identificazione<br />
delle risorse sia <strong>un</strong>’operazione concettualmente <strong>di</strong>versa dall’accesso e pertanto,<br />
in generale, è opport<strong>un</strong>o che le due operazioni siano <strong>di</strong>stinte. In tal caso,<br />
<strong>un</strong>a volta effettuata l’identificazione in <strong>un</strong>a prima fase, è possibile procedere,<br />
6 Uniform Resource Locator [BLMM94], sono gli in<strong>di</strong>rizzi utilizzati nel web per identificare<br />
ed accedere alle risorse. Sono <strong>un</strong> caso particolare <strong>di</strong> URI (Uniform Resource<br />
Identifiers) [BLFIM98].<br />
83
Modello dell’informazione <strong>versionata</strong> D3IM I no<strong>di</strong> informativi del documento<br />
in <strong>un</strong>a fase successiva, con l’accesso. Se, come nel web, le due operazioni<br />
si sovrappongono ci si trova <strong>di</strong> fronte ad <strong>un</strong> caso particolare del precedente,<br />
conseguentemente la scalabilità complessiva risulta minore o, al limite,<br />
uguale.<br />
Queste ultime considerazioni hanno portato alla definizione degli URN<br />
(Uniform Resource Name) [SM94, Moa97, DvGIF99, Dan97]. Un URN è<br />
anche <strong>un</strong> URI, ma <strong>di</strong>fferisce da <strong>un</strong> URL per il fatto che identifica <strong>un</strong>a risorsa<br />
web in<strong>di</strong>pendentemente dalla sua locazione fisica inoltre non contiene informazioni<br />
variabili nel tempo. Un buon esempio <strong>di</strong> URN è il co<strong>di</strong>ce ISBN <strong>di</strong><br />
<strong>un</strong> libro [LPD98]: ISBN identifica <strong>un</strong> libro, ma ness<strong>un</strong>a delle sue copie.<br />
In D3IM si definiscono Persistent Resource Identifier (PRI ) gli URN che<br />
identificano i no<strong>di</strong> del documento in modo <strong>un</strong>ivoco, questo nome mette in<br />
evidenza la principale proprietà che caratterizza questo tipo <strong>di</strong> identificatore:<br />
la persistenza. Ulteriori dettagli relativi alla definizione ed alla gestione dei<br />
PRI verranno riportati nel capitolo 8.<br />
Per accedere alla risorsa identificata dal PRI, c’è bisogno <strong>di</strong> risolverla in <strong>un</strong><br />
nome che ne consenta l’accesso, ovvero <strong>un</strong> URL. L’uso <strong>di</strong> PRI per identificare<br />
le risorse e <strong>di</strong> URL per accedervi consente <strong>di</strong> riferire in<strong>di</strong>rettamente le molte<br />
repliche in <strong>di</strong>fferenti locazioni come mostrato in figura 4.2.b. Questa soluzione<br />
consente <strong>di</strong> mascherare la ridondanza. Inoltre, data la stabilità <strong>di</strong> <strong>un</strong> PRI nel<br />
riferirsi alla risorsa, è possibile muovere la risorsa da <strong>un</strong>a locazione all’altra<br />
senza che tali cambiamenti si ripercuotano sul PRI. Un PRI consente a<br />
risorse mobili <strong>di</strong> essere in<strong>di</strong>rettamente riferite attraverso <strong>un</strong> insieme <strong>di</strong> URL<br />
che variano nel tempo.<br />
Poiché i PRI sono ad uso e consumo della macchina, non sono necessarie<br />
restrizioni per renderli facilmente utilizzabili e trascrivibili dall’uomo,<br />
anche se ciò è com<strong>un</strong>que auspicabile. Purtroppo gli utenti hanno bisogno<br />
<strong>di</strong> assegnare nomi facilmente intellegibili e con<strong>di</strong>visibili con altri per in<strong>di</strong>care<br />
concetti e contenuti. Per questo fine sono possibili due strade <strong>di</strong> seguito<br />
in<strong>di</strong>cate.<br />
La prima è usare <strong>un</strong> <strong>di</strong>rectory service, come LDAP [HM02], il quale permette<br />
agli utenti <strong>di</strong> cercare la risorsa con lo stesso principio delle “pagine<br />
gialle”, basato sulla ricerca del valore degli attributi assegnati ad essa. Il<br />
principale svantaggio del <strong>di</strong>rectory service è la limitata scalabilità, su larga<br />
scala, non sono ancora stati sviluppati. Attualmente la migliore soluzione<br />
è costituita da <strong>di</strong>rectory service federati, che richiedono middleware e che<br />
forniscono <strong>un</strong> <strong>un</strong>ico p<strong>un</strong>to <strong>di</strong> accesso.<br />
84
Modello dell’informazione <strong>versionata</strong> D3IM I no<strong>di</strong> informativi del documento<br />
(a)<br />
(b)<br />
(c)<br />
URL<br />
Replica<br />
URL<br />
Replica<br />
URL<br />
Replica<br />
URL<br />
Replica<br />
URN<br />
URL<br />
Replica<br />
HFN HFN<br />
URN<br />
URL<br />
Replica<br />
URL<br />
Replica<br />
URL<br />
Replica<br />
URL<br />
Replica<br />
Figura 4.2: Nomi <strong>di</strong> risorse replicate.<br />
La seconda consiste nell’utilizzare <strong>un</strong> sistema <strong>di</strong> nomi gerarchico comparabile<br />
al servizio delle “pagine bianche” (elenco telefonico). Il Domain Name<br />
System (DNS) [KR03] è <strong>un</strong> esempio <strong>di</strong> questo tipo. Sebbene non siano <strong>di</strong>sponibili<br />
gli attributi è provata la scalabilità su larga scala con milioni <strong>di</strong> utenti.<br />
Da questa prospettiva risulta più attraente rispetto al <strong>di</strong>rectory service.<br />
Per riempire il <strong>di</strong>vario tra le proprietà del PRI e le necessità umane è op-<br />
85
Modello dell’informazione <strong>versionata</strong> D3IM I no<strong>di</strong> informativi del documento<br />
port<strong>un</strong>o introdurre <strong>un</strong> nuovo tipo <strong>di</strong> URI come suggerito in [Sol98] e [CM03].<br />
È definito Human Friendly Name (HFN ) <strong>un</strong> nome <strong>di</strong> alto livello progettato<br />
a misura d’uomo [SM94]. A <strong>di</strong>fferenza degli URN gli HFN permettono l’uso<br />
esplicito <strong>di</strong> nomi descrittivi. Un HFN ha bisogno <strong>di</strong> essere risolto in <strong>un</strong> URL<br />
quando l’utente vuole accedere alla risorsa. Un modo per realizzare questa<br />
traduzione è <strong>di</strong> collegare <strong>un</strong> HFN ad <strong>un</strong> PRI, dopo<strong>di</strong>ché collegare il PRI all’URL<br />
opport<strong>un</strong>o. Il proce<strong>di</strong>mento è composto da due fasi: nella prima HFN<br />
viene risolto in PRI e nella seconda il PRI in URL, come schematizzato in<br />
figura 4.2.c.<br />
Esistono molti vantaggi con quest’ultimo approccio. In primo luogo gli<br />
utenti possono assegnare in libertà nomi <strong>di</strong> convenienza alle risorse. Se <strong>un</strong>a<br />
risorsa è replicata o spostata in <strong>un</strong>’altra locazione, ciò non ha effetti sul<br />
nome HFN. Analogamente, se <strong>un</strong> utente decide <strong>di</strong> cambiare l’HFN non si<br />
avranno effetti sulla posizione delle repliche. Inoltre <strong>un</strong> utente può scegliere<br />
<strong>di</strong> usare nomi <strong>di</strong>versi per in<strong>di</strong>care la stessa risorsa, allo stesso modo con cui<br />
vengono usati gli alias negli in<strong>di</strong>rizzi <strong>di</strong> posta elettronica o nei link simbolici<br />
del file system. Per evidenziare il fatto che gli HFN assegnano <strong>un</strong> nome logico<br />
alla risorsa, nel <strong>modello</strong> D3IM sono stati definiti Logical Resource Identifier<br />
(LRI ). Come per i PRI ulteriori dettagli su HFN e, più nello specifico sugli<br />
LRI, saranno riportati nel capitolo 8.<br />
4.2.2 Informazioni atomiche<br />
Come anticipato l’informazione atomica è <strong>un</strong>a coppia “”.<br />
I valori che vengono memorizzati sono soggetti a verifica sintattica e <strong>di</strong><br />
ammissibilità.<br />
Ad esempio l’informazione atomica “” è accurata sintatticamente,<br />
in quanto il valore numerico appartiene all’elenco dei CAP stabiliti<br />
dalle Poste Italiane. Invece il valore “FI-50100” è sintatticamente scorretto<br />
oppure “01234” è sintatticamente corretto, ma inammissibile. Indubbiamente<br />
per il generico utente, che inserisce il dato, la parte nome della coppia “”<br />
ha <strong>un</strong> certo peso semantico. Non è però conveniente affidare tali<br />
controlli <strong>un</strong>icamente alle capacità dell’utente in quanto (tutti quelli sintattici<br />
e buona parte <strong>di</strong> quelli semantici) possono essere automatizzati e affrontati<br />
da elaboratori elettronici con notevoli vantaggi sia in termini temporali che<br />
<strong>di</strong> precisione.<br />
Visto che il <strong>modello</strong> non è <strong>un</strong>a base <strong>di</strong> dati e non è dotato <strong>di</strong> algebra rela-<br />
86
Modello dell’informazione <strong>versionata</strong> D3IM I no<strong>di</strong> informativi del documento<br />
zionale sembrerebbe impossibile stabilire se il requisito <strong>di</strong> accuratezza possa<br />
essere sempre sod<strong>di</strong>sfatto. La risposta al problema consiste nell’ipotizzare che<br />
tutte le informazioni atomiche e primitive siano create e messe a <strong>di</strong>sposizione<br />
da <strong>un</strong>’entità responsabile che ne garantisce l’accuratezza.<br />
Per quanto riguarda le informazioni atomiche questo è ottenibile, senza<br />
perdere in generalità, tramite incapsulamento entro informazioni primitive.<br />
In altre parole ogni informazione atomica è associata ad <strong>un</strong>a e <strong>un</strong>a sola informazione<br />
primitiva la quale permette <strong>di</strong> proiettare la coppia “”<br />
nello spazio dei documenti D3IM. Questo è conseguenza dal fatto che ogni<br />
istanza <strong>di</strong> <strong>un</strong>a qualsiasi coppia “” non è <strong>un</strong>’informazione atomica,<br />
ma può <strong>di</strong>venire tale se viene “inquadrata” nell’ambito dei documenti<br />
D3IM e l’incapsulamento <strong>di</strong> cui sopra ha la finalità <strong>di</strong> svolgere questa<br />
operazione.<br />
Un esempio che permette <strong>di</strong> chiarire questo tema è relativo al concetto<br />
<strong>di</strong> responsabilità dell’informazione appena citato: parafrasando ciò che<br />
è stato introdotto in precedenza ogni informazione presente in <strong>un</strong> qualsiasi<br />
documento D3IM deve avere <strong>un</strong> responsabile, ovvero l’entità che ha autorità<br />
su <strong>di</strong> essa. Il concetto <strong>di</strong> responsabilità è <strong>di</strong>rettamente associato alle<br />
informazioni primitive e sarà affrontato nel paragrafo successivo. In questo<br />
contesto è sufficiente considerare il responsabile come <strong>un</strong>a proprietà, o attributo,<br />
dell’informazione. In questi termini l’incapsulamento della coppia<br />
“” all’interno <strong>di</strong> <strong>un</strong>’informazione primitiva permette <strong>di</strong> farle<br />
ere<strong>di</strong>tare il responsabile <strong>di</strong> quest’ultima, rendendola quin<strong>di</strong> dotata dell’attributo<br />
necessario per poter appartenere allo spazio delle informazioni definite<br />
in D3IM.<br />
In questo modo il problema della gestione delle informazioni viene semplificato:<br />
• da <strong>un</strong>a parte viene ricondotto verso il gestore <strong>di</strong> quella informazione,<br />
il quale ha le nozioni sufficienti a stabilire le regole sintattiche e le<br />
con<strong>di</strong>zioni a contorno;<br />
• dall’altra l’utente consumatore ha il dovere <strong>di</strong> cercare i valori e non più<br />
l’onere <strong>di</strong> acquisirli nuovamente.<br />
In questo modo si tende anche a realizzare il presupposto ai requisiti <strong>di</strong><br />
<strong>un</strong>ico inserimento dei dati nel sistema, pertinenza e non eccedenza. Com<strong>un</strong>que<br />
per non rendere troppo rigido il <strong>modello</strong> dovrà essere tenuta in<br />
considerazione anche la possibilità <strong>di</strong>:<br />
87
Modello dell’informazione <strong>versionata</strong> D3IM I no<strong>di</strong> informativi del documento<br />
• inserire i dati con strategie <strong>di</strong> autonomia a responsabilità <strong>di</strong>versificata;<br />
• correggerli ed arricchirli in fasi successive ed in<strong>di</strong>pendenti.<br />
4.2.3 Informazioni primitive<br />
È stato anticipato che le informazioni primitive modellano gli aspetti<br />
strutturali sfruttando il principio <strong>di</strong> aggregazione fra no<strong>di</strong>. Ogni nodo contenente<br />
<strong>un</strong>’informazione primitiva può essere genitore <strong>di</strong> <strong>un</strong>a serie <strong>di</strong> no<strong>di</strong><br />
contenenti altre informazioni primitive. L’<strong>un</strong>ico vincolo esistente è che nella<br />
struttura non siano presenti cicli (ovvero ogni informazione primitiva non<br />
può essere figlia, nipote, pronipote, etc. o antenata <strong>di</strong> se stessa).<br />
Le relazioni fra informazioni primitive vengono instaurate sulla base degli<br />
in<strong>di</strong>rizzi <strong>un</strong>ivoci e persistenti (PRI) descritti nel paragrafo 4.2.1. Si osservi<br />
che l’esistenza <strong>di</strong> più alias (in<strong>di</strong>rizzi LRI) verso l’informazione e <strong>di</strong> più repliche<br />
della stessa (accessibili tramite gli URL) sono aspetti ininfluenti ai fini <strong>di</strong><br />
questa trattazione.<br />
A seguito del concetto <strong>di</strong> “incapsulamento” introdotto nel paragrafo precedente,<br />
le informazioni atomiche non hanno <strong>un</strong> proprio in<strong>di</strong>rizzo all’interno<br />
dello spazio dei nomi PRI definito in D3IM, ma ere<strong>di</strong>tano quello dell’informazione<br />
primitiva che le incapsula. Eventualmente è possibile ipotizzare <strong>un</strong><br />
meccanismo equivalente a quello delle ancore presente nel web: fissato l’in<strong>di</strong>rizzo<br />
<strong>un</strong>ivoco dell’informazione primitiva è possibile specificare, tramite <strong>un</strong><br />
parametro ad<strong>di</strong>zionale, qual è l’informazione atomica <strong>di</strong> interesse. In questo<br />
modo risulta possibile in<strong>di</strong>rizzare <strong>un</strong>ivocamente anche le informazioni atomiche.<br />
Per quanto riguarda gli in<strong>di</strong>rizzi logici (LRI) e fisici (URL) non è<br />
possibile fare ipotesi. Ad esempio si può definire <strong>un</strong> in<strong>di</strong>rizzo LRI che in<strong>di</strong>vidui<br />
<strong>un</strong>’informazione atomica tramite il meccanismo menzionato simile alle<br />
ancore, come è ipotizzabile che l’accesso fisico ad <strong>un</strong>’informazione atomica<br />
avvenga tramite <strong>un</strong> URL.<br />
Il concetto <strong>di</strong> incapsulamento può essere visto anche come ottimizzazione<br />
dal p<strong>un</strong>to <strong>di</strong> vista ingegneristico, in quanto permette <strong>di</strong> contenere l’esplosione<br />
del numero <strong>di</strong> in<strong>di</strong>rizzi <strong>un</strong>ivoci presenti nello spazio dei nomi persistenti,<br />
senza perdere in generalità: in questo modo infatti le informazioni atomiche<br />
non hanno <strong>un</strong> proprio in<strong>di</strong>rizzo <strong>un</strong>ivoco. Questo aspetto porta anche <strong>un</strong> altro<br />
vantaggio: il numero <strong>di</strong> elementi <strong>di</strong>stinti che costituiscono i documenti risulta<br />
molto minore rispetto a quello che si avrebbe assegnando <strong>un</strong>a propria identità<br />
88
Modello dell’informazione <strong>versionata</strong> D3IM I no<strong>di</strong> informativi del documento<br />
(in<strong>di</strong>rizzo PRI) alle informazioni atomiche, senza rin<strong>un</strong>ciare ai vantaggi della<br />
sud<strong>di</strong>visione granulare dell’informazione che la soluzione proposta offre.<br />
Riassumendo, ogni informazione primitiva è quin<strong>di</strong> genitore <strong>di</strong> altre informazioni<br />
primitive ed incapsula (contiene) al proprio interno <strong>un</strong> certo numero<br />
<strong>di</strong> informazioni atomiche. Si osservi come da questo caso generale si possano<br />
definire documenti, come casi particolari, introducendo ulteriori restrizioni.<br />
Ad esempio <strong>un</strong> vincolo che può essere introdotto riguarda la mutua esclusione<br />
fra l’aggregazione e l’incapsulamento: in questi termini ogni informazione<br />
primitiva aggrega altre informazioni primitive senza incapsulare informazioni<br />
atomiche oppure incapsula informazioni atomiche senza aggregare<br />
informazioni primitive. Documenti strutturati secondo questa modalità hanno<br />
le informazioni atomiche esclusivamente nelle foglie. Inoltre tutte le foglie<br />
contengono necessariamente informazioni atomiche e pertanto esiste <strong>un</strong>a perfetta<br />
corrispondenza fra le foglie e le informazioni atomiche e fra gli atri no<strong>di</strong><br />
e le informazioni primitive.<br />
Un altro vincolo che può essere introdotto riguarda la possibilità <strong>di</strong> limitare<br />
il numero <strong>di</strong> genitori fra zero e <strong>un</strong>o. Questo permette <strong>di</strong> generare<br />
documenti con struttura ad albero (orientato) come caso particolare <strong>di</strong> DAG.<br />
Da <strong>un</strong> p<strong>un</strong>to <strong>di</strong> vista astratto è possibile considerare le informazioni primitive<br />
come il p<strong>un</strong>to <strong>di</strong> accesso all’informazione complessiva che si sviluppa<br />
da esse fino alle foglie, come evidenziato in figura 4.1.a.<br />
Questa associazione sarà ancora più chiara quando verrà illustrato il meccanismo<br />
<strong>di</strong> gestione delle versioni che si innesca in corrispondenza della mo<strong>di</strong>fica<br />
<strong>di</strong> <strong>un</strong>’informazione (ogni mo<strong>di</strong>fica ad <strong>un</strong> qual<strong>un</strong>que elemento che risulta<br />
essere successore nella gerarchia del nodo, si ripercuote su <strong>di</strong> esso).<br />
Infine ad ogni nodo contenente <strong>un</strong>’informazione primitiva è associato <strong>un</strong><br />
responsabile. Il responsabile deve garantire la correttezza della struttura<br />
(legame logico tra le parti) e, per le informazioni atomiche incapsulate, la<br />
correttezza dei dati associati alle coppie “”.<br />
Per esempio si faccia l’ipotesi che la patente <strong>di</strong> guida debba contenere i<br />
seguenti elementi:<br />
• numero;<br />
• categoria;<br />
• dati anagrafici.<br />
89
Modello dell’informazione <strong>versionata</strong> D3IM Relazioni fra i no<strong>di</strong> informativi<br />
La Motorizzazione Civile deve garantire la correttezza delle coppie “”<br />
e “”. È l’anagrafe a garantire la correttezza<br />
delle informazioni atomiche relative ai dati anagrafici, la motorizzazione<br />
è responsabile per quanto riguarda la sola aggregazione all’interno del<br />
documento.<br />
4.3 Relazioni fra i no<strong>di</strong> informativi<br />
Un documento ha la particolarità <strong>di</strong> essere classificabile come entità autonoma<br />
pur essendo costituito da <strong>un</strong> insieme <strong>di</strong> informazioni <strong>di</strong>sgi<strong>un</strong>te. Ogni<br />
documento ha <strong>un</strong>a ra<strong>di</strong>ce che lo in<strong>di</strong>vidua, nel senso che questa rappresenta<br />
il p<strong>un</strong>to d’accesso al documento, la quale è <strong>un</strong>’informazione primitiva.<br />
Dualmente ogni informazione primitiva può essere vista come ra<strong>di</strong>ce <strong>di</strong> <strong>un</strong><br />
documento.<br />
A partire dalla ra<strong>di</strong>ce esistono delle relazioni che la mettono in collegamento<br />
con altre informazioni primitive. Questo proce<strong>di</strong>mento si ripete in<br />
modo ricorsivo fino a quando non vengono raggi<strong>un</strong>te tutte le foglie ovvero<br />
tutte le informazioni atomiche.<br />
Link <strong>di</strong> composizione. Le relazioni che legano le informazioni interne<br />
al documento (secondo i principi precedentemente descritti) si definiscono<br />
link <strong>di</strong> composizione. In riferimento al <strong>modello</strong> UEVM, che si ricorda essere<br />
ampiamente descritto nel capitolo 2, i link sono da intendersi come relazioni<br />
che legano due no<strong>di</strong> <strong>di</strong> cui <strong>un</strong>o è il padre e l’altro il figlio. In particolare questi<br />
link sono quelli per i quali il nodo padre è <strong>di</strong> tipo C; tale corrispondenza<br />
ha condotto alla scelta del nome “link <strong>di</strong> composizione”. Questo porta a<br />
concludere che esiste <strong>un</strong>a equivalenza fra i no<strong>di</strong> <strong>di</strong> tipo C del <strong>modello</strong> UEVM<br />
e le informazioni primitive <strong>di</strong> D3IM.<br />
Link <strong>di</strong> riferimento. Come evidenziato in UEVM esiste la necessità <strong>di</strong><br />
introdurre delle relazioni fra documenti <strong>di</strong>stinti. In UEVM questo problema<br />
viene risolto introducendo no<strong>di</strong> <strong>di</strong> tipo L. Equivalentemente in D3IM sono<br />
stati definiti i link <strong>di</strong> riferimento che svolgono lo stesso tipo <strong>di</strong> f<strong>un</strong>zione.<br />
Questo tipo <strong>di</strong> collegamento, che modella il caso <strong>di</strong> correlazione fra documenti<br />
<strong>di</strong>stinti ovvero fra no<strong>di</strong> appartenenti a documenti <strong>di</strong>versi, può essere<br />
facilmente classificato come informazione atomica.<br />
90
Modello dell’informazione <strong>versionata</strong> D3IM Storico dei documenti<br />
4.4 Storico dei documenti<br />
Ogni documento <strong>di</strong>spone <strong>di</strong> caratteristiche atte a memorizzare la sua evoluzione<br />
temporale, chiamata storico. Tale evoluzione, sebbene sia <strong>un</strong>a caratteristica<br />
globale del documento, viene mantenuta memorizzando l’evoluzione<br />
delle singole informazioni che lo costituiscono (a livello <strong>di</strong> nodo).<br />
Le evoluzioni temporali delle singole informazioni (che si ricorda essere<br />
strutturate a DAG), pur essendo mantenute separate ed associate ad esse, non<br />
sono in<strong>di</strong>pendenti: <strong>un</strong>a mo<strong>di</strong>fica effettuata ad <strong>un</strong>’informazione che si trova ad<br />
<strong>un</strong> livello più basso della gerarchia si ripercuote su tutti i suoi predecessori.<br />
Questo fa sì che lo storico della ra<strong>di</strong>ce “comprenda”, seppur in<strong>di</strong>rettamente,<br />
l’evoluzione temporale <strong>di</strong> tutto il documento. Volendo recuperare <strong>un</strong>a data<br />
versione7 , è previsto <strong>un</strong> meccanismo <strong>di</strong> navigazione nello storico che, partendo<br />
dalla ra<strong>di</strong>ce ed attraversando i vari no<strong>di</strong> del documento, permette <strong>di</strong><br />
ricomporlo come richiesto. È utile evidenziare come il meccanismo, basandosi<br />
su <strong>un</strong> <strong>modello</strong> estensionale, permetta, a <strong>di</strong>fferenza <strong>di</strong> altri modelli <strong>di</strong><br />
versioning, <strong>di</strong> ripercorrere lo storico del documento nel modo più naturale<br />
possibile per l’utente: ogni versione del documento viene ricostruita correttamente<br />
sia per quel che riguarda i dati contenuti sia per quanto riguarda gli<br />
aspetti strutturali.<br />
Per descrivere i meccanismi <strong>di</strong> gestione dello storico è utile inizialmente<br />
fare riferimento ad <strong>un</strong> documento costituito da <strong>un</strong> <strong>un</strong>ico nodo e, successivamente,<br />
estendere il concetto al caso più generale.<br />
Sotto l’ipotesi che ogni nodo, <strong>un</strong>a volta creato, sia <strong>un</strong>a grandezza immutabile<br />
nel tempo l’operazione <strong>di</strong> mo<strong>di</strong>fica dà vita ad <strong>un</strong> nuovo nodo. Si definisce<br />
versione <strong>un</strong>’informazione primitiva ottenuta mo<strong>di</strong>ficando il contenuto<br />
informativo <strong>di</strong> <strong>un</strong> nodo esistente. Anche la nascita <strong>di</strong> <strong>un</strong>a nuova informazione<br />
rientra in questa definizione considerando che tale operazione può essere vista<br />
come la mo<strong>di</strong>fica dell’informazione nulla. Viene definito <strong>un</strong>o stato UPDATE<br />
che viene associato ad ogni informazione per determinare se è necessario generare<br />
nuove versioni oppure effettuare sovrascritture. Il valore ass<strong>un</strong>to dallo<br />
stato può essere frozen o changing rispettivamente. Le transizioni avvengono<br />
tramite le operazioni <strong>di</strong> freeze e melt, figura 4.3.<br />
È opport<strong>un</strong>o chiarire cosa si intende con “mo<strong>di</strong>fica” <strong>di</strong> <strong>un</strong>’informazione al<br />
variare del tipo <strong>di</strong> essa:<br />
7 In questo caso con versione si intende <strong>un</strong>a ben precisa configurazione del documento.<br />
A riguardo si faccia riferimento al capitolo 2.<br />
91
Modello dell’informazione <strong>versionata</strong> D3IM Storico dei documenti<br />
UPDATE<br />
melt<br />
changing<br />
frozen<br />
freeze<br />
close [in hard]<br />
Figura 4.3: Stato “Update” delle informazioni.<br />
• nel caso <strong>di</strong> informazione atomica si parla <strong>di</strong> cambiamento <strong>di</strong> <strong>un</strong>o o <strong>di</strong><br />
entrambi i campi “nome” o “valore”;<br />
• nel caso <strong>di</strong> informazione primitiva si parla <strong>di</strong> cambiamento <strong>di</strong> <strong>un</strong>a o più<br />
delle relazioni <strong>di</strong> aggregazione che partono dall’informazione in esame<br />
o dei metadati ad essa associati.<br />
Può essere utile specificare che per quanto riguarda i link <strong>di</strong> riferimento, siccome<br />
rientrano nella prima categoria, il nodo che contiene il link si considera<br />
mo<strong>di</strong>ficato solo se cambia il valore stesso del link. Eventuali variazioni del<br />
nodo riferito dal link non determinano variazioni dello storico del documento<br />
che lo contiene.<br />
È possibile mo<strong>di</strong>ficare solo e soltanto l’ultimo nodo creato all’interno dello<br />
storico e, nel caso in cui lo stato UPDATE sia frozen, quello che si genera è<br />
<strong>un</strong> insieme or<strong>di</strong>nato <strong>di</strong> revisioni. Viceversa per mo<strong>di</strong>ficare <strong>un</strong> nodo che non<br />
sia l’ultimo occorre creare <strong>un</strong>a <strong>di</strong>ramazione o branch (figura 4.4).<br />
L’or<strong>di</strong>namento delle versioni nella <strong>di</strong>ramazione è totale, in quanto sull’insieme<br />
è ben definita la relazione <strong>di</strong> revisione (−→) con le seguenti proprietà:<br />
1. riflessiva: per ogni versione x appartente ad <strong>un</strong>a <strong>di</strong>ramazione, si ha<br />
x−→x;<br />
2. antisimmetrica: per ogni versione x, y appartenenti ad <strong>un</strong>a stessa<br />
<strong>di</strong>ramazione, tali che x−→y e y−→x, allora x≡y;<br />
3. transitiva: per ogni versione x, y, z appartenenti ad <strong>un</strong>a stessa <strong>di</strong>ramazione,<br />
tali che x−→y e y−→z, allora x−→z;<br />
92
Modello dell’informazione <strong>versionata</strong> D3IM Storico dei documenti<br />
4. confronto: per ogni versione x, y appartenenti ad <strong>un</strong>a stessa <strong>di</strong>ramazione,<br />
si ha x−→y oppure y−→x.<br />
La creazione <strong>di</strong> <strong>un</strong>a nuova <strong>di</strong>ramazione avviene su esplicita richiesta dell’utente.<br />
Ad esempio consideriamo il ramo x al tempo t0 in figura 4.4. La<br />
richiesta <strong>di</strong> nascita <strong>di</strong> <strong>un</strong>a <strong>di</strong>ramazione a partire dalla prima versione x.0 al<br />
tempo t1>t0 comporta la creazione del ramo y contenente la nuova versione<br />
y.0. Al tempo t2>t1 la mo<strong>di</strong>fica <strong>di</strong> x.1 viene applicata nello stesso ramo con<br />
la revisione x.2.<br />
Branch x (t0) Branch x (t 1 > t 0 ) Branch x (t2 > t1 > t0)<br />
x.0 x.1 x.0 x.1 x.0 x.1 x.2<br />
Branch y (t1) Branch y (t2)<br />
y.0<br />
Figura 4.4: Generazione delle revisioni.<br />
Lo storico è interrogabile esprimendo esplicitamente la versione desiderata.<br />
Com<strong>un</strong>que è possibile estendere l’interrogazione anche attraverso delle<br />
proposizioni logiche: ogni versione contiene al proprio interno dei riferimenti<br />
relativi alle versioni precedenti ed a quelle successive<br />
4.4.1 La propagazione delle mo<strong>di</strong>fiche<br />
Le versioni sono correlate attraverso l’aggregazione e possono concorrere<br />
a formare arbitrarie strutture: se mettiamo in evidenza solo le versioni e<br />
le relazioni <strong>di</strong> aggregazione che le connettono ciò che otteniamo è <strong>un</strong> grafo<br />
orientato. La nascita <strong>di</strong> <strong>un</strong>a nuova revisione scatena <strong>un</strong> meccanismo <strong>di</strong> propagazione<br />
nel grafo attraverso i cammini che si sviluppano in senso opposto<br />
rispetto alla <strong>di</strong>rezione degli archi relativi ai link <strong>di</strong> composizione che partono<br />
dall’ultima revisione <strong>di</strong> ogni branch.<br />
Si può osservare che la propagazione all’interno della struttura del documento<br />
corrente è <strong>un</strong> caso particolare, poiché in generale coinvolge tutti quei<br />
y.0<br />
93
Modello dell’informazione <strong>versionata</strong> D3IM Storico dei documenti<br />
documenti che hanno dei sotto alberi in com<strong>un</strong>e legati da link <strong>di</strong> composizione.<br />
I link <strong>di</strong> riferimento permettono <strong>di</strong> creare correlazioni fra dati come<br />
avviene per i link <strong>di</strong> composizione; la <strong>di</strong>fferenza sostanziale è che, nel caso<br />
dei link <strong>di</strong> riferimento, non si ha la propagazione delle versioni.<br />
Durante <strong>un</strong>a sessione al massimo vengono create tante versioni quanti<br />
sono i no<strong>di</strong> coinvolti. Ripetute operazioni su <strong>un</strong> nodo sono parte integrante<br />
della stessa attività. Ripetute aggi<strong>un</strong>te, cancellazioni, e cambiamenti dei<br />
figli <strong>di</strong> <strong>un</strong> nodo genereranno <strong>un</strong>a ed <strong>un</strong>a sola versione relativa a quel nodo.<br />
L’estensione temporale <strong>di</strong> <strong>un</strong>a sessione è sfruttata per controllare la granularità<br />
del versioning. I meccanismi menzionati riflettono a pieno quelli visti in<br />
UEVM, a cui deve essere fatto riferimento per ulteriori dettagli.<br />
4.4.2 Authoring concorrente<br />
Consideriamo <strong>un</strong>’informazione primitiva sulla quale vengono effettuate<br />
operazioni <strong>di</strong> lettura e scrittura, intendendo con scrittura anche la mo<strong>di</strong>fica<br />
strutturale, cioè l’aggi<strong>un</strong>ta o l’eliminazione <strong>di</strong> no<strong>di</strong>. Le operazioni, pur essendo<br />
rivolte verso la ra<strong>di</strong>ce, coinvolgono tutti quei no<strong>di</strong> del documento sui<br />
quali l’utente ha i <strong>di</strong>ritti per operare. In questo paragrafo, per semplicità e<br />
senza perdere in generalità, si suppone che tutti gli utenti possano accedere<br />
alle informazioni in lettura e che solo il relativo responsabile possa effettuare<br />
mo<strong>di</strong>fiche. Ogni operazione avviene all’interno <strong>di</strong> <strong>un</strong>a sessione.<br />
Si può incorrere nella concorrenza delle operazioni per due motivi:<br />
1. è richiesta <strong>un</strong>a attività <strong>di</strong> authoring parallelo sullo stesso documento<br />
(figura 4.5.a);<br />
2. due o più documenti, che aggregano <strong>un</strong>a stessa informazione primitiva,<br />
vengono aperti in intervalli <strong>di</strong> tempo sovrapposti (figura 4.5.b).<br />
Concettualmente sono attività <strong>di</strong>verse, ma in questo contesto vengono trattate<br />
in modo in<strong>di</strong>stinguibile.<br />
Dato che le sessioni <strong>di</strong> lettura sono non <strong>di</strong>struttive e quin<strong>di</strong> meno critiche,<br />
non richiedono complesse tecniche <strong>di</strong> gestione, a patto <strong>di</strong> tenere presente il<br />
requisito <strong>di</strong> awareness percepito dall’utente (ve<strong>di</strong> il paragrafo 1.2 a pagina 7).<br />
Deve esistere <strong>un</strong> opport<strong>un</strong>o sistema <strong>di</strong> accodamento delle operazioni <strong>di</strong> lettura<br />
rispetto a quelle <strong>di</strong> scrittura.<br />
94
Modello dell’informazione <strong>versionata</strong> D3IM Storico dei documenti<br />
(a) (b)<br />
Req 1 Req 2<br />
Info1<br />
Req 1 Req 2<br />
Info1<br />
Info3<br />
Info2<br />
Figura 4.5: Casi <strong>di</strong> authoring concorrente.<br />
Il concetto <strong>di</strong> responsabilità sui no<strong>di</strong> consente <strong>di</strong> limitare la propagazione<br />
dell’apertura delle sessioni in scrittura all’interno del DAG. Ad esempio in<br />
figura 4.5.b si possono verificare 3 situazioni:<br />
1. ness<strong>un</strong>a delle richieste è effettuata dall’autorità responsabile della terza<br />
informazione (info3): ness<strong>un</strong>a sessione in scrittura è possibile sui no<strong>di</strong><br />
che hanno info3 (compreso) come predecessore;<br />
2. solo <strong>un</strong>a richiesta proviene dal responsabile <strong>di</strong> info3: solo <strong>un</strong>o può<br />
mo<strong>di</strong>ficare info3;<br />
3. entrambe le richieste provengono dal responsabile <strong>di</strong> info3: è <strong>un</strong>a situazione<br />
effettivamente singolare, soprattutto alla luce sulle ipotesi fatte<br />
sull’<strong>un</strong>icità del responsabile, ma può presentarsi.<br />
Alla luce <strong>di</strong> queste considerazioni è in<strong>di</strong>spensabile definire <strong>un</strong>o o più<br />
meccanismi necessari al controllo e alla gestione delle sessioni.<br />
Controllo delle sessioni<br />
Con questa prospettiva si in<strong>di</strong>viduano tre politiche <strong>di</strong> apertura <strong>di</strong> <strong>un</strong>a<br />
sessione in scrittura:<br />
• Strong.<br />
95
Modello dell’informazione <strong>versionata</strong> D3IM Storico dei documenti<br />
• Soft.<br />
• Relaxed.<br />
La Strong blocca sia in lettura che in scrittura tutti i no<strong>di</strong> interessati<br />
dall’apertura della sessione. Ad esempio, riconsiderando la figura 4.5.b, ed<br />
ammettendo che la prima richiesta accettata sia avvenuta su info1 con modalità<br />
Strong, successive richieste <strong>di</strong> apertura <strong>di</strong> sessione per la mo<strong>di</strong>fica <strong>di</strong><br />
info1 o semplici richieste <strong>di</strong> accesso verrebbero rifiutate.<br />
La Soft invece blocca i no<strong>di</strong> in scrittura senza inibire l’accesso in sola lettura.<br />
Nell’esempio precedente verrebbero rifiutate ulteriori richieste <strong>di</strong> apertura<br />
<strong>di</strong> sessione in scrittura su info1, ma la possibilità <strong>di</strong> accedere all’informazione<br />
verrebbe com<strong>un</strong>que garantita.<br />
Queste due tipologie <strong>di</strong> blocco permettono la gestione della politica <strong>di</strong> accesso<br />
concorrente turn-taking, descritta nel sotto paragrafo 1.2.4 a pagina 17.<br />
Come <strong>di</strong>mostrato in vari contesti questa politica, anche se comporta alc<strong>un</strong>i<br />
inconvenienti, può risultare utile o ad<strong>di</strong>rittura necessaria per certe tipologie<br />
<strong>di</strong> documenti.<br />
Ad esempio si consideri <strong>un</strong> documento costituito da <strong>un</strong>’<strong>un</strong>ica immagine<br />
in formato Jpeg (queste considerazioni sono valide per la maggior parte dei<br />
documenti, se non tutti, costituiti da <strong>un</strong> file in formato binario). Il formato<br />
Jpeg è tale che ad <strong>un</strong>a mo<strong>di</strong>fica localizzata dell’immagine non corrisponda<br />
<strong>un</strong>a mo<strong>di</strong>fica equivalentemente localizzata nel file. In altre parole ogni mo<strong>di</strong>fica,<br />
in<strong>di</strong>pendentemente dalla sua entità, può portare alla variazione <strong>di</strong> tutto<br />
il file.<br />
Ipotizzando quin<strong>di</strong> che due utenti mo<strong>di</strong>fichino l’immagine in aree non sovrapposte<br />
(ad esempio in alto a destra e in basso a sinistra) non è possibile<br />
fondere i cambiamenti in <strong>un</strong>’<strong>un</strong>ica immagine analizzando soltanto i file mo<strong>di</strong>ficati<br />
senza comprenderne la co<strong>di</strong>fica (in questo caso si potrebbe ipotizzare<br />
che il sistema sia in grado <strong>di</strong> deco<strong>di</strong>ficare le immagini, sovrapporle ricercando<br />
eventuali conflitti e poi co<strong>di</strong>ficare nuovamente il risultato dell’operazione,<br />
ma nella pratica ciò non è possibile per innumerevoli motivi e si potrebbero<br />
com<strong>un</strong>que trovare svariati esempi per i quali tale operazione non è possibile<br />
neanche a livello concettuale).<br />
Questo inconveniente impe<strong>di</strong>sce, <strong>di</strong> fatto, <strong>di</strong> in<strong>di</strong>viduare e risolvere i conflitti:<br />
qualora due o più utenti mo<strong>di</strong>ficassero contemporaneamente lo stesso<br />
documento, tutti perderebbero il lavoro svolto eccetto <strong>un</strong>o (l’ultimo che<br />
“salva”, sovrascrivendo il documento esistente). L’<strong>un</strong>ico modo per aggirare<br />
96
Modello dell’informazione <strong>versionata</strong> D3IM Storico dei documenti<br />
questo ostacolo è quello <strong>di</strong> ricorrere ad <strong>un</strong> blocco esclusivo del file facendo<br />
uso dell’approccio turn-taking.<br />
L’introduzione <strong>di</strong> due politiche <strong>di</strong> lock, la prima sia in lettura che in scrittura<br />
la seconda solo in scrittura, risulta necessaria per garantire la massima<br />
flessibilità del <strong>modello</strong> del documento: come noto, negli ambienti concorrenti,<br />
possono verificarsi casi in cui, all’interno della finestra temporale necessaria<br />
al completamento delle operazioni <strong>di</strong> mo<strong>di</strong>fica <strong>di</strong> <strong>un</strong> gruppo <strong>di</strong> dati, l’accesso<br />
in lettura ad essi da parte <strong>di</strong> altri utenti potrebbe portare ad ottenere risultati<br />
inconsistenti. Per garantire che non si verifichino letture inconsistenti si<br />
ricorre alla politica Strong. Quest’ultima è estremamente conservativa e se è<br />
possibile non inibire l’accesso in lettura in presenza <strong>di</strong> mo<strong>di</strong>fiche che richiedono<br />
l’acquisizione esclusiva della risorsa (sia perché si riesce a garantire la<br />
consistenza dei dati letti in modo <strong>di</strong>verso oppure perché è possibile ritenere<br />
accettabile <strong>un</strong>a certa probabilità <strong>di</strong> errore) si ricorre alla politica Soft che<br />
risulta essere meno conservativa e vincolante.<br />
Infine la Relaxed consente l’authoring concorrente tramite l’approccio<br />
copy-merge descritto nel sotto paragrafo 1.2.4 a pagina 17. Occorre specificare<br />
che, in questo caso, si ha <strong>un</strong> conflitto qualora due o più utenti mo<strong>di</strong>fichino<br />
lo stesso nodo, in<strong>di</strong>pendentemente dall’entità della mo<strong>di</strong>fica.<br />
Nell’esempio precedente, riferito ai file Jpeg, è stato illustrato come non<br />
sia sempre possibile in<strong>di</strong>viduare e risolvere i conflitti per certe tipologie <strong>di</strong> informazioni<br />
rappresentate da <strong>un</strong> <strong>un</strong>ico file (e quin<strong>di</strong> che normalmente verranno<br />
co<strong>di</strong>ficate in <strong>un</strong> <strong>un</strong>ico nodo D3IM). Questo non esclude che per altre categorie<br />
<strong>di</strong> informazioni co<strong>di</strong>ficate all’interno <strong>di</strong> <strong>un</strong> <strong>un</strong>ico nodo D3IM sia possibile<br />
determinare algoritmi in grado <strong>di</strong> analizzarne e comprenderne il contenuto<br />
ed agire <strong>di</strong> conseguenza per quanto riguarda la rilevazione e la gestione dei<br />
conflitti. Un esempio che può essere citato riguarda l’authoring <strong>di</strong> co<strong>di</strong>ce sorgente:<br />
in questo caso si può modellare l’ambiente inserendo il contenuto <strong>di</strong><br />
ogni file sorgente appartenente al progetto all’interno <strong>di</strong> <strong>un</strong>’informazione atomica.<br />
In questo caso è abbastanza semplice comprendere come sia possibile<br />
analizzare il contenuto dell’informazione atomica per stabilire se due utenti<br />
hanno mo<strong>di</strong>ficato le medesime porzioni <strong>di</strong> co<strong>di</strong>ce oppure porzioni <strong>di</strong>verse in<br />
modo da applicare le politiche <strong>di</strong> gestione dei conflitti in modo equivalente<br />
agli SCM (Software Configuration Management) descritti nel capitolo 2.<br />
La modalità Relaxed, come evidenziato nei capitoli 1 e 2, è più adatta ad<br />
essere usata in contesti nei quali l’accesso e la mo<strong>di</strong>fica dei dati avvengono<br />
da parte <strong>di</strong> più in<strong>di</strong>vidui e pertanto, escludendo i casi particolari che devo-<br />
97
Modello dell’informazione <strong>versionata</strong> D3IM Lo stato <strong>di</strong> <strong>un</strong> documento<br />
no essere gestiti ricorrendo alle politiche precedenti, è quella da utilizzarsi<br />
preferibilmente.<br />
In ogni modo ricorrere alla tipologia “sessione Relaxed” nelle richieste <strong>di</strong><br />
scrittura, incrementa la consapevolezza ad alto livello in quanto permette<br />
all’utente <strong>di</strong> prendere atto del fatto che il documento (o parte <strong>di</strong> esso) è in<br />
fase <strong>di</strong> aggiornamento.<br />
In realtà, come anticipato all’inizio del paragrafo, il concetto <strong>di</strong> responsabilità<br />
fa sì che non tutti gli utenti possano mo<strong>di</strong>ficare in<strong>di</strong>scriminatamente<br />
i documenti (o parti <strong>di</strong> essi) conseguentemente si ha <strong>un</strong>a combinazione <strong>di</strong><br />
modelli: split-combine associato a turn-taking oppure a copy-merge.<br />
4.5 Lo stato <strong>di</strong> <strong>un</strong> documento<br />
Per definizione in D3IM lo stato <strong>di</strong> <strong>un</strong> documento è <strong>un</strong>’entità che serve<br />
a quantificare la qualità dell’informazione che questo contiene. Così come<br />
avviene per il versioning anche per lo stato viene fatto riferimento ai singoli<br />
no<strong>di</strong>: le informazioni atomiche hanno <strong>un</strong>o stato che <strong>di</strong>pende <strong>di</strong>rettamente<br />
dalla qualità delle coppie “”, mentre le informazioni primitive<br />
assumono <strong>un</strong> valore <strong>di</strong> stato che <strong>di</strong>pende dalle informazioni che aggregano<br />
ed incapsulano. Quin<strong>di</strong>, anche in questo caso, si prevede <strong>un</strong> meccanismo <strong>di</strong><br />
propagazione dello stato che, a partire dai no<strong>di</strong> in fondo alla gerarchia, risale<br />
gli antenati (dai figli verso i genitori) fino al capostipite assegnando, man<br />
mano, lo stato ai no<strong>di</strong> attraversati.<br />
4.5.1 Lo stato delle informazioni<br />
Lo stato delle informazioni atomiche<br />
Un’informazione atomica può essere soggetta a mo<strong>di</strong>fiche oppure può essere<br />
memorizzata in modo definitivo. Ortogonalmente esistono dei parametri<br />
per stabilire la qualità dell’informazione. Lo stato QUALITY in<strong>di</strong>ca la qualità<br />
dei dati ed è rappresentato in figura 4.6 con il formalismo delle state<br />
chart.<br />
Un’informazione atomica può essere <strong>un</strong>a bozza (draft), ammissibile sintatticamente<br />
(allowable) oppure accurata sintatticamente (accurate). La transizione<br />
dello stato allowable avviene quando è verificato il controllo sintattico,<br />
se poi sono verificate anche le restrizioni lo stato passa in accurate. Con re-<br />
98
Modello dell’informazione <strong>versionata</strong> D3IM Lo stato <strong>di</strong> <strong>un</strong> documento<br />
QUALITY<br />
write-open<br />
[in changing]<br />
write-open<br />
[in changing]<br />
accurate<br />
draft<br />
allowable<br />
set<br />
soft allowable<br />
set<br />
syntax check<br />
[verified]<br />
restriction check<br />
[verified]<br />
Figura 4.6: Stati <strong>di</strong> <strong>un</strong>’informazione atomica.<br />
strizioni si intendono tutte quelle regole che limitano il valore ad <strong>un</strong> intervallo<br />
o ad <strong>un</strong> particolare insieme <strong>di</strong> valori.<br />
Lo stato delle informazioni primitive<br />
Come mostrato in figura 4.7, il comportamento dell’informazione primitiva<br />
è <strong>un</strong> AND <strong>di</strong> stati delle informazioni aggregate a cui se ne aggi<strong>un</strong>gono<br />
ulteriori due, similmente definiti a quelli <strong>di</strong> <strong>un</strong>’informazione atomica, ma<br />
propri <strong>di</strong> questa informazione. La definizione delle state chart è ricorsiva<br />
e la complessità <strong>di</strong>pende dal numero <strong>di</strong> livelli della gerarchia associata al<br />
documento.<br />
Con<strong>di</strong>zione necessaria e non sufficiente affinché <strong>un</strong>’informazione primitiva<br />
risulti consistente è che ogni informazione aggregata (o tutte atomiche o tutte<br />
primitive) sia singolarmente accurata. Per gli altri stati le seguenti con<strong>di</strong>zioni<br />
sono anche sufficienti:<br />
1. è nello stato <strong>di</strong> bozza (draft), se almeno <strong>un</strong>’informazione aggregata è<br />
nello stato <strong>di</strong> bozza;<br />
2. è nello stato <strong>di</strong> ammissibile (allowable), se ness<strong>un</strong>a informazione aggregata<br />
è nello stato <strong>di</strong> bozza ed almeno <strong>un</strong>a nello stato <strong>di</strong> ammissibile;<br />
H<br />
99
Modello dell’informazione <strong>versionata</strong> D3IM Lo stato <strong>di</strong> <strong>un</strong> documento<br />
info_1 ... info_N<br />
write-open<br />
[this in<br />
changing]<br />
write-open<br />
[this in<br />
changing]<br />
write-open<br />
[this in<br />
changing]<br />
consistency<br />
draft<br />
allowable<br />
accurate<br />
set<br />
soft hard<br />
Figura 4.7: Stati <strong>di</strong> <strong>un</strong>’informazione primitiva.<br />
set<br />
syntax check<br />
restriction<br />
check<br />
3. è nello stato <strong>di</strong> accurata (accurate) sintatticamente, se ogni informazione<br />
aggregata è accurata sintatticamente.<br />
In tabella 4.1 sono riportate schematicamente le regole <strong>di</strong> transizione per<br />
determinare lo stato nel caso in cui l’aggregazione sia <strong>di</strong> sole due informazioni.<br />
Per N informazioni basterà applicare tali regole iterativamente a coppie <strong>di</strong><br />
informazioni <strong>di</strong>sgi<strong>un</strong>te per N-1 volte.<br />
Per le informazioni primitive è possibile <strong>un</strong> ulteriore controllo che riguarda<br />
la verifica della consistenza. Questo permette <strong>di</strong> far transitare lo stato da<br />
accurate a consistency.<br />
Con controllo della consistenza si intende la verifica della coerenza logica<br />
e/o semantica tra le informazioni aggregate. Lo stato consistency in<strong>di</strong>ca<br />
quin<strong>di</strong> che l’informazione complessiva, costituita da <strong>un</strong>a serie <strong>di</strong> informazioni<br />
più semplici, è corretta nella sua globalità. Questa è <strong>un</strong>’affermazione più<br />
H<br />
100
Modello dell’informazione <strong>versionata</strong> D3IM Lo stato <strong>di</strong> <strong>un</strong> documento<br />
Info 2<br />
Draft<br />
Info 1<br />
Draft Allowable<br />
Draft<br />
Draft<br />
Allowable Draft Allowable<br />
Accurate Draft Allowable<br />
Accurate<br />
Draft<br />
Allowable<br />
Accurate<br />
Tabella 4.1: Mappa per la determinazione degli stati.<br />
forte rispetto al <strong>di</strong>chiarare che tutte le informazioni più semplici, prese singolarmente,<br />
sono corrette. Si consideri ad esempio <strong>un</strong>a via ed <strong>un</strong> numero civico<br />
<strong>di</strong> <strong>un</strong> in<strong>di</strong>rizzo: il nome della via può essere accurato così come il numero<br />
civico, però in quella via potrebbe non esistere quel numero.<br />
101
Parte III<br />
Dai modelli teorici<br />
all’architettura concreta
Capitolo<br />
5<br />
Architettura CISA<br />
Il principale obiettivo che si intende raggi<strong>un</strong>gere in questo progetto è<br />
rappresentare l’informazione da <strong>un</strong> p<strong>un</strong>to <strong>di</strong> vista concettuale in modo che<br />
sia possibile:<br />
• prevedere <strong>un</strong> metodo per rendere l’informazione con<strong>di</strong>visa;<br />
• ridurre la complessità della com<strong>un</strong>icazione.<br />
Come espresso in [Pra03] <strong>un</strong> Information Model non si addentra nei dettagli,<br />
ma cerca <strong>di</strong> catturare le astrazioni ed i requisiti fondamentali. Uno<br />
dei principali vantaggi <strong>di</strong> <strong>un</strong> Information Model è proprio la capacità <strong>di</strong> dare<br />
vita a più Data Model. La possibilità <strong>di</strong> generare molti Data Model dallo<br />
stesso Information Model è in<strong>di</strong>ce <strong>di</strong> scalabilità ed adattabilità del <strong>modello</strong> a<br />
contesti <strong>di</strong>versi. Inoltre, per la realizzazione, è possibile scegliere tra <strong>un</strong>a vasta<br />
gamma <strong>di</strong> standard e tecnologie già esistenti, se rispondenti alle esigenze.<br />
D’altra parte questa prospettiva rappresenta anche <strong>un</strong>a forte restrizione che<br />
consiste nel dover rimanere ad <strong>un</strong> elevato livello <strong>di</strong> astrazione. La sottile linea<br />
che <strong>di</strong>vide il <strong>modello</strong> astratto dai rispettivi modelli concreti non è sempre <strong>di</strong><br />
facile identificazione.<br />
Per poter applicare i modelli descritti in precedenza occorre quin<strong>di</strong> passare<br />
da <strong>un</strong>a schematizzazione astratta ad <strong>un</strong>a più concreta. Di seguito verrà proposta<br />
<strong>un</strong>’architettura che implementa le caratteristiche astratte del <strong>modello</strong>,
Architettura CISA Visione stratificata <strong>di</strong> CISA<br />
creata con lo scopo <strong>di</strong> costituire <strong>un</strong>’infrastruttura sulla quale basare specifiche<br />
applicazioni. Nella definizione dell’architettura si delineano dei Data Model<br />
conformi all’Information Model <strong>di</strong> riferimento, ma viene quin<strong>di</strong> lasciata la<br />
massima libertà per quanto riguarda la definizione dell’applicazione.<br />
Il progetto Collaborative Information System Architecture, in breve CISA,<br />
definisce <strong>un</strong>a stratificazione <strong>di</strong> sistemi per rendere efficace ed efficiente la collaborazione<br />
tra utenti in rete. Il sistema non è pensato solo come riferimento<br />
per lo sviluppo <strong>di</strong> piattaforme per le attività collaborative, ma più in generale<br />
come ambiente operativo <strong>di</strong>sponibile all’utente per svolgere attività tra<strong>di</strong>zionali<br />
e concorrenti. Tale ambiente consentirà <strong>di</strong> sfruttare in modo trasparente<br />
la natura <strong>di</strong>stribuita che sta alla base.<br />
5.1 Visione stratificata <strong>di</strong> CISA<br />
L’orientamento verso <strong>un</strong>’architettura stratificata è stato suggerito da S.<br />
Melnik e S. Decker i quali, in [MD00], evidenziano come questo approccio<br />
risulti conveniente non solo per l’internetworking, ma anche per la gestione<br />
dei dati nello lo scenario del web semantico. Il termine interdataworking<br />
è stato introdotto in questo contesto sulla base dell’analogia esistente fra<br />
il <strong>modello</strong> stratificato da loro proposto e il <strong>modello</strong> stratificato utilizzato<br />
convenzionalmente nelle reti <strong>di</strong> computer.<br />
In questo modo è possibile ridurre considerevolmente la complessità della<br />
soluzione al problema. A tal fine sono stati identificati dei livelli (Application,<br />
Virtual Repository, Structure, Replica Management e Me<strong>di</strong>um Dependent),<br />
tenendo presenti i principi <strong>di</strong>:<br />
• separation of concern: ogni livello viene definito trattando separatamente<br />
i soli problemi che riguardano il livello stesso, mettendo da parte<br />
problematiche inessenziali o che verranno trattate da altri livelli;<br />
• information hi<strong>di</strong>ng: ogni livello espone all’esterno solo l’informazione<br />
in<strong>di</strong>spensabile alla com<strong>un</strong>icazione con i livelli a<strong>di</strong>acenti, mantenendo<br />
interna ogni altra necessaria informazione;<br />
• good enough: la progettazione deve essere sufficiente a risolvere il problema,<br />
senza pretendere il miglior risultato possibile in tutte le circostanze.<br />
104
Architettura CISA Visione stratificata <strong>di</strong> CISA<br />
Ogni livello è tenuto a rispondere in maniera corretta alle chiamate che<br />
gli competono e che verranno generate dai livelli ad esso a<strong>di</strong>acenti. La logica<br />
interna, con cui le f<strong>un</strong>zioni <strong>di</strong> competenza verranno elaborate, non è visibile<br />
dall’esterno. Naturalmente la strategia good enough risulta vincente solo<br />
se <strong>un</strong>ita alla capacità del sistema <strong>di</strong> crescere e migliorarsi nel tempo. Una<br />
possibilità per ottenere questa caratteristica è renderlo aperto in tutto il suo<br />
ciclo <strong>di</strong> sviluppo (analisi, progettazione, implementazione e validazione).<br />
Come nel caso del web semantico i vari layer operano ad <strong>un</strong> livello <strong>di</strong><br />
astrazione <strong>di</strong>verso per quel che riguarda il concetto <strong>di</strong> informazione (figura<br />
5.1).<br />
Quelli più alti percepiscono l’informazione come entità complessa sotto<br />
forma <strong>di</strong> documento. Ogni documento è costituito da <strong>un</strong>a serie <strong>di</strong> informazioni<br />
elementari legate da relazioni strutturali.<br />
Spostando l’attenzione verso i livelli interme<strong>di</strong> gli aspetti strutturali dell’informazione<br />
vengono meno: l’informazione è vista come tante <strong>un</strong>ità elementari<br />
in<strong>di</strong>pendenti.<br />
Infine per i livelli più bassi l’informazione è semplicemente <strong>un</strong>a particolare<br />
co<strong>di</strong>fica delle entità definite ai livelli superiori, in altre parole “sequenze <strong>di</strong><br />
byte” (file e record <strong>di</strong> database).<br />
Livello <strong>di</strong> astrazione<br />
<strong>dell'informazione</strong><br />
Informazioni<br />
complesse<br />
(documenti).<br />
Informazioni<br />
elementari<br />
(no<strong>di</strong>).<br />
Byte.<br />
(file, database).<br />
Application<br />
Layer<br />
Virtual Repository<br />
Layer<br />
Structure<br />
Layer<br />
Replica Management<br />
Layer<br />
Me<strong>di</strong>um Dependent<br />
Layer<br />
Figura 5.1: Livelli dell’architettura CISA.<br />
Con questa prospettiva, nel presente lavoro, si parla <strong>di</strong> livello (o layer)<br />
per fare riferimento ad <strong>un</strong> contenitore logico <strong>di</strong> sottosistemi concreti e in<strong>di</strong>pendenti<br />
che manipolano ed effettuano specifiche operazioni sull’informazione<br />
vista come entità astratta. Tali sottosistemi interagiscono fornendo o<br />
105
Architettura CISA Visione stratificata <strong>di</strong> CISA<br />
richiedendo servizi ad altri sottosistemi appartenenti allo stesso livello logico<br />
oppure ad altri livelli a<strong>di</strong>acenti.<br />
Principalmente CISA descrive i livelli Virtual Repository, Structure e Replica<br />
Management. Vincolare e dettagliare gli strati Application e Me<strong>di</strong>um<br />
Dependent, alle estremità dello stack, non risulta conveniente ai fini, rispettivamente,<br />
della crescita del sistema e dell’adattabilità verso il passato. Per<br />
quanto concerne la crescita viene infatti lasciata la massima libertà per quel<br />
che riguarda la definizione del contesto applicativo che può essere <strong>di</strong>versificato<br />
e, equivalentemente, non vengono fissate specifiche stringenti sul formato<br />
<strong>di</strong> storage dei dati. Quest’ultimo aspetto permette quin<strong>di</strong> <strong>di</strong> <strong>di</strong>versificare<br />
anche le soluzioni <strong>di</strong> basso livello, aspetto che garantisce l’adattabilità con il<br />
passato ovvero la possibilità <strong>di</strong> riutilizzare, definendo dei Me<strong>di</strong>um Dependent<br />
ad hoc, i sistemi legacy attualmente in possesso delle organizzazioni. Non<br />
è infatti possibile ipotizzare <strong>un</strong>a completa conversione dello storico dei documenti<br />
in formato elettronico in loro possesso in <strong>un</strong> nuovo formato, i quali<br />
dovranno pertanto essere riutilizzati all’interno del sistema “così come sono”.<br />
Si noti come questo approccio equivalga a quello utilizzato nella definizione<br />
della pila Internet nella quale è stata lasciata la massima libertà per quanto<br />
riguarda la definizione del livello applicativo e dei livelli inferiori a quello <strong>di</strong><br />
rete.<br />
Per quanto riguarda la modalità <strong>di</strong> interazione fra i vari livelli è stato scelto<br />
<strong>di</strong> ricorrere ad <strong>un</strong> approccio REST-like (Representational State Transfer,<br />
REST [Fie00, Res05]). REST è stato introdotto da Roy Thomas Fiel<strong>di</strong>ng<br />
ed è definito tramite <strong>un</strong> insieme <strong>di</strong> linee guida seguendo le quali si realizza<br />
<strong>un</strong>’architettura strutturata come il World Wide Web il quale ha, nell’ultimo<br />
decennio, in<strong>di</strong>scutibilmente <strong>di</strong>mostrato <strong>di</strong> essere scalabile e per questo è stato<br />
preso come riferimento.<br />
L’interazione avviene tramite il para<strong>di</strong>gma client/server: ogni livello è<br />
client <strong>di</strong> quello inferiore (al quale richiede servizi) e server <strong>di</strong> quello superiore<br />
(al quale fornisce dei servizi). Quin<strong>di</strong>, per ogni coppia <strong>di</strong> livelli, viene<br />
definito <strong>un</strong> protocollo <strong>di</strong> com<strong>un</strong>icazione che, come HTTP (ve<strong>di</strong> [FIG + 99]), è<br />
request/response. Il para<strong>di</strong>gma convenzionale <strong>di</strong> interazione fra l’utente e il<br />
sistema è <strong>di</strong> tipo pull: in seguito ad <strong>un</strong>’azione dell’utente la pila viene attraversata<br />
da <strong>un</strong>a sequenza <strong>di</strong> request che si sviluppa dall’alto verso il basso e<br />
da <strong>un</strong>a sequenza corrispondente <strong>di</strong> response che la percorre in senso opposto.<br />
Ogni livello si attiva per generare la response a seguito <strong>di</strong> ogni request proveniente<br />
dal livello superiore (o da <strong>un</strong>’azione dell’utente per quanto riguarda<br />
106
Architettura CISA Visione stratificata <strong>di</strong> CISA<br />
il livello applicativo), eventualmente effettuando delle richieste ai livelli inferiori<br />
(come evidenziato in figure 5.2) per richiedere l’espletamento <strong>di</strong> servizi<br />
necessari per il completamento dell’operazione.<br />
Richiesta dell'utente Risposta all'utente<br />
Livelli CISA<br />
Request - Response<br />
Tempo<br />
Figura 5.2: Para<strong>di</strong>gma <strong>di</strong> interazione request/response.<br />
Un meccanismo <strong>di</strong> notifica in modalità push, che può risultare utile in svariati<br />
contesti (ad esempio per inoltrare segnalazioni in tempo reale all’utente<br />
a seguito <strong>di</strong> eventi che si sono verificati nel sistema), può essere introdotto in<br />
<strong>un</strong>a fase successiva dello sviluppo del progetto. Allo stato attuale è infatti<br />
possibile ipotizzare che tale modalità operativa possa essere introdotta senza<br />
interferire con il lavoro già svolto (rispetto al quale è <strong>un</strong>a caratteristica del<br />
tutto ortogonale) ricorrendo a protocolli ed a canali <strong>di</strong> com<strong>un</strong>icazione de<strong>di</strong>cati.<br />
Risulta infine utile osservare come la modalità push possa essere simulata<br />
in presenza della sola modalità pull (a scapito dell’efficienza operativa) tramite<br />
polling. Questo permette quin<strong>di</strong> <strong>di</strong> concludere che, almeno al momento,<br />
è possibile rimandare l’inserimento <strong>di</strong> tale modalità operativa senza perdere<br />
in generalità.<br />
Nei capitoli seguenti verranno descritti in modo approfon<strong>di</strong>to i livelli <strong>di</strong><br />
CISA, mentre l’analisi dei protocolli e delle interfacce <strong>di</strong> com<strong>un</strong>icazione verrà<br />
affrontata dettagliatamente nel capitolo 9.<br />
107
Architettura CISA Visione stratificata <strong>di</strong> CISA<br />
5.1.1 Application Layer<br />
A questo livello appartengono non solo tutte le applicazioni specializzate<br />
per trattare i documenti in particolari contesti come i tool <strong>di</strong> gestione<br />
e <strong>di</strong> authoring, ma anche tutti i sottosistemi utilizzati <strong>di</strong>rettamente (o<br />
in<strong>di</strong>rettamente) dall’utente.<br />
Si prevede che il livello Application sia costituito da tre sottolivelli: <strong>di</strong><br />
presentazione, <strong>di</strong> elaborazione e <strong>di</strong> interfaccia. La presentazione pone l’informazione<br />
in <strong>un</strong>a forma tale da facilitarne la fruizione (lettura e scrittura) da<br />
parte dell’utente; il sottolivello <strong>di</strong> elaborazione definisce tutti gli algoritmi <strong>di</strong><br />
livello applicativo atti a gestire il f<strong>un</strong>zionamento della specifica applicazione;<br />
l’interfaccia è necessaria per la com<strong>un</strong>icazione, tramite appositi protocolli,<br />
con il layer sottostante. In questi termini la sottoparte <strong>di</strong> presentazione<br />
dell’Application Layer rappresenta il front-end dell’architettura.<br />
Nel sotto paragrafo 4.2.1 (a pagina 82) sono stati introdotti gli LRI (Logical<br />
Resource Identifier) come particolari HFN. Tali nomi rappresentano lo<br />
spazio <strong>di</strong> in<strong>di</strong>rizzi da utilizzare a questo livello. Può essere ammesso l’uso <strong>un</strong><br />
sistema <strong>di</strong> nomi <strong>di</strong>verso purché sia previsto <strong>un</strong> meccanismo <strong>di</strong> traduzione da<br />
tale sistema a LRI.<br />
5.1.2 Virtual Repository Layer<br />
A questo livello appartengono le entità dell’ambiente virtuale definito nel<br />
capitolo 3: Avatar, Stuff, Group, World. Ogni entità ha <strong>un</strong>o o più nomi virtuali<br />
(LRI) che la identificano ai quali è associato <strong>un</strong> in<strong>di</strong>rizzo <strong>un</strong>ivoco (PRI):<br />
il livello Virtual Repository provvede alla relativa risoluzione, ve<strong>di</strong> sotto paragrafo<br />
4.2.1 a pagina 82. L’informazione è mantenuta in documenti D3IM<br />
(definiti nel capitolo 4) che, in questo contesto, sono <strong>un</strong>a specializzazione degli<br />
Stuff e sono capaci <strong>di</strong> mappare entità astratte come libri, certificati, manuali,<br />
tabelle <strong>di</strong> database, record, capitoli, paragrafi <strong>di</strong> testo, sezioni, documenti <strong>di</strong><br />
identità, e così via, in entità maneggiabili dagli Avatar. Per ogni documento<br />
sono definite almeno le stesse operazioni <strong>di</strong> base previste per gli Stuff e che<br />
verranno trattate con maggiore dettaglio nel prossimo sotto paragrafo.<br />
È onere del livello Virtual Repository validare lo stato del documento<br />
(come descritto nel paragrafo 4.5 a pagina 98) e permettere la navigazione<br />
nell’<strong>un</strong>iverso virtuale.<br />
In contrapposizione al livello applicativo rientra a pieno titolo, così come<br />
tutti i livelli inferiori, nel back-end dell’architettura.<br />
108
Architettura CISA Visione stratificata <strong>di</strong> CISA<br />
Operazioni <strong>di</strong> base sulle entità<br />
Alla luce delle definizioni delle entità, presentate nel capitolo 3, è possibile<br />
stabilire con maggior dettaglio le operazioni effettuabili su <strong>di</strong> esse.<br />
Produttori, consumatori e gestori dell’informazione agiscono su World,<br />
Avatar, Group e Stuff conformemente ai permessi che i rispettivi Avatar<br />
detengono. In <strong>un</strong>a prospettiva ad alto livello è però più semplice pensare<br />
che agiscano <strong>di</strong>rettamente, assumendo che gli Avatar si comportino in modo<br />
trasparente. Ciò permette <strong>di</strong> definire l’interfaccia dell’ambiente dal p<strong>un</strong>to <strong>di</strong><br />
vista <strong>di</strong> chi lo utilizzerà.<br />
In <strong>un</strong>’attività collaborativa il confine tra i tre ruoli sopra menzionati è ben<br />
definito, ma non è altrettanto imme<strong>di</strong>ato attribuire l’insieme delle operazioni.<br />
La partecipazione alle attività è variamente determinata e valutabile, ad<br />
esempio chi prima si comporta da produttore può, <strong>un</strong> istante dopo, comportarsi<br />
da consumatore e così via. È quin<strong>di</strong> conveniente introdurre anche <strong>un</strong>a<br />
classificazione più incentrata sulle in<strong>di</strong>vidualità.<br />
User<br />
Admin<br />
Producer Consumer Management<br />
Gli utenti introducono<br />
informazioni nel<br />
sistema<br />
L'amministratore<br />
definisce permessi e<br />
regole <strong>di</strong> produzione<br />
<strong>dell'informazione</strong><br />
Gli utenti recepiscono o<br />
prelevano informazioni<br />
dal sistema<br />
L'amministratore<br />
definisce permessi e<br />
regole <strong>di</strong> fruizione<br />
<strong>dell'informazione</strong><br />
Gli utenti sono<br />
coor<strong>di</strong>nati da <strong>un</strong><br />
supervisione<br />
L'amministratore<br />
definisce i compiti<br />
del gestore<br />
Tabella 5.1: Decomposizione dei ruoli degli utenti.<br />
La complessità del sistema non permette <strong>di</strong> stabilire a priori tutte le<br />
tipologie <strong>di</strong> utenti. Ciò è anche conseguenza del fatto che si realizza <strong>un</strong><br />
ambiente <strong>di</strong>namico e non vincolato da rigide regole predeterminate, capace<br />
<strong>di</strong> adattarsi al maggior numero <strong>di</strong> contesti. È com<strong>un</strong>que possibile identificare<br />
due principali categorie <strong>di</strong> utilizzatori, così come avviene nei sistemi operativi:<br />
utenti generici e amministratori (tabella 5.1), tenendo presente che il sistema<br />
dovrà anche essere in grado <strong>di</strong> catturare eventuali sfumature interme<strong>di</strong>e.<br />
109
Architettura CISA Visione stratificata <strong>di</strong> CISA<br />
Col termine utente si intendono non solo persone, ma anche applicazioni<br />
o sistemi caratterizzati dal fatto che risultano esterni all’ambiente virtuale.<br />
Ad esempio potrebbero essere client o agenti intelligenti.<br />
Nei seguenti paragrafi verranno dettagliate le f<strong>un</strong>zionalità delle entità presentate<br />
nel capitolo 3, nel modo in cui sono percepite dagli utenti. Sarà dato<br />
particolare rilievo ai principali servizi che dovranno fornire, senza rivelare la<br />
propria struttura interna, e agli attori che li possono invocare.<br />
Operazioni sugli Avatar. Un utente, prima <strong>di</strong> avviare qual<strong>un</strong>que altra<br />
operazione, dovrà stabilire <strong>un</strong>a connessione col proprio Avatar. Ciò avviene<br />
attraverso le f<strong>un</strong>zioni <strong>di</strong> login e logout che stabiliscono l’inizio e la fine <strong>di</strong><br />
<strong>un</strong>a sessione <strong>di</strong> collegamento e determinano le transizioni tra gli stati interni<br />
on-line ed off-line dell’Avatar.<br />
Generalmente è richiesta l’autenticazione tra utente e Avatar tale da realizzare<br />
la bi<strong>un</strong>ivocità dell’identità e delle responsabilità. Questo è <strong>un</strong> requisito<br />
forte, ma necessario quando l’Avatar dovrà trattare dati sensibili, compiere<br />
azioni a valore legale o, più in generale, azioni <strong>di</strong> particolare rilevanza<br />
relativamente al contesto <strong>di</strong> interesse.<br />
Ad ogni utente è concessa <strong>un</strong>a certa libertà <strong>di</strong> movimento per collocare<br />
il suo alter-ego virtuale nei mon<strong>di</strong>, quin<strong>di</strong> esisterà <strong>un</strong>a f<strong>un</strong>zionalità per simulare<br />
gli spostamenti. Lo stesso utente potrà essere contemporaneamente<br />
presente in più <strong>di</strong> <strong>un</strong> World, attraverso l’uso <strong>di</strong> più Avatar, a ciasc<strong>un</strong>o dei<br />
quali corrisponderà <strong>un</strong>a sessione <strong>di</strong> login.<br />
Come accennato nel capitolo 3, l’Avatar è <strong>un</strong> processo che deve essere<br />
in grado <strong>di</strong> evolvere in<strong>di</strong>pendentemente dallo stato dell’utente: può subire<br />
operazioni e recepire messaggi per conto del suo proprietario anche quando<br />
quest’ultimo è scollegato, permettendo <strong>di</strong> realizzare sia interazioni sincrone<br />
che asincrone con le altre entità dell’ambiente.<br />
Il profilo è definito come l’insieme <strong>di</strong> informazioni personali (ad esempio<br />
età, residenza, citta<strong>di</strong>nanza, professione, hobby) che possono essere aggi<strong>un</strong>te,<br />
eliminate o nascoste entro i limiti stabiliti dal gestore del Group <strong>di</strong> appartenenza<br />
o dal World visitato. Ad esempio alc<strong>un</strong>i World potrebbero imporre<br />
che alc<strong>un</strong>i dati debbano essere in chiaro per motivi amministrativi.<br />
La creazione, la cancellazione e l’assegnazione dei permessi è a carico<br />
dell’amministratore, il quale è <strong>un</strong> super-utente. Tramite il suo Avatar potrà<br />
eseguire, in modo del tutto trasparente, queste operazioni su tutti gli Avatar<br />
con minori <strong>di</strong>ritti.<br />
110
Architettura CISA Visione stratificata <strong>di</strong> CISA<br />
Operazioni sui Group. Per i Group non ha senso parlare <strong>di</strong> sessioni <strong>di</strong><br />
login occorre invece parlare <strong>di</strong> appartenenza e non appartenenza al gruppo.<br />
Sebbene sia l’Avatar ad essere sottoscritto ad <strong>un</strong> Group, si può assumere per<br />
transitività che lo sia l’utente.<br />
I Group sono entità <strong>di</strong>namiche poiché possono variare nel tempo riguardo<br />
alla struttura, al numero <strong>di</strong> utenti affiliati ed ai requisiti <strong>di</strong> appartenenza.<br />
Alc<strong>un</strong>e f<strong>un</strong>zionalità assegnate all’utente e all’amministratore possono apparire<br />
duplicate. La principale <strong>di</strong>fferenza consiste nell’entità su cui vengono<br />
effettuate. Per <strong>un</strong> utente saranno riflessive, cioè applicabili solamente su se<br />
stesso, per <strong>un</strong> amministratore <strong>di</strong> gruppo anche sugli altri.<br />
L’avvio della sottoscrizione, cancellazione o espulsione può essere innescato<br />
anche con procedure automatiche. Ad esempio <strong>un</strong>o Stuff capace <strong>di</strong><br />
monitorare l’evoluzione dei profili degli Avatar, può avviare <strong>un</strong>a <strong>di</strong> queste<br />
operazioni al verificarsi <strong>di</strong> particolari con<strong>di</strong>zioni (in modo analogo ai trigger<br />
nel contesto delle basi <strong>di</strong> dati).<br />
Operazioni sui World. L’operazione <strong>di</strong> ingresso nel World permette <strong>di</strong><br />
navigare nell’ambiente virtuale. L’utente che tenta <strong>di</strong> entrare potrebbe non<br />
aver stabilito <strong>un</strong>a sessione <strong>di</strong> login, per cui deve effettuare la preventiva scelta<br />
dell’Avatar che intende muovere nel mondo. L’uscita è <strong>un</strong>a f<strong>un</strong>zionalità<br />
sottintesa, nel senso che l’utente permane nel World solamente per il tempo<br />
necessario alla ricezione dei contenuti informativi.<br />
Da <strong>un</strong> p<strong>un</strong>to <strong>di</strong> vista strutturale i World hanno delle forti similitu<strong>di</strong>ni<br />
con le <strong>di</strong>rectory del file system, mentre da <strong>un</strong> p<strong>un</strong>to <strong>di</strong> vista <strong>di</strong> meccanismi<br />
<strong>di</strong> com<strong>un</strong>icazione, assomigliano alle pagine Web.<br />
Il tempo <strong>di</strong> permanenza nel mondo corrisponde al tempo necessario per<br />
ottenerne i contenuti (sotto mon<strong>di</strong> e risorse). L’uscita è quin<strong>di</strong> determinata<br />
in automatico alla conclusione delle operazioni legate all’acquisizione<br />
dell’informazione. Dal lato World non è previsto il mantenimento dello<br />
stato dell’utente, tale compito però può essere eventualmente demandato<br />
all’Avatar.<br />
Il successo <strong>di</strong> qual<strong>un</strong>que operazione ha come precon<strong>di</strong>zione la verifica dei<br />
permessi attuata tramite il confronto degli attributi del World con il profilo<br />
dell’utente.<br />
Conoscere gli Stuff <strong>di</strong>sponibili è <strong>un</strong> requisito fondamentale per poter avviare<br />
qual<strong>un</strong>que attività collaborativa o cooperativa o <strong>di</strong> interazione. L’identificazione<br />
dell’oggetto mira all’uso dei suoi servizi.<br />
111
Architettura CISA Visione stratificata <strong>di</strong> CISA<br />
L’amministratore ha il compito <strong>di</strong> stabilire quali Avatar sono abilitati ad<br />
entrare impostando opport<strong>un</strong>amente gli attributi del World come ad esempio<br />
la visibilità, il numero massimo <strong>di</strong> richieste contemporanee e gli orari <strong>di</strong><br />
accesso.<br />
L’aggi<strong>un</strong>ta e la cancellazione degli Stuff, può essere concessa a qual<strong>un</strong>que<br />
Avatar, ma <strong>di</strong> principio sono attribuite al solo amministratore.<br />
Operazioni sugli Stuff. Ogni risorsa risiede in almeno <strong>un</strong> World. La<br />
copia e la replicazione consentono <strong>di</strong> posizionarla in luoghi <strong>di</strong>versi. Mentre la<br />
duplicazione garantisce l’uguaglianza degli Stuff fino all’istante antecedente<br />
la prima mo<strong>di</strong>fica, la replicazione garantisce l’identità degli Stuff, a meno dei<br />
tempi <strong>di</strong> latenza del meccanismo <strong>di</strong> sincronizzazione.<br />
L’utente che crea <strong>un</strong>o Stuff, tramite il suo Avatar, ne determina la proprietà<br />
e ne assume il ruolo <strong>di</strong> amministratore. Il proprietario è l’<strong>un</strong>ico che<br />
può effettuare la cancellazione. Nel caso <strong>di</strong> repliche, cancellare significa eliminarle<br />
tutte, mentre nel caso <strong>di</strong> copie, essendo tra loro in<strong>di</strong>pendenti, significa<br />
eliminarne solamente <strong>un</strong>a.<br />
Come già <strong>di</strong>scusso, l’Avatar appartiene ad almeno <strong>un</strong> Group, quin<strong>di</strong> tutti<br />
gli affiliati al gruppo, salvo <strong>di</strong>versa in<strong>di</strong>cazione, ottengono stessi <strong>di</strong>ritti e<br />
responsabilità sullo Stuff.<br />
L’apertura e la chiusura determinano l’acquisizione e il rilascio della risorsa.<br />
In questo intervallo <strong>di</strong> tempo si parla anche <strong>di</strong> apertura e chiusura<br />
della sessione che si possono classificare in base ai vari gra<strong>di</strong> <strong>di</strong> lock. L’accesso<br />
dovrà essere regolato da meccanismi <strong>di</strong> sicurezza che verificheranno gli<br />
effettivi privilegi dell’utente in modo analogo a quanto previsto per i World.<br />
5.1.3 Structure Layer<br />
Questo livello si occupa della gestione del versioning dell’informazione<br />
secondo i principi descritti nel paragrafo 4.4 a pagina 91. Trattandosi del<br />
principale argomento <strong>di</strong> interesse nel presente lavoro <strong>di</strong> tesi questo livello<br />
verrà descritto dettagliatamente nel capitolo 6.<br />
5.1.4 Replica Management Layer<br />
Il livello Replica Management è specializzato nella gestione delle sorgenti e<br />
delle destinazioni eterogenee dei dati, ospitate nel Me<strong>di</strong>um Dependent Layer.<br />
112
Architettura CISA Visione stratificata <strong>di</strong> CISA<br />
Replicare <strong>un</strong>’entità significa copiarla in <strong>di</strong>fferenti host e mantenere le copie<br />
equivalenti nel tempo. Le repliche delle informazioni, che sono identificate<br />
attraverso i PRI, sono in<strong>di</strong>rizzate tramite gli URL [BLMM94], in quanto la<br />
logica dello strato ha bisogno <strong>di</strong> accedere a delle risorse concrete e pertanto<br />
è presente <strong>un</strong> opport<strong>un</strong>o meccanismo <strong>di</strong> risoluzione (LS, capitolo 8).<br />
I compiti <strong>di</strong> questo livello riguardano:<br />
• la sincronizzazione delle repliche;<br />
• la conversione dei formati dei dati<br />
(ad esempio database↔database, database↔file system).<br />
A questo livello deve essere garantita la consistenza delle repliche. I vantaggi<br />
della tecnica active, nota anche col nome <strong>di</strong> state-machine approach,<br />
sono evidenziati in [CM03]. Una volta stabilito qual è la replica <strong>di</strong> riferimento,<br />
in<strong>di</strong>cata col nome <strong>di</strong> replica master, tutti gli accessi <strong>di</strong>struttivi, ovvero<br />
quelli che attuano mo<strong>di</strong>fiche <strong>di</strong> qualsiasi entità ai dati, confluiscono in essa.<br />
In pratica tutte le operazioni <strong>di</strong> mo<strong>di</strong>fica vengono effettuate prima sulla<br />
replica master e successivamente applicate alle repliche secondarie; questa<br />
modalità operativa permette <strong>di</strong> gestire la concorrenza negli accessi <strong>di</strong>struttivi<br />
attraverso <strong>un</strong> opport<strong>un</strong>o meccanismo <strong>di</strong> lock.<br />
Le repliche si possono trovare nello stato <strong>di</strong> lock o <strong>un</strong>lock, che in<strong>di</strong>ca se<br />
sulle repliche è stata o meno aperta <strong>un</strong>a sessione <strong>di</strong> scrittura. Acquisire <strong>un</strong>a<br />
replica significa acquisire tutte le repliche. Per le operazioni <strong>di</strong> lettura non<br />
è necessario il meccanismo <strong>di</strong> lock anche se durante <strong>un</strong>a sessione tutte le<br />
operazioni <strong>di</strong> scrittura e/o <strong>di</strong> lettura effettuate, avvengono in modo atomico.<br />
La scelta della replica master può essere fissata a priori oppure effettuata<br />
con opport<strong>un</strong>i algoritmi <strong>di</strong>stribuiti <strong>di</strong> elezione che possono tenere in<br />
considerazione vari parametri <strong>di</strong> costo (eventualmente pesati) come ad esempio<br />
il carico <strong>di</strong> richieste dei no<strong>di</strong>, la <strong>di</strong>stanza geografica rispetto al sistema<br />
autoritativo, la posizione nella topologia della rete.<br />
Il principale servizio che Replica Management Layer offre al livello Structure<br />
è la “valorizzazione” cioè la ricerca, l’acquisizione, la conversione e la<br />
memorizzazione dei valori. In generale le informazioni relative allo stato sono<br />
memorizzate in <strong>un</strong> qualsiasi host. Il livello Replica Management decide il<br />
sito da cui prelevare o su cui scrivere le informazioni in base all’URL della<br />
replica, realizzando <strong>un</strong>a sorta <strong>di</strong> instradamento delle richieste.<br />
Gli obiettivi del servizio <strong>di</strong> gestione delle repliche (ve<strong>di</strong> [CM03]) consistono<br />
nell’aumentare:<br />
113
Architettura CISA Visione stratificata <strong>di</strong> CISA<br />
• la <strong>di</strong>sponibilità del sistema;<br />
• la velocità <strong>di</strong> risposta del sistema;<br />
• la tolleranza ai guasti.<br />
Per quanto riguarda gli accessi non <strong>di</strong>struttivi (<strong>di</strong> sola lettura), la gestione<br />
mira a <strong>di</strong>stribuire le richieste verso le repliche in modo da ridurre i singoli<br />
carichi <strong>di</strong> elaborazione, che altrimenti sarebbero concentrati verso <strong>un</strong> esiguo<br />
gruppo <strong>di</strong> host con <strong>un</strong> conseguente tempo <strong>di</strong> attesa eccessivo nelle code <strong>di</strong><br />
accesso. Inoltre <strong>di</strong>stribuendo geograficamente ed opport<strong>un</strong>amente le repliche<br />
si riducono anche i tempi <strong>di</strong> latenza.<br />
Nel caso in cui non sia necessario avere <strong>un</strong> elevato awareness <strong>di</strong> alto livello<br />
(questo concetto è stato affrontato in precedenza e non è legato al sistema <strong>di</strong><br />
replicazione, bensì al lavoro concorrente, capitolo 1) è possibile accedere alla<br />
replica in modo non <strong>di</strong>struttivo beneficiando dei vantaggi menzionati. Questa<br />
ipotesi si verifica nella maggior parte degli accessi in lettura che rappresentano,<br />
ragionevolmente, <strong>un</strong>a buona percentuale delle operazioni complessive<br />
effettuate sulla replica.<br />
Viceversa, nel caso in cui sia necessario avere awareness <strong>di</strong> alto livello,<br />
occorre interagire sistematicamente con le repliche in scrittura per contrassegnarle<br />
in qualche forma in modo da ottenere l’awareness voluto.<br />
Infine le repliche possono essere viste come copie <strong>di</strong> backup capaci <strong>di</strong><br />
rimpiazzare attivamente le omologhe guaste.<br />
Gli obiettivi esposti hanno però dei costi in termini <strong>di</strong>:<br />
1. complessità dell’implementazione. In relazione alle politiche ed ai protocolli,<br />
l’implementazione <strong>di</strong> <strong>un</strong> sistema per la gestione delle repliche<br />
può essere <strong>un</strong> compito costoso;<br />
2. amministrazione. Deve essere deciso quali risorse replicare e dove le<br />
repliche devono essere memorizzate;<br />
3. com<strong>un</strong>icazione aggi<strong>un</strong>tiva. Dipendentemente dal protocollo usato per<br />
mantenere aggiornate le repliche, il costo della com<strong>un</strong>icazione <strong>di</strong> risorse<br />
replicate è superiore rispetto all’accesso ad <strong>un</strong> sistema non replicato;<br />
4. spazio <strong>di</strong>sponibile. Ovviamente più repliche occupano <strong>un</strong>o spazio superiore<br />
rispetto a quello usato per <strong>un</strong>a singola replica.<br />
114
Architettura CISA CISA, sistema <strong>di</strong>stribuito<br />
Il problema maggiore è certamente la complessità, che d’altra parte è<br />
insita nel <strong>modello</strong> stesso, visti gli obiettivi <strong>di</strong> or<strong>di</strong>ne generale <strong>di</strong> CISA. I costi<br />
dovuti alla ridondanza sono ammortizzati dal vantaggio <strong>di</strong> <strong>un</strong>a maggiore<br />
affidabilità. Inoltre essendo proporzionali al costo dei <strong>di</strong>spositivi <strong>di</strong> memorizzazione<br />
<strong>di</strong> massa, come è noto, sono soggetti nel tempo alla <strong>di</strong>minuzione<br />
<strong>di</strong> prezzo.<br />
5.1.5 Me<strong>di</strong>um Dependent Layer<br />
Il Me<strong>di</strong>um Dependent Layer può modellare <strong>un</strong> file system, <strong>un</strong> database,<br />
<strong>un</strong> protocollo che agisce per il trasposto dei dati o anche <strong>un</strong> Legacy System.<br />
Si <strong>di</strong>stinguono due categorie <strong>di</strong> dati: dati locali e dati remoti. I dati locali<br />
possono essere repliche <strong>di</strong> dati remoti mantenuti in cache.<br />
I dati locali. Sono sud<strong>di</strong>visi in dati <strong>di</strong> responsabilità dell’amministratore<br />
e repliche <strong>di</strong> dati, <strong>di</strong> responsabilità <strong>di</strong> <strong>un</strong>’altra organizzazione, ottenuti con<br />
la com<strong>un</strong>icazione.<br />
I dati remoti. Sono ottenuti con <strong>un</strong> protocollo <strong>di</strong> trasporto. Una volta<br />
acquisti vengono replicati in <strong>un</strong>a cache locale. L’uso <strong>di</strong> Internet e <strong>di</strong> protocolli<br />
applicativi è estremamente in<strong>di</strong>cato in quanto sono <strong>un</strong> sistema pervasivo,<br />
<strong>di</strong>sponibile su tutto il territorio (o quasi). Inoltre in molte aree il livello<br />
collegamento ha alte prestazioni in termini <strong>di</strong> banda.<br />
5.2 CISA, sistema <strong>di</strong>stribuito<br />
L’architettura CISA è <strong>un</strong> sistema complesso sud<strong>di</strong>viso per convenienza<br />
in livelli <strong>di</strong>stinti. Le descrizioni delle f<strong>un</strong>zionalità <strong>di</strong> tali layer, effettuate nel<br />
paragrafo precedente, evidenziano come essi stessi siano sistemi complessi e,<br />
in alc<strong>un</strong>i casi, ulteriormente scomponibili in sistemi più elementari. Senza<br />
entrare nel dettaglio dei layer Application e Me<strong>di</strong>um Dependent, la figura 5.3<br />
evidenzia come il compito del Virtual Repository Layer sia espletato da tre<br />
sistemi <strong>di</strong>stinti: <strong>un</strong> sistema Virtual Repository, che gestisce la logica <strong>di</strong> controllo<br />
e le f<strong>un</strong>zioni specifiche del livello e due sistemi ausiliari, State e LDNS,<br />
utilizzati dal sistema Virtual Repository per il controllo della vali<strong>di</strong>tà dei<br />
documenti e la risoluzione dei nomi da LRI a PRI rispettivamente. Allo stesso<br />
modo Replica Management Layer è scomposto in due entità separate in<br />
115
Architettura CISA CISA, sistema <strong>di</strong>stribuito<br />
quanto il servizio <strong>di</strong> risoluzione dei nomi (da PRI ad URL) è espletato da <strong>un</strong><br />
sistema in<strong>di</strong>pendente, nello specifico da LS.<br />
Application Layer<br />
Virtual Repository Layer<br />
Structure Layer<br />
Replica Management<br />
Layer<br />
Me<strong>di</strong>um Dependent<br />
Layer<br />
State<br />
Replica<br />
Management<br />
Application<br />
Virtual<br />
Repository<br />
Structure<br />
LS<br />
Me<strong>di</strong>um Dependent<br />
LDNS<br />
Control Plane<br />
Application Layer<br />
Inter Layer Controller<br />
Figura 5.3: La pila CISA più nel dettaglio.<br />
Infine è necessario prevedere l’esistenza <strong>di</strong> <strong>un</strong> piano <strong>di</strong> controllo (Control<br />
Plane) trasversale all’architettura necessario per l’amministrazione, il monitoraggio<br />
e la gestione del sistema. Il piano <strong>di</strong> controllo sarà brevemente<br />
descritto nel paragrafo seguente.<br />
5.2.1 Control Plane<br />
Il piano <strong>di</strong> controllo serve per definire gli scopi e le modalità <strong>di</strong> f<strong>un</strong>zionamento<br />
dei livelli dell’architettura.<br />
Il controllo dei layer può essere attuato agendo attraverso <strong>un</strong> livello applicativo<br />
che si occupa anche <strong>di</strong> presentare in modo amichevole i possibili<br />
settaggi degli attuatori della QoS. La logica <strong>di</strong> controllo permette <strong>di</strong> agire<br />
su alc<strong>un</strong>i livelli CISA, così come <strong>un</strong>o <strong>di</strong> tali livelli può richiedere servizi al<br />
Control Plane.<br />
La possibilità <strong>di</strong> intervenire su alc<strong>un</strong>i piani in modo <strong>di</strong>retto, in<strong>di</strong>pendentemente<br />
dal comportamento degli altri layer, consente attività <strong>di</strong> amministrazione,<br />
manutenzione e configurazione, che qualsiasi sistema reale prevede.<br />
Ad esempio parametri <strong>di</strong> f<strong>un</strong>zionamento quali quelli relativi alle regole per la<br />
116
Architettura CISA Definizione <strong>di</strong> livelli, servizi e processi<br />
<strong>di</strong>stribuzione delle repliche, al comportamento delle versioni e delle informazioni<br />
possono essere monitorati e controllati <strong>di</strong>rettamente attraverso questo<br />
piano.<br />
Il Control Plane permette <strong>di</strong> agire e monitorare i vari layer secondo <strong>un</strong>a<br />
politica, entro certi limiti, centralizzata. Questo può essere utile per permettere<br />
agli amministratori dei sistemi che costituiscono CISA (sicuramente<br />
è utile nella fase <strong>di</strong> debug dell’architettura) <strong>di</strong> monitorarli e controllarne il<br />
f<strong>un</strong>zionamento nel loro insieme. In altre parole gli amministratori, grazie al<br />
Control Plane, hanno <strong>un</strong>a visione globale del f<strong>un</strong>zionamento dell’architettura.<br />
Ad esempio se ad <strong>un</strong> sistema arriva <strong>un</strong>a richiesta corrotta o malformata<br />
gli amministratori possono in<strong>di</strong>viduare il sistema specifico che, fra quelli<br />
che hanno partecipando all’elaborazione <strong>di</strong> tale richiesta, non ha operato<br />
correttamente.<br />
Infine è prevista <strong>un</strong>’interfaccia per il salvataggio degli eventi che può essere<br />
utilizzata dagli altri sistemi per memorizzare i dati <strong>di</strong> log su <strong>un</strong> server<br />
remoto e centralizzato. In realtà, essendo il sistema <strong>di</strong>stribuito, è possibile<br />
parlare <strong>di</strong> centralizzazione solo su scala locale in quanto il piano <strong>di</strong> controllo<br />
è strettamente correlato con la figura dell’amministratore <strong>di</strong> sistema che ha<br />
la f<strong>un</strong>zione <strong>di</strong> gestire tutte le problematiche legate ad <strong>un</strong> numero finito e ben<br />
determinato <strong>di</strong> apparati CISA. Come esempio si può pensare ai <strong>di</strong>spositivi<br />
<strong>di</strong> proprietà <strong>di</strong> <strong>un</strong>a data organizzazione che delega <strong>un</strong>o o più amministratori<br />
ad occuparsi della relativa gestione. I <strong>di</strong>spositivi appartenenti ad altre<br />
organizzazioni non rientrano, ovviamente, nel gruppo <strong>di</strong> sistemi su cui i suddetti<br />
amministratori hanno autorità ed è per questo motivo che si parla <strong>di</strong><br />
centralizzazione su scala locale.<br />
Il sottosistema finalizzato alla gestione dei dati <strong>di</strong> log può essere utilizzato<br />
per <strong>un</strong> altro scopo, può essere utile infatti per interagire attivamente,<br />
ad esempio in fase <strong>di</strong> debug del sistema, con le varie componenti che lo<br />
costituiscono sulla base degli eventi che esse stesse notificano al piano <strong>di</strong><br />
controllo.<br />
5.3 Definizione <strong>di</strong> livelli, servizi e processi<br />
CISA è <strong>un</strong>’architettura <strong>di</strong>stribuita ovvero <strong>un</strong> insieme <strong>di</strong> entità <strong>di</strong> elaborazione<br />
connesse tramite <strong>un</strong>a rete <strong>di</strong> com<strong>un</strong>icazione.<br />
La rete <strong>di</strong> com<strong>un</strong>icazione fa parte quin<strong>di</strong> dell’infrastruttura <strong>di</strong> base uti-<br />
117
Architettura CISA Definizione <strong>di</strong> livelli, servizi e processi<br />
lizzata da CISA per il proprio f<strong>un</strong>zionamento, infatti ogni apparato proprio<br />
<strong>di</strong> CISA è <strong>un</strong> sistema <strong>di</strong> livello applicativo della pila ISO/OSI.<br />
In questo scenario è possibile utilizzare anche la nomenclatura relativa<br />
all’ingegneria del software, che opera per definizione al livello applicativo<br />
OSI, e ricorrere al termine tier per fare riferimento ai layer CISA.<br />
Data la complessità del sistema e la moltitu<strong>di</strong>ne <strong>di</strong> elementi in gioco è<br />
necessario introdurre delle convenzioni relative alla nomenclatura utilizzata<br />
in modo da evitare spiacevoli incomprensioni.<br />
Parlando <strong>di</strong> layer (livello, tier o strato) viene fatto riferimento alle entità<br />
illustrate nei paragrafi precedenti: Application Layer, Virtual Repository<br />
Layer, Structure Layer, Replica Management Layer e Me<strong>di</strong>um Dependent<br />
Layer. Queste entità sono definite ad <strong>un</strong> livello <strong>di</strong> astrazione massimo e non<br />
è possibile delinearle come entità in<strong>di</strong>viduali all’interno dell’architettura <strong>di</strong><br />
rete.<br />
In riferimento all’architettura <strong>di</strong> rete è più opport<strong>un</strong>o parlare <strong>di</strong> servizio<br />
dotato <strong>di</strong> <strong>un</strong>o o più p<strong>un</strong>ti <strong>di</strong> accesso. Escludendo il layer applicativo sul quale<br />
viene lasciata la massima libertà, le tipologie <strong>di</strong> servizio possibili e le relative<br />
interfacce, che sono state definite in CISA seguendo la filosofia REST, sono in<br />
numero limitato e definito a priori. In modo particolare è possibile inquadrare<br />
ogni livello CISA come fornitore, verso il livello superiore, <strong>di</strong> <strong>un</strong> servizio ben<br />
determinato.<br />
Con servizio si intende <strong>un</strong> sistema software costituito da <strong>un</strong> insieme <strong>di</strong><br />
entità equivalenti fra loro (processi) che operano, in<strong>di</strong>vidualmente o in collaborazione,<br />
per svolgere lo stesso tipo <strong>di</strong> attività. Il concetto <strong>di</strong> equivalenza è<br />
relativo alla mansione svolta e non alle modalità con cui il singolo processo<br />
opera; esiste quin<strong>di</strong> <strong>un</strong> protocollo che, tramite <strong>un</strong>’interfaccia ben definita e<br />
com<strong>un</strong>e a tutte le entità, permette <strong>di</strong> usufruire del servizio offerto. La risoluzione<br />
degli hostname in in<strong>di</strong>rizzi IP <strong>di</strong> Internet, effettuata dal DNS (Domain<br />
Name System), è <strong>un</strong> esempio <strong>di</strong> servizio fornito da <strong>un</strong> insieme <strong>di</strong> entità, i<br />
server dei nomi, che operano in collaborazione [KR03].<br />
In CISA le entità appena introdotte sono processi ovvero programmi in<br />
esecuzione [TW97] su host <strong>di</strong> rete (computer fisici o macchine virtuali). L’accezione<br />
a cui si fa riferimento è quella utilizzata nel contesto dei sistemi operativi.<br />
Inoltre tali processi, per poter erogare dei servizi all’esterno, devono<br />
essere in<strong>di</strong>viduabili in rete tramite in<strong>di</strong>rizzi <strong>di</strong> livello applicativo <strong>di</strong> OSI 1 e<br />
1 In riferimento a reti basate sullo stack TCP/IP è possibile fare riferimento a coppie<br />
“IP:PORTA”.<br />
118
Architettura CISA Definizione <strong>di</strong> livelli, servizi e processi<br />
pertanto si può parlare <strong>di</strong> processi in esecuzione su host.<br />
L’architettura più semplice in grado <strong>di</strong> fornire <strong>un</strong> servizio è costituita da<br />
<strong>un</strong> singolo processo ospitato in <strong>un</strong> host, ma generalmente <strong>un</strong> servizio viene<br />
fornito da <strong>un</strong> cospicuo insieme <strong>di</strong> processi <strong>di</strong>stinti.<br />
Per quanto riguarda i servizi che sono forniti da due o più processi si<br />
hanno le seguenti possibilità:<br />
• i processi coinvolti nella fornitura del servizio sono in<strong>di</strong>pendenti. Questo<br />
è il caso ideale che garantisce il grado <strong>di</strong> parallelismo massimo in quanto<br />
ogni processo riesce ad espletare tutte le richieste che gli vengono inoltrate<br />
senza dover chiamare in causa altri processi ad esso equivalenti.<br />
Le prestazioni del servizio scalano linearmente con il numero <strong>di</strong> processi<br />
che lo erogano e questa è la situazione ideale. Esempi <strong>di</strong> questo tipo<br />
sono Application Service, Virtual Repository Service, Structure Service<br />
e State Service;<br />
• i processi coinvolti nella fornitura del servizio sono non in<strong>di</strong>pendenti.<br />
In questo caso esiste <strong>un</strong>a correlazione fra i processi in gioco, questo<br />
significa che per espletare le richieste che vengono inoltrate ad <strong>un</strong>o <strong>di</strong><br />
essi potrebbe sorgere la necessità <strong>di</strong> chiamarne in causa altri. In questo<br />
caso non è possibile fare ipotesi sulla scalabilità in quanto <strong>di</strong>pende dal<br />
grado <strong>di</strong> accoppiamento che non è noto a priori. Esempi <strong>di</strong> questo tipo<br />
sono LS Service e LDNS Service che sono costituiti da <strong>un</strong>a griglia <strong>di</strong><br />
processi che collaborano l’<strong>un</strong>o con l’altro per poter rispondere a richieste<br />
<strong>di</strong> risoluzione rivolte ad <strong>un</strong>o qual<strong>un</strong>que <strong>di</strong> essi. Il problema della<br />
risoluzione viene affrontato nel capitolo 8; per quanto riguarda la scalabilità,<br />
in questo caso specifico, è possibile anticipare che è equiparabile<br />
a quella <strong>di</strong>mostrata sul campo da DNS in quanto LS ed LDNS operano<br />
secondo gli stessi principi.<br />
Per i livelli più bassi l’analisi si complica in quanto ci si scontra col fatto<br />
che i dati hanno <strong>un</strong> responsabile (come persona fisica o come organizzazione)<br />
e sono replicati fisicamente <strong>un</strong> numero <strong>di</strong> volte in<strong>di</strong>pendente dal numero<br />
<strong>di</strong> host che operano a livello Replica Management e Me<strong>di</strong>um Dependent.<br />
In ogni caso al crescere delle quantità dei dati il sistema scala linearmente<br />
aumentando il numero <strong>di</strong> apparati 2 .<br />
2 In questo caso parlare <strong>di</strong> processo risulta riduttivo in quanto occorre considerare che<br />
i dati devono essere memorizzati su <strong>un</strong> qualche supporto fisico.<br />
119
Architettura CISA Definizione <strong>di</strong> livelli, servizi e processi<br />
I problemi sorgono fissando l’attenzione su <strong>un</strong> ben particolare dato e<br />
volendo analizzare la scalabilità del sistema al crescere degli utenti interessati<br />
ad esso. In questo caso, trattando l’accesso in sola lettura, il sistema scala<br />
proporzionalmente al numero <strong>di</strong> repliche del dato (che in ogni caso con<strong>di</strong>ziona<br />
il numero <strong>di</strong> apparati).<br />
Per quanto riguarda le scritture l’ipotesi <strong>di</strong> esistenza <strong>di</strong> <strong>un</strong> <strong>un</strong>ico responsabile<br />
(che deve garantire la correttezza delle informazioni) è <strong>un</strong> requisito<br />
che porta ad ipotizzare che il numero <strong>di</strong> utenti da esso autorizzati ad operare<br />
sull’informazione stessa sia limitato al fine <strong>di</strong> mantenere <strong>un</strong> controllo sufficiente<br />
su <strong>di</strong> essa. Quin<strong>di</strong> questo aspetto rientra nella scelta delle politiche <strong>di</strong><br />
gestione dei <strong>di</strong>ritti <strong>di</strong> accesso all’informazione, ma, a seguito <strong>di</strong> <strong>un</strong>a fase <strong>di</strong><br />
analisi effettuata sul contesto applicativo nel quale il sistema dovrà operare<br />
(ve<strong>di</strong> [Inn04]) e considerando che le politiche <strong>di</strong> gestione <strong>di</strong> scrittura sui dati<br />
sono possibilmente ottimistiche (ve<strong>di</strong> sotto paragrafo 1.2.4, a pagina 17), la<br />
scalabilità anche in questo caso non dovrebbe rappresentare <strong>un</strong> problema.<br />
In figura 5.4 vengono riportate le relazioni esistenti tra livelli, servizi e<br />
processi che costituiscono il sistema CISA. Due processi hanno la possibilità<br />
<strong>di</strong> com<strong>un</strong>icare se i relativi servizi sono collegati tramite <strong>un</strong>a freccia. In particolare<br />
la <strong>di</strong>rezione della freccia in<strong>di</strong>ca in quale verso si sviluppa la richiesta:<br />
l’elemento dal quale essa parte è il richiedente del servizio ovvero il client,<br />
mentre quello nel quale essa termina è il fornitore del servizio ovvero il server.<br />
La figura 5.4 evidenzia anche altri aspetti: in particolare è possibile osservare<br />
che esistono processi che forniscono servizi ad altri processi, rappresentati<br />
tramite il case <strong>di</strong> <strong>un</strong> server, e processi che forniscono servizi all’uomo<br />
attraverso <strong>un</strong>’interfaccia utente, rappresentati tramite <strong>un</strong> personal computer<br />
dotato <strong>di</strong> monitor e tastiera. Tenendo conto <strong>di</strong> questa convenzione grafica<br />
è possibile osservare come tutti i processi in gioco offrano servizi ad altri<br />
processi rispettando i vincoli imposti dal <strong>modello</strong> stratificato presentato nel<br />
paragrafo 5.1, ad eccezione <strong>di</strong> quelli appartenenti ad Application Layer e, almeno<br />
in parte, <strong>di</strong> quelli presenti nel Control Layer. Questo aspetto, insieme<br />
al fatto che Control Layer può agire su altri processi oppure essere fornitore<br />
<strong>di</strong> servizi ad altri processi, ne evidenzia la doppia natura:<br />
• attiva (per quanto riguarda la possibilità <strong>di</strong> intervenire su altre entità);<br />
• passiva (per quanto riguarda la capacità <strong>di</strong> fornire <strong>un</strong> sistema <strong>di</strong> memorizzazione<br />
degli eventi).<br />
Infine è possibile <strong>di</strong>stinguere i servizi che vengono espletati da processi<br />
120
Architettura CISA Definizione <strong>di</strong> livelli, servizi e processi<br />
Application<br />
Layer<br />
Virtual<br />
Repository<br />
Layer<br />
Structure<br />
Layer<br />
Replica<br />
Management<br />
Layer<br />
Me<strong>di</strong>um<br />
Dependent<br />
Layer<br />
Application<br />
Type 1<br />
Virtual<br />
Repository<br />
Service<br />
Structure<br />
Service<br />
Replica<br />
Management<br />
Service<br />
Me<strong>di</strong>um<br />
Dependent<br />
Service<br />
...<br />
Legenda: tipologie <strong>di</strong> processi<br />
Processo dotato <strong>di</strong><br />
interfaccia utente<br />
Application<br />
Type N<br />
LDNS<br />
Service<br />
State<br />
Service<br />
LS<br />
Service<br />
Processo privo <strong>di</strong><br />
interfaccia utente<br />
Figura 5.4: Livelli, servizi e processi.<br />
Control<br />
Plane<br />
Control<br />
Service<br />
in<strong>di</strong>pendenti e non in<strong>di</strong>pendenti. In particolare quelli non in<strong>di</strong>pendenti sono<br />
messi in risalto da <strong>un</strong>a interconnessione <strong>di</strong> rete (nello specifico LDNS Service,<br />
LS Service e Replica Management Service), gli altri sono isolati ad in<strong>di</strong>care<br />
121
Architettura CISA Definizione <strong>di</strong> livelli, servizi e processi<br />
la loro in<strong>di</strong>pendenza e che agiscono, quin<strong>di</strong>, in autonomia.<br />
Di seguito, facendo sempre riferimento alla figura 5.4, vengono brevemente<br />
descritti i servizi presenti nell’architettura, sud<strong>di</strong>visi per layer <strong>di</strong> appartenenza.<br />
Application Layer. Il livello applicativo fornisce servizi <strong>di</strong>rettamente all’utente.<br />
I servizi forniti possono essere <strong>di</strong> vario tipo e CISA non entra nel<br />
merito della loro definizione. Quin<strong>di</strong>, in riferimento alla figura, Application<br />
Type X (con X compreso fra 1 ed N) rappresenta <strong>un</strong>a specifica applicazione<br />
CISA con la quale l’utente interagisce ideata per svolgere <strong>un</strong>a particolare f<strong>un</strong>zione.<br />
Il concetto <strong>di</strong> servizio in questo caso, data la generalità del problema<br />
e il fatto che è l’utente ad essere il fruitore dello stesso, è da considerarsi <strong>di</strong><br />
più ampio spettro e più astratto e gli scenari che possono essere realizzati<br />
sono i più <strong>di</strong>versificati.<br />
In generale Application Layer può essere modellato come sistema ulteriormente<br />
stratificato e sud<strong>di</strong>viso in tre livelli, riportati <strong>di</strong> seguito dal più alto al<br />
più basso:<br />
• presentazione: gestisce l’interazione con l’utente sia per quanto riguarda<br />
la visualizzazione che l’acquisizione dei dati;<br />
• elaborazione: implementa gli algoritmi per l’elaborazione dei dati e per<br />
la gestione del f<strong>un</strong>zionamento della specifica applicazione;<br />
• interfaccia: si occupa della com<strong>un</strong>icazione fra l’applicazione e Virtual<br />
Repository.<br />
Il seguente esempio è sicuramente utile per chiarire questa scenario. Si<br />
pensi ad <strong>un</strong>a situazione, estremamente semplificata rispetto al caso reale,<br />
nella quale <strong>un</strong> libero professionista si rivolge al proprio commercialista per la<br />
compilazione del <strong>modello</strong> annuale <strong>di</strong> <strong>di</strong>chiarazione IVA [dedF06]. Il software<br />
del commercialista, <strong>di</strong> livello Application <strong>di</strong> CISA, è dotato <strong>di</strong> <strong>un</strong>’interfaccia<br />
utente (in<strong>di</strong>viduabile nel contesto del layer <strong>di</strong> presentazione) attraverso la<br />
quale l’utilizzatore può effettuare:<br />
• l’inserimento e la visualizzazione dei dati dei clienti;<br />
• l’inserimento e la visualizzazione delle fatture;<br />
• la richiesta del calcolo dei dati necessari alla compilazione del <strong>modello</strong><br />
<strong>di</strong> <strong>di</strong>chiarazione IVA.<br />
122
Architettura CISA Definizione <strong>di</strong> livelli, servizi e processi<br />
Per quanto riguarda i primi due p<strong>un</strong>ti il layer <strong>di</strong> elaborazione può essere considerato<br />
del tutto trasparente in quanto sia i dati dei clienti che le fatture<br />
sono informazioni agevolmente mappabili in documenti D3IM. A seguito dell’inserimento<br />
o della richiesta <strong>di</strong> visualizzazione <strong>di</strong> questo tipo <strong>di</strong> informazioni<br />
(da parte del commercialista) il layer Application si interfaccia con Virtual<br />
Repository per il salvataggio o l’accesso ad esse come richiesto.<br />
Il calcolo delle parametri necessari alla compilazione del modulo è <strong>un</strong>’operazione<br />
più complessa e in questo caso entra in gioco il layer <strong>di</strong> elaborazione:<br />
l’algoritmo richiede a Virtual Repository tutti i documenti necessari relativi<br />
al cliente e tutte le sue fatture (dell’anno fiscale <strong>di</strong> interesse). Sulla base <strong>di</strong><br />
questi dati calcola i valori da inserire nel <strong>modello</strong> come richiesto, applicando<br />
i criteri stabiliti dalla Agenzia delle Entrate.<br />
Si noti come in <strong>un</strong> ambiente totalmente <strong>di</strong>stribuito l’Agenzia delle Entrate<br />
avrebbe potuto accedere <strong>di</strong>rettamente ai dati relativi al libero professionista<br />
(eventualmente immessi dal commercialista) per il calcolo delle tasse (nello<br />
specifico l’IVA) senza la necessità <strong>di</strong> obbligare il citta<strong>di</strong>no a compilare alc<strong>un</strong><br />
modulo come avviene attualmente.<br />
Questo esempio mette in luce che gli scenari possibili sono innumerevoli e<br />
pertanto le soluzioni tecniche che possono presentarsi nelle fasi <strong>di</strong> analisi e <strong>di</strong><br />
progettazione del layer Application possono essere estremamente <strong>di</strong>versificate.<br />
In riferimento alla figura si pensi, ad esempio, all’Application Type N che<br />
potrebbe essere <strong>un</strong>’applicazione a 2-tier basata su interfaccia web: in questo<br />
caso esistono svariati processi che interagiscono <strong>di</strong>rettamente con l’utente (i<br />
web browser) e <strong>un</strong>o o più processi, sicuramente <strong>di</strong>versi sotto ogni p<strong>un</strong>to <strong>di</strong><br />
vista dai precedenti, che costituiscono l’Application Server. In questo caso il<br />
client utente interagisce in HTTP con l’Application Server ed è l’Application<br />
Server a richiedere servizi a Virtual Repository. Viceversa l’Application Type<br />
1 potrebbe essere <strong>un</strong>’applicazione con interfaccia grafica integrata: ogni utente<br />
ha <strong>un</strong>’istanza dell’applicazione completa, operante sul proprio terminale,<br />
la quale com<strong>un</strong>ica <strong>di</strong>rettamente con Virtual Repository.<br />
Virtual Repository Layer. A questo livello si localizzano tre servizi<br />
<strong>di</strong>stinti:<br />
• Virtual Repository Service, svolge tutte le f<strong>un</strong>zionalità previste dal Livello<br />
Virtual Repository ad eccezione della risoluzione da nomi logici (LRI)<br />
in nomi persistenti (PRI) e della validazione dell’informazione;<br />
123
Architettura CISA Definizione <strong>di</strong> livelli, servizi e processi<br />
• LDNS Service, effettua la risoluzione da LRI in PRI;<br />
• State Service, effettua la validazione dell’informazione.<br />
Structure Layer. Il livello Structure ospita al proprio interno <strong>un</strong> solo tipo<br />
<strong>di</strong> servizio: Structure Service. Questo servizio copre tutte le f<strong>un</strong>zionalità<br />
fornite dal livello CISA in esame.<br />
Replica Management Layer. A questo livello si localizzano due servizi<br />
<strong>di</strong>stinti:<br />
• Replica Management Service, svolge tutte le f<strong>un</strong>zionalità previste nel<br />
Replica Management Layer ad eccezione della risoluzione da nomi persistenti<br />
(PRI) in URL. Dipendentemente dal protocollo e dalla politica<br />
utilizzata per la gestione delle repliche potrebbe esistere <strong>un</strong> certo accoppiamento<br />
fra tali processi. Le metodologie possibili sono infatti<br />
due:<br />
– si ricorre ad <strong>un</strong> meccanismo <strong>di</strong> delega attraverso cui il processo al<br />
quale è stata effettuata la richiesta <strong>di</strong> servizio (accesso o mo<strong>di</strong>fica<br />
<strong>di</strong> <strong>un</strong> dato) contatta il processo responsabile del dato che può valutare<br />
se sod<strong>di</strong>sfare o meno la richiesta. Questa è la situazione a cui<br />
è stato fatto riferimento precedentemente che determina l’instaurarsi<br />
dell’accoppiamento. Il vantaggio <strong>di</strong> questa soluzione consiste<br />
nel fatto che il responsabile del dato, visto come informazione<br />
astratta (identificata da <strong>un</strong> PRI, nome persistente ed <strong>un</strong>ivoco), ne<br />
detiene <strong>di</strong>rettamente il controllo per quel che riguarda la gestione<br />
delle politiche <strong>di</strong> accesso. Si osservi che parlare <strong>di</strong> <strong>un</strong>a particolare<br />
replica <strong>di</strong> tale dato è <strong>un</strong> concetto <strong>di</strong>verso;<br />
– si ipotizza che il processo al quale è stata effettuata la richiesta<br />
<strong>di</strong> servizio acceda autonomamente al processo <strong>di</strong> livello Me<strong>di</strong>um<br />
Dependent che detiene la particolare replica in esame. Questo tipo<br />
<strong>di</strong> interazione fra processi appartenenti a layer a<strong>di</strong>acenti verrà<br />
<strong>di</strong>scusso in modo più approfon<strong>di</strong>to successivamente, parlando dell’architettura<br />
<strong>di</strong> rete <strong>di</strong> CISA e, più nello specifico, <strong>di</strong> multiplexing<br />
e demultiplexing (paragrafo 9.1.1) in CISA.<br />
Allo stato attuale dell’evoluzione del progetto non è possibile effettuare<br />
la scelta della strategia da utilizzare in quanto non è possibile stimare<br />
124
Architettura CISA Definizione <strong>di</strong> livelli, servizi e processi<br />
quali risvolti pratici comportino i vantaggi e gli svantaggi evidenziati.<br />
Pertanto questo aspetto sarà da trattare negli sviluppi futuri.<br />
• LS Service, effettua la risoluzione da PRI in URL.<br />
Me<strong>di</strong>um Dependent Layer. Me<strong>di</strong>um Dependent Service fornisce al Livello<br />
Replica Management <strong>un</strong>’interfaccia <strong>un</strong>ificata per l’accesso fisico ai dati. I<br />
processi che operano con questa finalità possono essere <strong>di</strong> vario tipo in quanto<br />
i dati possono essere memorizzati in varie forme (file system, database, etc.)<br />
e conseguentemente il relativo accesso può essere effettuato secondo criteri<br />
<strong>di</strong>versi. Inoltre esiste la necessità <strong>di</strong> garantire la compatibilità verso i sistemi<br />
legacy pertanto occorre prevedere l’esistenza <strong>di</strong> <strong>un</strong> meccanismo <strong>di</strong> “traduzione”<br />
che permetta <strong>di</strong> convertire le informazioni in <strong>un</strong> formato <strong>un</strong>ificato<br />
interpretabile senza ambiguità dagli strati superiori.<br />
Control Plane. Il Control Plane è stato descritto nel sotto paragrafo 5.2.1.<br />
In questa sede è utile evidenziare che è <strong>un</strong> aggregato <strong>di</strong> servizi <strong>di</strong>versificati (in<br />
figura, Control Services) che operano per le finalità riportate precedentemente.<br />
Alc<strong>un</strong>i <strong>di</strong> questi servizi hanno <strong>un</strong>’interfaccia utente (ad esempio è possibile<br />
ipotizzare l’esistenza <strong>di</strong> specifici tool <strong>di</strong> amministrazione), altri ne sono privi<br />
(ad esempio, escludendo l’aspetto attivo che potrebbe richiedere l’intervento<br />
umano, l’infrastruttura <strong>di</strong> logging).<br />
125
Capitolo<br />
6<br />
Versioning in CISA<br />
L’architettura CISA è stata progettata applicando la separation of concern<br />
cercando <strong>di</strong> massimizzarne i benefici e, a tal fine, sono stati in<strong>di</strong>viduati<br />
alc<strong>un</strong>i livelli che espletano vari servizi, ogn<strong>un</strong>o dei quali si occupa <strong>di</strong> <strong>un</strong><br />
compito ben determinato e definito.<br />
L’architettura è stata introdotta nel capitolo 5 nel quale sono stati illustrati<br />
i principali sistemi e sottosistemi che la costituiscono con <strong>un</strong>a descrizione<br />
delle loro f<strong>un</strong>zionalità. L’<strong>un</strong>ico layer che è stato trascurato è Structure. Il<br />
motivo <strong>di</strong> questa scelta è legato al fatto che Structure si occupa del versioning<br />
dell’informazione, argomento <strong>di</strong> maggior interesse nel presente lavoro <strong>di</strong> tesi<br />
e pertanto affrontato dettagliatamente in questo capitolo e nel successivo i<br />
quali ne evidenziano i dettagli progettuali.<br />
Si ricorda che il versioning è <strong>un</strong>’operazione finalizzata al mantenimento ed<br />
alla gestione dell’evoluzione temporale dell’informazione e, nel caso specifico,<br />
il layer Structure implementa le f<strong>un</strong>zionalità relative al versioning previste<br />
nel <strong>modello</strong> <strong>di</strong> documento D3IM, descritto nel capitolo 4.<br />
D3IM è stato definito con la finalità <strong>di</strong> ottenere <strong>un</strong> <strong>modello</strong> per i dati<br />
il più vantaggioso possibile nel contesto <strong>di</strong> sistemi finalizzati per il lavoro<br />
collaborativo.<br />
I concetti <strong>di</strong> cooperazione, <strong>di</strong> versioning e la descrizione <strong>di</strong> alc<strong>un</strong>i siste-
Versioning in CISA Da D3IM al versioning in CISA<br />
mi esistenti finalizzati al lavoro collaborativo sono stati trattati in modo<br />
approfon<strong>di</strong>to nei capitoli 1 e 2.<br />
6.1 Da D3IM al versioning in CISA<br />
Il <strong>modello</strong> dell’informazione D3IM è stato progettato ispirandosi al <strong>modello</strong><br />
<strong>di</strong> documento <strong>di</strong> UEVM (paragrafo 2.4 a pagina 33) con la finalità <strong>di</strong><br />
applicare gli stessi principi relativamente al versioning delle informazioni.<br />
Si ricorda che UEVM è <strong>un</strong> <strong>modello</strong> che permette <strong>di</strong> gestire le versioni <strong>di</strong><br />
documenti strutturati ad albero con la particolarità <strong>di</strong> riuscire a versionare<br />
anche gli aspetti strutturali. In altre parole il documento è visto come <strong>un</strong>a<br />
“istantanea” delle informazioni sia per quel che riguarda il loro contenuto che<br />
per le relazioni esistenti fra <strong>di</strong> esse. UEVM quin<strong>di</strong> applica il versioning alle<br />
configurazioni (paragrafo 1.3 a pagina 18) del documento.<br />
Il fatto che UEVM si limiti a gestire documenti strutturati ad albero<br />
deriva dal considerare l’informazione come entità in<strong>di</strong>viduale: il documento.<br />
In UEVM due documenti <strong>di</strong>versi sono entità <strong>di</strong>stinte e completamente<br />
scorrelate.<br />
In D3IM viceversa l’informazione è <strong>di</strong>stribuita e <strong>un</strong>a delle caratteristiche<br />
<strong>di</strong> maggior rilievo del <strong>modello</strong> è proprio la con<strong>di</strong>visione delle conoscenza fra<br />
soggetti (e documenti) <strong>di</strong>versi. Il documento in D3IM è considerato come<br />
l’aggregazione <strong>di</strong> informazioni <strong>di</strong>stribuite.<br />
Questo porta ad <strong>un</strong>a struttura più generale rispetto a quella ad albero in<br />
quanto la con<strong>di</strong>visione <strong>di</strong> <strong>un</strong>’informazione fra due documenti <strong>di</strong>stinti genera<br />
<strong>un</strong> DAG: si hanno due alberi parzialmente sovrapposti e l’intersezione è data<br />
esattamente dal sotto albero che rappresenta l’informazione con<strong>di</strong>visa. Generalizzando,<br />
lo stesso risultato si ottiene anche nel caso della con<strong>di</strong>visione<br />
<strong>di</strong> <strong>un</strong>’informazione da parte <strong>di</strong> N documenti, con N arbitrario.<br />
Da questa considerazione si deduce che le generiche relazioni fra no<strong>di</strong><br />
D3IM portano ad avere <strong>un</strong> DAG. Per questo motivo, e com<strong>un</strong>que per avere<br />
maggiore flessibilità nella modellazione dell’informazione, in D3IM si parla<br />
<strong>di</strong> DAG anche limitatamente al contesto del singolo documento.<br />
Infine il <strong>modello</strong> <strong>di</strong> documento <strong>di</strong> UEVM tiene conto esclusivamente delle<br />
informazioni e delle loro relazioni strutturali con la finalità <strong>di</strong> versionarle.<br />
D3IM prende in considerazione anche altre problematiche come il concetto<br />
<strong>di</strong> responsabilità e <strong>di</strong> stato dell’informazione, dello spazio dei nomi, eccete-<br />
127
Versioning in CISA Lo storico in CISA<br />
ra, aspetti che non risultano <strong>di</strong> fondamentale importanza nel contesto del<br />
versioning e pertanto non verranno trattati in questo ambito.<br />
6.2 Lo storico in CISA<br />
Il servizio <strong>di</strong> gestione del versioning (o dello storico) <strong>di</strong> <strong>un</strong> documento,<br />
secondo le specifiche stabilite nel <strong>modello</strong> D3IM, viene fornito integralmente<br />
ed esclusivamente dal layer Structure <strong>di</strong> CISA. Quin<strong>di</strong>, in riferimento a<br />
Structure, è possibile parlare equivalentemente <strong>di</strong> layer o <strong>di</strong> servizio (a patto<br />
<strong>di</strong> assegnare ad ogni termine il giusto significato concettuale) in quanto non<br />
vi è rischio <strong>di</strong> ambiguità.<br />
Per poter introdurre, in modo dettagliato, quale sia il servizio che effettivamente<br />
viene fornito da Structure, e come questo sia conforme alle specifiche<br />
dettate da D3IM, è necessario evidenziare che i seguenti aspetti sono<br />
in<strong>di</strong>pendenti:<br />
• la gestione dello storico del documento ovvero l’insieme <strong>di</strong> tutti quei<br />
meccanismi necessari per la creazione, l’aggiornamento e il mantenimento<br />
della consistenza dello stesso. Queste operazioni sono del tutto<br />
interne al layer e le modalità operative secondo le quali vengono<br />
espletate non riguardano i sistemi esterni;<br />
• la navigazione nello storico del documento ovvero l’insieme <strong>di</strong> tutti quei<br />
meccanismi finalizzati a fornire il servizio <strong>di</strong> in<strong>di</strong>rizzamento all’informazione<br />
<strong>versionata</strong>, in quanto deve essere possibile, per i livelli superiori,<br />
“spostarsi” nello spazio delle versioni; in caso contrario l’importanza<br />
dell’esistenza del versioning verrebbe del tutto vanificata.<br />
6.2.1 La struttura dello storico<br />
Prima <strong>di</strong> entrare nel merito <strong>di</strong> come il layer Structure implementi le specifiche<br />
dettate dal <strong>modello</strong> D3IM è utile ricordare brevemente la nomenclatura<br />
e i principi generali utilizzati nell’ambito del versioning.<br />
Una configurazione è <strong>un</strong>’istantanea del sistema (documento), ad <strong>un</strong> certo<br />
istante <strong>di</strong> tempo. Il para<strong>di</strong>gma <strong>di</strong> versioning utilizzato in CISA si applica alle<br />
configurazioni: ogni mo<strong>di</strong>fica (tempo <strong>di</strong>screta 1 ) alla configurazione genera<br />
1 Per poter considerare variazioni tempo continue, in questo contesto, è necessario<br />
ricorrere ad opport<strong>un</strong>e tecniche <strong>di</strong> campionamento.<br />
128
Versioning in CISA Lo storico in CISA<br />
<strong>un</strong>a nuova revisione del documento. Con mo<strong>di</strong>fica si in<strong>di</strong>vidua <strong>un</strong>’operazione<br />
che comprende <strong>un</strong>a o più variazioni all’interno della configurazione. L’entità<br />
della mo<strong>di</strong>fica nel suo complesso è <strong>un</strong>a grandezza che può essere gestita sia<br />
dall’utente che in modo automatico dal sistema e <strong>di</strong>pende dall’entità e dal<br />
numero delle singole variazioni elementari che la costituiscono.<br />
L’insieme delle revisioni è <strong>un</strong>a co<strong>di</strong>fica dell’evoluzione temporale delle<br />
configurazioni ed è quin<strong>di</strong> <strong>un</strong> insieme nel quale esiste <strong>un</strong> or<strong>di</strong>namento totale:<br />
date due revisioni ra e rb si ha che ra < rb oppure rb < ra oppure ra e rb<br />
sono la stessa configurazione. Lo storico <strong>di</strong> <strong>un</strong> documento descritto in questi<br />
termini è lineare ed è costituito dall’insieme delle sole revisioni.<br />
Uno storico <strong>di</strong> questo tipo può essere sufficiente a modellare l’evoluzione<br />
temporale <strong>di</strong> <strong>un</strong>’informazione, ma può non essere abbastanza flessibile da<br />
favorire la cooperazione fra più utenti e, in generale, l’authoring su <strong>di</strong> essa in<br />
modo concorrente.<br />
Senza entrare nel merito della questione (già affrontata in dettaglio nei capitoli<br />
1 e 2) è necessario poter creare esplicitamente delle <strong>di</strong>ramazioni (branch)<br />
all’interno dello storico per permettere lo sviluppo concorrente (quin<strong>di</strong> in<br />
parallelo) su due o più rami in<strong>di</strong>pendenti. Creare branch all’interno <strong>di</strong> <strong>un</strong>o<br />
storico lineare porta ad avere <strong>un</strong>a struttura dello storico ad albero. In questo<br />
caso con revisione si intende <strong>un</strong>a nuova versione <strong>di</strong> <strong>un</strong> elemento presente in<br />
<strong>un</strong> determinato branch.<br />
Infine può risultare necessario far convergere (operazione <strong>di</strong> merge) due<br />
rami <strong>di</strong>stinti su <strong>un</strong> <strong>un</strong>ico ramo e così la struttura complessiva che si ottiene<br />
è <strong>un</strong> DAG.<br />
Il DAG permette quin<strong>di</strong> <strong>di</strong> rappresentare le relazioni fra <strong>un</strong> qual<strong>un</strong>que<br />
insieme <strong>di</strong> versioni <strong>di</strong> <strong>un</strong>’informazione.<br />
A tal riguardo può essere utile riferirsi nuovamente al paragrafo 2.1 e, in<br />
particolare, alla figura 2.1 a pagina 25.<br />
D3IM nel layer Structure<br />
D3IM è <strong>un</strong> <strong>modello</strong> strutturato e prevede l’esistenza <strong>di</strong> due tipologie <strong>di</strong><br />
informazioni:<br />
• primitive;<br />
• atomiche.<br />
129
Versioning in CISA Lo storico in CISA<br />
Le informazioni atomiche vengono incapsulate in informazioni primitive:<br />
solo queste ultime hanno <strong>un</strong> in<strong>di</strong>rizzo <strong>un</strong>ivoco (PRI) e possono essere<br />
associate ai no<strong>di</strong> del DAG relativo al documento. Tali no<strong>di</strong> contengono<br />
quin<strong>di</strong>:<br />
• le informazioni atomiche costituite da coppie “”, i dati<br />
veri e propri definiti nei livelli superiori;<br />
• i metadati definiti nei livelli superiori;<br />
• le relazioni verso altri no<strong>di</strong>, proprie delle informazioni primitive.<br />
Per il livello Structure esistono quin<strong>di</strong> no<strong>di</strong> al cui interno è possibile in<strong>di</strong>viduare<br />
due sezioni <strong>di</strong>stinte, che nascono a seguito del principio <strong>di</strong> imbustamento<br />
presente in CISA in quanto architettura stratificata.<br />
Tali no<strong>di</strong>, rappresentati schematicamente in figura 6.1, sono costituiti da:<br />
• <strong>un</strong> header, che contiene tutti i metadati necessari al mantenimento delle<br />
relazioni definite a livello Structure;<br />
• <strong>un</strong> body, nel quale Structure imbusta tutti i dati e i metadati che non<br />
sono <strong>di</strong> sua competenza (ma <strong>di</strong> competenza dei livelli superiori).<br />
In<strong>di</strong>rizzamento<br />
PRI<br />
Header Body<br />
Dati e metadati <strong>di</strong><br />
competenza <strong>di</strong> Structure<br />
Dati e metadati <strong>di</strong> competenza<br />
dei livelli superiori<br />
Figura 6.1: No<strong>di</strong> <strong>di</strong> livello Structure.<br />
6.2.2 Relazioni fra no<strong>di</strong> <strong>di</strong> livello Structure<br />
Il DAG a cui è stato fatto riferimento nel sotto paragrafo 6.2.1 è ottenuto<br />
andando a considerare le informazioni atomiche, le informazioni primitive e<br />
i link <strong>di</strong> composizione definiti nel <strong>modello</strong> D3IM.<br />
130
Versioning in CISA Lo storico in CISA<br />
Si ricorda che D3IM definisce anche <strong>un</strong> altro tipo <strong>di</strong> relazione fra no<strong>di</strong> che<br />
è rappresentata dai link <strong>di</strong> riferimento. Tali link non hanno ness<strong>un</strong> legame<br />
con la gestione delle versioni, sono infatti definiti ai livelli Application e<br />
Virtual Repository ed essendo informazioni atomiche per Structure risultano<br />
incorporate nel body.<br />
In riferimento al <strong>modello</strong> D3IM, in corrispondenza dei link <strong>di</strong> composizione,<br />
è necessario prevedere <strong>un</strong> meccanismo che permetta <strong>di</strong> propagare le<br />
mo<strong>di</strong>fiche dei figli verso i genitori. Tale algoritmo rientra a pieno titolo fra le<br />
mansioni legate alla gestione dello storico e pertanto deve essere definito ed<br />
applicato nel contesto del layer Structure. Structure deve quin<strong>di</strong> prevedere<br />
<strong>un</strong> secondo tipo <strong>di</strong> link, detto link <strong>di</strong> propagazione, che permetta <strong>di</strong> risalire<br />
nella gerarchia dei no<strong>di</strong> presenti nel dominio del documento per propagare le<br />
versioni come richiesto dal <strong>modello</strong> D3IM.<br />
In corrispondenza <strong>di</strong> tutti i link <strong>di</strong> composizione presenti nell’ultima revisione<br />
<strong>di</strong> ogni branch <strong>di</strong> qualsiasi nodo, esistono i relativi link <strong>di</strong> propagazione<br />
che hanno verso opposto.<br />
Documento al tempo t 0<br />
X1<br />
P1 P2<br />
C1 C2<br />
Y1 Z1<br />
Legenda: tipologie <strong>di</strong> link<br />
Documento al tempo t 1<br />
C1<br />
Link <strong>di</strong> Propagazione<br />
Link <strong>di</strong> Composizione<br />
Link <strong>di</strong> Versione<br />
X1<br />
C2<br />
P3<br />
V2<br />
C3<br />
X2<br />
C4<br />
Y1 Y2 Z1<br />
V1<br />
Figura 6.2: Gestione dei link <strong>di</strong> propagazione.<br />
Per chiarire questo concetto si faccia riferimento alla figura 6.2 nella quale<br />
il documento al tempo t0 è costituito da <strong>un</strong>a ra<strong>di</strong>ce X1 che aggrega due figli<br />
P4<br />
131
Versioning in CISA Lo storico in CISA<br />
Y1 e Z1 tramite opport<strong>un</strong>i link <strong>di</strong> composizione, rispettivamente C1 e C2.<br />
Esistendo <strong>un</strong>a sola revisione <strong>di</strong> ogni nodo a tali link <strong>di</strong> composizione vengono<br />
associati i link <strong>di</strong> propagazione P1 e P2. Il documento al tempo t1 appare<br />
dopo <strong>un</strong>a mo<strong>di</strong>fica (in conformità al meccanismo previsto in D3IM) relativa<br />
a Y e propagata alla ra<strong>di</strong>ce X. In questo caso i link <strong>di</strong> propagazione P1 e P2<br />
sono stati rimossi e sono stati inseriti P3 e P4 in corrispondenza dei link <strong>di</strong><br />
composizione C3 e C4 presenti nell’ultima revisione della ra<strong>di</strong>ce X.<br />
Infine esiste <strong>un</strong> terzo tipo <strong>di</strong> link, detto link <strong>di</strong> versione, che permette<br />
<strong>di</strong> rappresentare le relazioni presenti fra no<strong>di</strong> appartenenti allo storico <strong>di</strong><br />
<strong>un</strong>a determinata informazione. Fanno parte <strong>di</strong> questa categoria i legami<br />
esistenti fra <strong>un</strong>a revisione e la successiva, <strong>un</strong>a revisione e la precedente etc.<br />
(tutte le tipologie <strong>di</strong> link che rientrano in questa categoria verranno introdotte<br />
dettagliatamente nel paragrafo 7.2 a pagina 169). In figura 6.2 è presente <strong>un</strong><br />
esempio nel quale si ipotizza l’esistenza dei soli link <strong>di</strong> versione presenti dalla<br />
revisione precedente a quella successiva.<br />
La gestione integrale dei link <strong>di</strong> versione e <strong>di</strong> propagazione è indubbiamente<br />
<strong>di</strong> competenza del livello Structure. Il <strong>di</strong>scorso è <strong>di</strong>verso se si parla<br />
dei link <strong>di</strong> composizione, in tal caso esiste <strong>un</strong>a minima sovrapposizione delle<br />
mansioni fra Virtual Repository e Structure.<br />
Virtual Repository è responsabile della gestione degli aspetti strutturali<br />
dei documenti. Questo significa che la definizione (ovvero la creazione), la<br />
mo<strong>di</strong>fica, la cancellazione e la navigazione nello spazio delle relazioni che i<br />
suddetti link definiscono sono operazioni <strong>di</strong> sua competenza.<br />
Dall’altro lato c’è Structure che deve poter propagare le versioni dai figli<br />
verso i genitori seguendo i link <strong>di</strong> propagazione. Prendendo l’esempio precedente<br />
(figura 6.2), la nascita <strong>di</strong> <strong>un</strong>a nuova versione del figlio (Y2) crea,<br />
tramite il meccanismo <strong>di</strong> propagazione, <strong>un</strong>a nuova versione del genitore (X2)<br />
che deve essere connessa, tramite <strong>un</strong> link <strong>di</strong> composizione (C3), alla nuova<br />
versione del figlio.<br />
La creazione della nuova versione del genitore è a carico del layer Structure<br />
il quale, per poter connettere tale elemento alla nuova versione del figlio, deve<br />
essere in grado <strong>di</strong> manipolare i link <strong>di</strong> composizione (nell’esempio si tratta <strong>di</strong><br />
creare C3 e C4).<br />
Si osservi che non esiste <strong>un</strong>a reale violazione della separation of concern<br />
in quanto le motivazioni che spingono i due layer ad agire sui link <strong>di</strong><br />
composizione sono <strong>di</strong>verse.<br />
Inoltre, operando come descritto più avanti, non esiste neanche la viola-<br />
132
Versioning in CISA Lo storico in CISA<br />
zione dell’information hi<strong>di</strong>ng che si avrebbe permettendo ad entrambi i layer<br />
<strong>di</strong> intervenire sulle relazioni strutturali. È infatti sufficiente affidare a Structure<br />
l’onere <strong>di</strong> definire e gestire la struttura dati che permette <strong>di</strong> descrivere<br />
le relazioni in<strong>di</strong>viduate dai link <strong>di</strong> composizione. In altre parole tali link vengono<br />
gestiti esclusivamente da Structure e mantenuti all’interno dell’header<br />
del nodo definito a questo livello. Inoltre è necessario corredare l’interfaccia,<br />
fornita a Virtual Repository, <strong>di</strong> opport<strong>un</strong>e primitive e/o definire il formato<br />
dei messaggi scambiati fra i due livelli in modo da permettere a Virtual<br />
Repository <strong>di</strong> agire, secondo le proprie necessità e competenze, sugli aspetti<br />
strutturali del documento. Questo permette a Virtual Repository <strong>di</strong> inserire,<br />
mo<strong>di</strong>ficare ed eliminare i link <strong>di</strong> composizione in base alle proprie esigenze e<br />
navigare nello spazio del documento che essi contribuiscono a definire.<br />
Questo meccanismo è simile a quello presente in DOM: l’interfaccia messa<br />
a <strong>di</strong>sposizione permette all’utilizzatore <strong>di</strong> creare, mo<strong>di</strong>ficare, cancellare e<br />
navigare fra i no<strong>di</strong> dell’albero del documento (nel caso in esame l’utilizzatore<br />
è il livello Virtual Repository), mentre è la libreria in uso (che implementa<br />
DOM) ad avere l’onere <strong>di</strong> gestire la logica interna della struttura e la co<strong>di</strong>fica<br />
delle relazioni fra no<strong>di</strong> (in questo caso tale compito spetta a Structure).<br />
6.2.3 Gestione delle revisioni: la propagazione<br />
Nel <strong>modello</strong> D3IM le informazioni atomiche costituiscono l’insieme dei<br />
dati contenuti nel documento. Essendo il documento strutturato, tali dati<br />
sono messi in relazione tramite le informazioni primitive. La struttura è gerarchica:<br />
i no<strong>di</strong> che si trovano ai livelli più alti della gerarchia rappresentano,<br />
da <strong>un</strong> p<strong>un</strong>to <strong>di</strong> vista concettuale, il p<strong>un</strong>to d’accesso all’informazione strutturata<br />
che si sviluppa da essi fino alle foglie. Mo<strong>di</strong>ficare <strong>un</strong>o qual<strong>un</strong>que dei no<strong>di</strong><br />
appartenenti a tale gerarchia significa mo<strong>di</strong>ficare l’informazione complessiva.<br />
Considerando l’esempio <strong>di</strong> <strong>un</strong> libro, costituito da capitoli sud<strong>di</strong>visi a loro<br />
volta in paragrafi che sono <strong>un</strong> insieme <strong>di</strong> frasi, mo<strong>di</strong>ficare <strong>un</strong>a frase significa<br />
mo<strong>di</strong>ficare il paragrafo che la contiene, ma anche il capitolo contenente il<br />
paragrafo e, in ultima analisi, tutto il libro.<br />
D3IM permette <strong>di</strong> modellare il comportamento descritto tramite il concetto<br />
<strong>di</strong> propagazione che viene applicato sui genitori in corrispondenza della<br />
nascita <strong>di</strong> <strong>un</strong>a nuova revisione dei figli all’interno della gerarchia del documento.<br />
Si osservi che la richiesta <strong>di</strong> salvataggio <strong>di</strong> <strong>un</strong>a variazione del contenuto<br />
133
Versioning in CISA Lo storico in CISA<br />
<strong>di</strong> <strong>un</strong> nodo non genera necessariamente <strong>un</strong>a nuova revisione. A tal riguardo<br />
possono presentarsi due casi, che <strong>di</strong>pendono dal valore dello stato UPDATE<br />
del nodo (paragrafo 4.4 a pagina 91):<br />
• frozen: il sistema crea <strong>un</strong>a nuova revisione del nodo ed avvia il meccanismo<br />
<strong>di</strong> propagazione (viene creata <strong>un</strong>a nuova revisione in quanto il<br />
nodo <strong>di</strong> partenza è “congelato” e non può essere mo<strong>di</strong>ficato);<br />
• changing: il sistema sovrascrive il contenuto del nodo e non attua<br />
ness<strong>un</strong>a propagazione.<br />
Nel seguito <strong>di</strong> questa trattazione, se non espressamente specificato, si<br />
assume che lo stato UPDATE valga “frozen”. Il motivo è dovuto al fatto<br />
che in corrispondenza della nascita <strong>di</strong> <strong>un</strong>a nuova revisione occorre com<strong>un</strong>que<br />
apportare alc<strong>un</strong>e variazioni (sovrascritture) alle strutture dati <strong>di</strong> competenza<br />
<strong>di</strong> Structure, interne al nodo <strong>di</strong> partenza. Nel caso in cui il valore sia “frozen”<br />
il salvataggio è infatti costituito dalle seguenti tre fasi:<br />
1. creazione della nuova revisione;<br />
2. mo<strong>di</strong>fica del contenuto della revisione precedente per l’aggiornamento<br />
delle relazioni <strong>di</strong> versione;<br />
3. esecuzione dell’algoritmo <strong>di</strong> propagazione verso i genitori.<br />
Ogn<strong>un</strong>a <strong>di</strong> queste fasi prevede la sovrascrittura (operazione equivalente al<br />
caso in cui il valore sia “changing”) dei no<strong>di</strong> interessati per applicare su <strong>di</strong><br />
essi le mo<strong>di</strong>fiche richieste. Per quanto riguarda il caso 1 la sovrascrittura<br />
è necessaria per inserire il contenuto corretto nel nodo appena creato, negli<br />
altri due casi serve per aggiornare i vari link in gioco.<br />
Il meccanismo <strong>di</strong> propagazione è stato descritto nel paragrafo 2.4 (a pagina<br />
33) nel quale è descritto il <strong>modello</strong> UEVM. Si noti, come osservato in<br />
precedenza, che in questa sede, a <strong>di</strong>fferenza del caso preso in esame in UEVM,<br />
la struttura <strong>di</strong> riferimento è <strong>un</strong> DAG e quin<strong>di</strong> ogni nodo può avere zero, <strong>un</strong>o<br />
o più genitori (mentre in UEVM può avere al massimo <strong>un</strong> genitore in quanto<br />
la struttura è <strong>un</strong> albero). Questo aspetto è ininfluente ai fini dell’algoritmo<br />
<strong>di</strong> propagazione a patto <strong>di</strong> applicarlo a tutti i genitori presenti.<br />
134
Versioning in CISA Lo storico in CISA<br />
Propagazione “push” e propagazione “pull”<br />
Il concetto <strong>di</strong> responsabile dell’informazione è legato alle politiche <strong>di</strong><br />
accesso all’informazione stessa che riguardano sia la lettura che la mo<strong>di</strong>fica.<br />
Senza perdere in generalità si assume che:<br />
• l’identificazione dell’utente avvenga contestualmente alla sua proiezione<br />
nel sistema, ovvero tramite l’Avatar;<br />
• il responsabile decida quali sono gli Avatar autorizzati ad accedere in<br />
lettura o in scrittura ad <strong>un</strong>a data informazione;<br />
• sia presente <strong>un</strong>’infrastruttura finalizzata alla gestione degli aspetti legati<br />
alla sicurezza operativa dell’architettura che permetta <strong>di</strong> associare<br />
ogni azione (in<strong>di</strong>viduabile nel sistema) ad <strong>un</strong> Avatar.<br />
Si consideri, per esempio, l’accesso ad <strong>un</strong>’informazione da parte <strong>di</strong> <strong>un</strong><br />
utente: questo, tramite il proprio Avatar A, fa pervenire la richiesta <strong>di</strong> lettura<br />
a Virtual Repository. Conseguentemente si innescano tutti i meccanismi<br />
necessari per il reperimento e la successiva presentazione dell’informazione<br />
all’utente. Una delle operazioni che senz’altro viene effettuata riguarda l’accesso<br />
fisico ad <strong>un</strong>a delle repliche da parte <strong>di</strong> Replica Management. Si suppone<br />
che il meccanismo <strong>di</strong> cui sopra sia in grado <strong>di</strong> associare all’Avatar A l’azione<br />
<strong>di</strong> lettura che Replica Management si vede pervenire da Structure. Questa<br />
associazione permette a Replica Management, ad esempio, <strong>di</strong> ricercare l’Avatar<br />
A nella tabella degli utenti autorizzati ad accedere alla risorsa in modo<br />
da poter stabilire se sod<strong>di</strong>sfare o meno la richiesta 2 .<br />
Alla luce <strong>di</strong> questa breve descrizione 3 , è possibile analizzare le due modalità<br />
previste per il meccanismo <strong>di</strong> propagazione: push e pull. Si osservi che<br />
queste non sono mutuamente esclusive: è possibile portare a termine l’aggiornamento<br />
<strong>di</strong> tutti i no<strong>di</strong> interessati dalla propagazione operando in parte<br />
in modalità “push” e in parte in modalità “pull”.<br />
2 La gestione delle identità e dei permessi sui no<strong>di</strong> del documento è onere <strong>di</strong> Virtual Repository.<br />
Si noti però che anche a livello Replica Management (ed eventualmente Me<strong>di</strong>um<br />
Dependent) devono essere previsti dei meccanismi <strong>di</strong> gestione <strong>di</strong> politiche per l’accesso<br />
ai dati, che altrimenti potrebbero essere letti e/o mo<strong>di</strong>ficati (in modo fraudolento) senza<br />
possibilità <strong>di</strong> controllo.<br />
3 In CISA gli aspetti legati alla sicurezza, alla gestione dei <strong>di</strong>ritti, etc. sono in fase <strong>di</strong><br />
sviluppo e, nel presente contesto possono essere considerati fra le problematiche per le<br />
quali la formalizzazione della soluzione viene rimandata a sviluppi futuri.<br />
135
Versioning in CISA Lo storico in CISA<br />
Push. L’algoritmo “push”, eseguito in modo centralizzato, aggiorna ogni<br />
elemento presente nella gerarchia degli antenati del nodo (N) dal quale parte<br />
il meccanismo <strong>di</strong> propagazione. Viene infatti eseguito integralmente dal<br />
processo <strong>di</strong> livello Structure che riceve la richiesta <strong>di</strong> mo<strong>di</strong>fica <strong>di</strong> N per conto<br />
dell’Avatar A che ha effettuato la richiesta.<br />
Questa soluzione ha il vantaggio <strong>di</strong> essere la più semplice, ma ha almeno<br />
due inconvenienti.<br />
Il primo è relativo al fatto che l’Avatar A deve essere stato precedentemente<br />
autorizzato ad intervenire su tutti i no<strong>di</strong> della gerarchia. Questo<br />
aspetto complica la procedura <strong>di</strong> aggregazione per composizione che deve<br />
quin<strong>di</strong> prevedere <strong>un</strong>a fase nella quale vengono concessi i <strong>di</strong>ritti <strong>di</strong> mo<strong>di</strong>fica<br />
(almeno degli aspetti strutturali) ai responsabili <strong>di</strong> tutti i documenti presenti<br />
nella gerarchia.<br />
Nell’esempio <strong>di</strong> figura 6.3 l’inserimento della nuova relazione <strong>di</strong> composizione<br />
dal nodo H al nodo I deve essere accompagnato dall’aggi<strong>un</strong>ta dei<br />
responsabili B e C fra gli autorizzati alla mo<strong>di</strong>fica dei no<strong>di</strong>, presenti nella<br />
gerarchia, sotto la responsabilità <strong>di</strong> A (nello specifico i no<strong>di</strong> G ed H).<br />
Questa operazione è necessaria per permettere la propagazione. Ad esempio<br />
la mo<strong>di</strong>fica del nodo N da parte <strong>di</strong> C deve poter essere propagata, a nome<br />
<strong>di</strong> C, su tutta la gerarchia.<br />
L’altro inconveniente riguarda la scalabilità del sistema. In questo caso<br />
infatti il costo computazionale dell’algoritmo a carico <strong>di</strong> <strong>un</strong> singolo processo<br />
aumenta linearmente con il numero <strong>di</strong> no<strong>di</strong> che si trovano al <strong>di</strong> sopra <strong>di</strong> esso<br />
nella gerarchia. Questo limita il numero <strong>di</strong> documenti che possono aggregare<br />
per composizione <strong>un</strong>a data informazione. Si ricorda com<strong>un</strong>que che l’aggregazione<br />
per composizione è solo <strong>un</strong>a delle due alternative: ai livelli superiori è<br />
possibile gestire l’aggregazione per riferimento che, non coinvolgendo i meccanismi<br />
<strong>di</strong> propagazione, non ha ness<strong>un</strong>o degli inconvenienti menzionati e<br />
in molti casi può risultare più che sufficiente per modellare le relazioni esistenti<br />
fra le informazioni (si pensi che i collegamenti fra pagine web presenti<br />
nel WWW sono l’equivalente prototipale dei link <strong>di</strong> riferimento del <strong>modello</strong><br />
D3IM).<br />
Pull. L’algoritmo “pull” prevede che l’aggiornamento degli elementi appartenenti<br />
agli antenati del nodo N, da cui parte il meccanismo <strong>di</strong> propagazione,<br />
venga effettuato dai relativi responsabili. La descrizione <strong>di</strong> questa modali-<br />
136
Versioning in CISA Lo storico in CISA<br />
G<br />
Responsabile A<br />
Relazione<br />
Preesistente<br />
N<br />
M<br />
Responsabile C<br />
H<br />
L<br />
I<br />
Nuova<br />
relazione<br />
Responsabile B<br />
Figura 6.3: Concessione dei <strong>di</strong>ritti <strong>di</strong> mo<strong>di</strong>fica a tutti i responsabili nella<br />
gerarchia <strong>di</strong> successori.<br />
tà operativa, che sotto certi aspetti permette <strong>di</strong> superare alc<strong>un</strong>e limitazioni<br />
della precedente, viene lasciata agli sviluppi futuri.<br />
Il motivo <strong>di</strong> questa scelta è conseguenza del fatto che la modalità push è<br />
com<strong>un</strong>que sufficiente per l’efficacia del sistema e per implementare la modalità<br />
pull risulta necessario ricorrere al meccanismo <strong>di</strong> notifica introdotto nel<br />
paragrafo 5.1 (a pagina 107) attualmente in fase <strong>di</strong> definizione.<br />
Il principio <strong>di</strong> base è il seguente: il processo <strong>di</strong> layer Structure che riceve<br />
la richiesta <strong>di</strong> mo<strong>di</strong>fica <strong>di</strong> N attua la propagazione in modalità push per ogni<br />
antenato sul quale l’Avatar A ha autorità (in questo caso A è il responsabile<br />
dell’informazione oppure è stato autorizzato dal responsabile ad operare su<br />
<strong>di</strong> essa). Nel momento in cui, risalendo nella gerarchia, incontra <strong>un</strong> elemento<br />
137
Versioning in CISA Lo storico in CISA<br />
per il quale A non ha autorità il processo termina ed invia al responsabile<br />
che ha autorità su <strong>di</strong> esso <strong>un</strong>a notifica per segnalargli l’aggiornamento avvenuto.<br />
Tale Avatar (o meglio <strong>un</strong> agente software che opera per suo conto) può<br />
richiedere, secondo la modalità “pull”, la lettura dei no<strong>di</strong> aggiornati e avviare<br />
conseguentemente, tramite lo stesso o <strong>un</strong> altro processo <strong>di</strong> layer Structure, la<br />
propagazione sui no<strong>di</strong> <strong>di</strong> sua competenza. Questo meccanismo continua fino<br />
al termine dell’aggiornamento <strong>di</strong> tutti gli antenati.<br />
In riferimento all’esempio <strong>di</strong> figura 6.3 il processo <strong>di</strong> livello Structure,<br />
al quale viene richiesto il salvataggio delle mo<strong>di</strong>fiche sul nodo N, effettua<br />
la propagazione a M. Il responsabile dell’antenato <strong>di</strong> M (il nodo L) è B ed<br />
è <strong>di</strong>verso da C, responsabile <strong>di</strong> M. Il processo <strong>di</strong> livello Structure non si<br />
preoccupa quin<strong>di</strong> della propagazione verso L, ma si limita ad inoltrare <strong>un</strong>a<br />
notifica <strong>di</strong> aggiornamento al suo responsabile, B. L’Avatar <strong>di</strong> B, tramite <strong>un</strong><br />
opport<strong>un</strong>o agente, si preoccupa <strong>di</strong> aggiornare L dando vita ad <strong>un</strong> nuovo<br />
meccanismo <strong>di</strong> propagazione che, nell’esempio, prosegue fino ad I. L’ulteriore<br />
variazione <strong>di</strong> responsabile che si ha risalendo verso H dà vita ad <strong>un</strong>a nuova<br />
notifica verso A e l’algoritmo prosegue secondo la modalità descritta.<br />
Si osservi come entrambi i problemi evidenziati con la modalità “push”<br />
risultino risolti. Da <strong>un</strong> lato non è necessario “ere<strong>di</strong>tare” i <strong>di</strong>ritti in fase <strong>di</strong> aggregazione,<br />
in quanto sarà l’Avatar del responsabile <strong>di</strong> ogni nodo a procedere<br />
con la propagazione su <strong>di</strong> esso, dall’altro la scalabilità risulta effettivamente<br />
più elevata poiché la propagazione globale avviene tramite l’esecuzione <strong>di</strong> <strong>un</strong><br />
algoritmo totalmente <strong>di</strong>stribuito. Si osservi che, in questo caso, esiste <strong>un</strong><br />
rovescio della medaglia: il vantaggio ottenuto in termini <strong>di</strong> efficienza viene<br />
pagato in termini <strong>di</strong> complessità nella definizione ed implementazione dell’algoritmo<br />
e del protocollo <strong>di</strong> com<strong>un</strong>icazione a causa della maggiore <strong>di</strong>fficoltà<br />
che si incontra per garantirne l’efficacia.<br />
6.2.4 Branching e merging<br />
Le operazioni <strong>di</strong> branching e <strong>di</strong> merging risultano essere, da <strong>un</strong> p<strong>un</strong>to <strong>di</strong><br />
vista logico, legate alla gestione dello storico <strong>di</strong> <strong>un</strong> documento e sono state<br />
introdotte nel paragrafo 2.1 a pagina 24. Creare <strong>un</strong> branch può essere utile<br />
per i motivi più <strong>di</strong>sparati che variano in base al contesto. Quello che è certo<br />
è che risulta necessario, parlando <strong>di</strong> versioning in senso lato, considerare i<br />
branch e la loro gestione. Nella “gestione” rientrano le operazioni <strong>di</strong> creazione<br />
138
Versioning in CISA Lo storico in CISA<br />
dei branch, <strong>di</strong> navigazione dello storico, costituito da più rami <strong>di</strong> sviluppo<br />
paralleli, ed ovviamente <strong>di</strong> convergenza (merge).<br />
Nel momento in cui si crea <strong>un</strong> branch la gestione dell’evoluzione temporale<br />
al suo interno risulta essere del tutto in<strong>di</strong>pendente rispetto a quella relativa<br />
al documento <strong>di</strong> provenienza.<br />
Generare <strong>un</strong> branch equivale a creare <strong>un</strong> nuovo documento che abbia in<br />
com<strong>un</strong>e con quello <strong>di</strong> partenza almeno <strong>un</strong> nodo dello storico. In conclusione<br />
all’interno <strong>di</strong> ogni branch esiste <strong>un</strong> or<strong>di</strong>namento totale delle revisioni che modella<br />
l’evoluzione temporale del documento (relativo a quel branch), inoltre<br />
non esiste ness<strong>un</strong>a correlazione fra revisioni appartenenti a branch <strong>di</strong>versi, se<br />
non quella <strong>di</strong> avere predecessori (nello storico) com<strong>un</strong>i.<br />
L’equivalenza a cui è stato appena fatto riferimento fra branch e nuovo<br />
documento non è soltanto concettuale, ma è stata sfruttata ampiamente nella<br />
pratica in molti SCM (Software Configuration Management), fra i quali il già<br />
citato Subversion, CVS, eccetera.<br />
Per comprendere le scelte che hanno permesso <strong>di</strong> introdurre nel layer<br />
Structure le operazioni <strong>di</strong> branch e <strong>di</strong> merge è sicuramente utile fare riferimento<br />
a Subversion (paragrafo 2.8, pagina 53) che utilizza <strong>un</strong> <strong>modello</strong> <strong>di</strong><br />
versioning molto simile a quello definito in CISA (entrambi i modelli derivano<br />
da UEVM).<br />
Richiami <strong>di</strong> branching e merging in Subversion<br />
In Subversion non è previsto <strong>un</strong> meccanismo esplicito per la gestione dei<br />
branch, in particolare non esiste ness<strong>un</strong> comando o primitiva che ne permetta<br />
la creazione. I branch vengono gestiti esplicitamente e consapevolmente<br />
dall’utente tramite il comando <strong>di</strong> copia: nel momento in cui l’utente desidera<br />
creare <strong>un</strong> branch effettua <strong>un</strong>a copia del sotto albero del file system in cui<br />
sono memorizzati tutti i file relativi alla configurazione a partire dalla quale<br />
intende creare il nuovo branch.<br />
Il manuale ufficiale <strong>di</strong> Subversion [CSFP04] consiglia, senza porre ness<strong>un</strong><br />
vincolo, <strong>di</strong> operare creando <strong>un</strong>a <strong>di</strong>rectory nel repository per ogni progetto 4 ,<br />
tale <strong>di</strong>rectory deve a sua volta contenere due sotto <strong>di</strong>rectory chiamate“tr<strong>un</strong>k”<br />
e “branches”.<br />
4 Nel caso in esame è opport<strong>un</strong>o parlare <strong>di</strong> documento. In realtà, per semplificare, si<br />
può supporre <strong>di</strong> creare <strong>un</strong> nuovo repository per ogni documento in modo da garantire<br />
l’in<strong>di</strong>pendenza degli storici.<br />
139
Versioning in CISA Lo storico in CISA<br />
documento1<br />
tr<strong>un</strong>k<br />
file1<br />
file2<br />
branches<br />
il_mio_branch<br />
file1<br />
file2<br />
altro_branch<br />
file1<br />
file2<br />
documento2<br />
tr<strong>un</strong>k<br />
fileA<br />
fileB<br />
<strong>di</strong>r<br />
branches<br />
Figura 6.4: Organizzazione tipica <strong>di</strong> <strong>un</strong> progetto gestito con Subversion.<br />
La prima <strong>di</strong> esse (“tr<strong>un</strong>k”) contiene i file relativi al ramo principale, l’altra<br />
(“branches”) tante sotto <strong>di</strong>rectory quanti sono i branch creati dall’utente.<br />
In riferimento alla figura 6.4, per creare il branch il mio branch, relativo<br />
all’intero progetto documento1, l’utente crea per prima cosa l’opport<strong>un</strong>a<br />
<strong>di</strong>rectory in branches e successivamente copia in essa il contenuto <strong>di</strong> tr<strong>un</strong>k.<br />
L’operazione <strong>di</strong> copia deve essere effettuata agendo <strong>di</strong>rettamente sul repository<br />
tramite lo specifico comando <strong>di</strong> copia e non effettuando la copia dei singoli<br />
file all’interno della <strong>di</strong>rectory <strong>di</strong> lavoro dell’utente. Tale comando permette<br />
a Subversion <strong>di</strong> effettuare la copia e, allo stesso tempo, <strong>di</strong> far con<strong>di</strong>videre lo<br />
storico (fino all’istante precedente all’operazione) fra la sorgente e la destinazione<br />
della copia stessa. È scorretto effettuare prima la copia all’interno<br />
dell’area <strong>di</strong> lavoro dell’utente e successivamente il commit per aggiornare il<br />
repository poiché in tal modo il sistema non riconosce i file copiati come legati<br />
agli originali e verrebbero quin<strong>di</strong> considerati come nuove entità con <strong>un</strong><br />
proprio storico in<strong>di</strong>pendente da quello della sorgente.<br />
fileC<br />
140
Versioning in CISA Lo storico in CISA<br />
È buona regola infatti non effettuare il checkout 5 <strong>di</strong> tutto il progetto,<br />
ma soltanto della <strong>di</strong>rectory contenente il branch <strong>di</strong> interesse in modo tale<br />
da far figurare nell’area <strong>di</strong> lavoro dell’utente soltanto tale branch. In questo<br />
modo non è possibile effettuare copie <strong>di</strong> file da <strong>un</strong> branch all’altro all’interno<br />
dell’area <strong>di</strong> lavoro, neanche accidentalmente.<br />
Per quanto riguarda il merging, il concetto <strong>di</strong> fusione <strong>di</strong> <strong>un</strong> branch in <strong>un</strong><br />
altro si ritrova in modo in<strong>di</strong>retto tramite il concetto <strong>di</strong> antenato. Il merging<br />
è infatti <strong>un</strong>’operazione definita fra due <strong>di</strong>rectory <strong>di</strong>stinte. Nel caso in cui<br />
il contenuto delle due <strong>di</strong>rectory sia costituito da elementi che con<strong>di</strong>vidono<br />
<strong>un</strong>a parte dello storico (ovvero che sono stati creati tramite copia e quin<strong>di</strong><br />
associabili in<strong>di</strong>rettamente al concetto <strong>di</strong> branch) il sistema li confronta nei<br />
contenuti: per le <strong>di</strong>rectory significa operare ricorsivamente entrando al loro<br />
interno, per i file significa compararli riga per riga.<br />
Supponendo che <strong>un</strong>o sviluppatore che opera nel ramo principale crei <strong>un</strong><br />
file (o <strong>di</strong>rectory) con lo stesso nome e la stessa posizione relativa <strong>di</strong> quello<br />
creato da <strong>un</strong> secondo sviluppatore che opera nel branch, i due file omonimi<br />
vengono trattati, durante il merge, come entità <strong>di</strong>stinte in quanto non con<strong>di</strong>vidono<br />
ness<strong>un</strong> antenato nello storico e pertanto non vengono confrontati.<br />
Il sistema avverte l’utente, che ha richiesto il merge, della presenza <strong>di</strong> <strong>un</strong><br />
conflitto senza risolverlo <strong>di</strong>rettamente. Se questo comportamento, che permette<br />
<strong>di</strong> capire che le due entità in esame appartengono a due branch <strong>di</strong>versi,<br />
non è quello voluto è possibile inibire la verifica <strong>di</strong> parentela e in tal caso il<br />
confronto avviene com<strong>un</strong>que.<br />
Branching da D3IM a CISA<br />
Per proseguire con l’analisi del problema è utile descrivere come potrebbe<br />
essere implementato <strong>un</strong> clone <strong>di</strong> Subversion adattato come applicazione<br />
basata sull’architettura CISA. Questo permette sia <strong>di</strong> comprendere meglio<br />
i principi che hanno condotto alla definizione del branching (e del merging)<br />
in CISA sia <strong>di</strong> mostrare come CISA risulti <strong>un</strong>’architettura flessibile e adattabile<br />
(tramite la definizione <strong>di</strong> <strong>un</strong> opport<strong>un</strong>o livello applicativo) a svariati<br />
contesti, <strong>un</strong>o dei quali potrebbe essere app<strong>un</strong>to lo sviluppo concorrente <strong>di</strong><br />
co<strong>di</strong>ce sorgente da parte <strong>di</strong> più programmatori (ambito nel quale si colloca<br />
Subversion).<br />
5 Si ricorda che l’operazione <strong>di</strong> checkout è quella che serve per effettuare <strong>un</strong>a copia locale<br />
(nell’area <strong>di</strong> lavoro dell’utente) <strong>di</strong> tutti o alc<strong>un</strong>i file presenti nel repository.<br />
141
Versioning in CISA Lo storico in CISA<br />
Per prima cosa occorre definire il <strong>modello</strong> per i dati: ogni progetto gestito<br />
in Subversion può essere definito come documento D3IM, operando come<br />
segue:<br />
• i file e le <strong>di</strong>rectory in Subversion sono informazioni primitive in D3IM;<br />
• il contenuto dei file in Subversion corrisponde alle informazioni atomiche<br />
<strong>di</strong> D3IM.<br />
Un file quin<strong>di</strong> è rappresentato da <strong>un</strong>’informazione primitiva che ne permette<br />
l’identificazione e da <strong>un</strong>’informazione atomica che ne memorizza il<br />
contenuto. Si osservi che è possibile rappresentare il file anche in modo più<br />
dettagliato considerando il contenuto come entità strutturata (ad esempio,<br />
per i file <strong>di</strong> testo, inserendo ogni riga del file in <strong>un</strong>’informazione atomica <strong>di</strong>stinta<br />
oppure, per il co<strong>di</strong>ce sorgente, andando a co<strong>di</strong>ficare in D3IM gli aspetti<br />
strutturali in esso presenti).<br />
I documenti così definiti sono strettamente strutturati ad albero in quanto<br />
la loro struttura riflette quella del file system 6 e sono, a pieno titolo,<br />
documenti D3IM vali<strong>di</strong>.<br />
Le operazioni <strong>di</strong> aggi<strong>un</strong>ta, cancellazione o mo<strong>di</strong>fica <strong>di</strong> <strong>un</strong> file (o <strong>di</strong>rectory)<br />
nel progetto equivalgono all’aggi<strong>un</strong>ta, la cancellazione o la mo<strong>di</strong>fica <strong>di</strong> <strong>un</strong><br />
nodo dell’albero del documento. A seguito <strong>di</strong> tale azione risulta mo<strong>di</strong>ficata<br />
anche la <strong>di</strong>rectory che contiene il file (o <strong>di</strong>rectory) in esame: tale mo<strong>di</strong>fica<br />
si propaga verso l’alto fino alla ra<strong>di</strong>ce del progetto con lo stesso meccanismo<br />
<strong>di</strong> propagazione presente in D3IM. Questo aspetto è evidente nella modalità<br />
con cui Subversion assegna i numeri <strong>di</strong> versione. Tali numeri sono relativi al<br />
progetto nella sua interezza e non alle singole parti che lo costituiscono.<br />
A questo p<strong>un</strong>to è possibile riprendere la descrizione della modalità operativa<br />
<strong>di</strong> Subversion relativa al branching ed al merging ed applicarla al contesto<br />
in esame. L’operazione <strong>di</strong> copia <strong>di</strong> <strong>un</strong>o o più elementi nel repository è tale<br />
che l’elemento <strong>di</strong> origine e l’elemento <strong>di</strong> destinazione con<strong>di</strong>vidono lo stesso<br />
storico fino al momento della copia. Il caso più semplice che può essere<br />
ipotizzato è quello nel quale è presente <strong>un</strong>a singola informazione primitiva<br />
(la <strong>di</strong>rectory, vuota, ra<strong>di</strong>ce del progetto). Creare <strong>un</strong> branch in questo caso<br />
significa generare <strong>un</strong>a <strong>di</strong>ramazione dello storico <strong>di</strong> <strong>un</strong> nodo, figura 6.5.<br />
6 In realtà, ricorrendo all’uso <strong>di</strong> link simbolici, è possibile creare strutture più complesse<br />
(DAG) che non hanno interesse nella presente trattazione.<br />
142
Versioning in CISA Lo storico in CISA<br />
Storico dell'elemento<br />
Storico con<strong>di</strong>viso<br />
R1 R2 R3 R4<br />
Copia o<br />
Branch<br />
R2.1 R2.2<br />
Figura 6.5: Risultato della copia <strong>di</strong> <strong>un</strong> file in Subversion: branch in D3IM.<br />
Deve essere quin<strong>di</strong> previsto <strong>un</strong> meccanismo che permetta <strong>di</strong> creare <strong>un</strong><br />
branch nello storico <strong>di</strong> <strong>un</strong> nodo al fine <strong>di</strong> considerarne tutta l’evoluzione temporale,<br />
<strong>di</strong>ramazioni comprese. Il concetto <strong>di</strong> branch deve com<strong>un</strong>que restare<br />
<strong>di</strong>stinto dal concetto <strong>di</strong> revisione sia per il sistema che per l’utente. I no<strong>di</strong> del<br />
documento a livello Struttura contengono al più <strong>un</strong> p<strong>un</strong>tatore alla revisione<br />
seguente e da zero ad infiniti p<strong>un</strong>tatori a branch.<br />
In riferimento alla figura 6.5, durante la navigazione nello storico, nel caso<br />
in cui venga richiesto l’elemento seguente al nodo R2 il sistema fornisce R3<br />
(che rappresenta l’effettivo successore) e l’in<strong>di</strong>cazione che esiste <strong>un</strong> branch il<br />
cui primo elemento è R2.1.<br />
Si osservi che in generale, mentre per creare la nuova revisione è sufficiente<br />
effettuare <strong>un</strong> commit sul nodo, per creare <strong>un</strong> branch occorre richiamare esplicitamente<br />
<strong>un</strong>’opport<strong>un</strong>a primitiva. Questo permette da <strong>un</strong> lato <strong>di</strong> evidenziare<br />
al massimo la <strong>di</strong>fferenza tra i concetti <strong>di</strong> revisione e <strong>di</strong> branch, dall’altro <strong>di</strong><br />
creare <strong>un</strong> branch anche a partire dall’ultima revisione <strong>di</strong>sponibile dell’elemento.<br />
Per eseguire quest’ultima operazione è necessario <strong>un</strong> meccanismo<br />
esplicito <strong>di</strong> creazione dei branch.<br />
In figura 6.6 è riportato <strong>un</strong> esempio <strong>di</strong> come Subversion operi al fine <strong>di</strong><br />
creare la copia della <strong>di</strong>rectory G (genitore) contenente <strong>un</strong> solo file F (figlio).<br />
Per Subversion creare <strong>un</strong> branch <strong>di</strong> <strong>un</strong>’informazione primitiva significa<br />
creare, ricorsivamente, <strong>un</strong> branch <strong>di</strong> ogni nodo dell’albero <strong>di</strong> cui essa è ra<strong>di</strong>ce.<br />
Questo comportamento in CISA viene ottenuto richiedendo il branching<br />
143
Versioning in CISA Lo storico in CISA<br />
Storico dell'elemento genitore<br />
G1 G2<br />
F1 F2<br />
G2.1<br />
F2.1<br />
Storico dell'elemento figlio<br />
Link <strong>di</strong><br />
Composizione<br />
Link <strong>di</strong> Revisione<br />
Link <strong>di</strong> Branch<br />
Figura 6.6: Risultato della copia <strong>di</strong> <strong>un</strong>a <strong>di</strong>rectory in Subversion.<br />
dei no<strong>di</strong> <strong>di</strong> interesse a livello Application (o Virtual Repository) in quanto<br />
è <strong>un</strong>’operazione che concettualmente è applicata al documento come entità<br />
strutturata. Questa scelta permette <strong>di</strong> ottenere anche <strong>un</strong>a maggiore<br />
flessibilità rispetto a quella <strong>di</strong> Subversion in quanto permette <strong>di</strong> ipotizzare<br />
l’esistenza <strong>di</strong> <strong>di</strong>ramazioni nelle quali non viene effettuato il branch <strong>di</strong> ogni<br />
nodo dell’albero lasciando <strong>un</strong>o o più no<strong>di</strong> in com<strong>un</strong>e fra il branch e il ramo<br />
principale.<br />
Quest’ultimo caso è messo in evidenza in figura 6.7 nella quale la ra<strong>di</strong>ce<br />
G ha due figli: F’ e F”. Il branch del documento è stato effettuato creando<br />
<strong>un</strong> branch della ra<strong>di</strong>ce e del figlio F’ mentre il figlio F”non è stato duplicato.<br />
Questo permette <strong>di</strong> propagare le mo<strong>di</strong>fiche <strong>di</strong> F”in entrambi i rami <strong>di</strong> sviluppo<br />
(il ramo principale, che si sviluppa creando <strong>un</strong>a nuova revisione <strong>di</strong> G2, e del<br />
branch che si sviluppa creando <strong>un</strong>a nuova revisione <strong>di</strong> G2.1).<br />
In figura 6.8 è presente l’effetto della propagazione. L’azione scatenante è<br />
la mo<strong>di</strong>fica <strong>di</strong> F”2 che, al tempo T , genera la revisione F”3 e la propagazione<br />
avviene su entrambi i branch dando vita alle revisioni G3 nel ramo principale<br />
e G2.2 nel branch. Per semplicità il figlio F’, presente in figura 6.7, non è<br />
stato riportato in quanto non viene mo<strong>di</strong>ficato durante la propagazione: G3<br />
continua ad aggregare F’2 come G2 e G2.2 continua ad aggregare F’2.1 come<br />
G2.1.<br />
144
Versioning in CISA Lo storico in CISA<br />
G1 G2<br />
F''1 F''2<br />
Figlio F''<br />
G1 G2<br />
F'1 F'2<br />
Figlio F'<br />
F''1 F''2<br />
Figlio F''<br />
Ra<strong>di</strong>ce G<br />
F'2.1<br />
G2.1<br />
Figura 6.7: Branch in D3IM con <strong>un</strong> figlio con<strong>di</strong>viso.<br />
G3<br />
G2.1 G2.2<br />
F''3<br />
Ra<strong>di</strong>ce G<br />
Legenda<br />
T = istante<br />
della nascita<br />
del nodo F''3<br />
Relazioni<br />
No<strong>di</strong><br />
Tempo t < T Tempo t ≥ T<br />
Figura 6.8: Propagazione in presenza <strong>di</strong> <strong>un</strong> figlio con<strong>di</strong>viso.<br />
Merging da D3IM a CISA<br />
L’operazione complementare al branching è il merging. Da <strong>un</strong> p<strong>un</strong>to <strong>di</strong><br />
vista concettuale effettuare <strong>un</strong> merge significa integrare le mo<strong>di</strong>fiche presenti<br />
su <strong>un</strong> branch in <strong>un</strong> altro branch. Nella pratica questa operazione può essere<br />
effettuata secondo modalità <strong>di</strong>verse che variano con il contesto.<br />
Supponendo quin<strong>di</strong> <strong>di</strong> operare con documenti D3IM occorre stabilire cosa<br />
significhi fondere informazioni atomiche e informazioni primitive, elementi<br />
che costituiscono i documenti presenti nei due branch <strong>di</strong> interesse. In realtà<br />
si ricorda che le informazioni atomiche sono incapsulate all’interno <strong>di</strong> quelle<br />
Abc<br />
Abc<br />
145
Versioning in CISA Lo storico in CISA<br />
primitive e, a livello Structure, sono del tutto invisibili.<br />
Il concetto <strong>di</strong> merge <strong>di</strong> informazioni atomiche è com<strong>un</strong>que necessario e<br />
si è scelto <strong>di</strong> fornire ai livelli superiori a Structure delle modalità <strong>di</strong> fusione<br />
elementari a partire dalle quali essi possano definire metodologie <strong>di</strong> merge<br />
più complesse (in base alle proprie esigenze).<br />
È possibile definire <strong>un</strong>’operazione <strong>di</strong> confronto fra due informazioni atomiche<br />
(che <strong>di</strong>pende dal tipo <strong>di</strong> informazione atomica trattata e quin<strong>di</strong>, in<br />
ultima analisi, dal contesto) che ne determina l’uguaglianza o la <strong>di</strong>fferenza.<br />
Nel primo caso il merge è banale e il risultato è l’informazione stessa; altrimenti<br />
l’operazione <strong>di</strong> confronto può permettere <strong>di</strong> stabilire l’entità della<br />
<strong>di</strong>fferenza e si possono presentare le seguenti situazioni:<br />
• il contesto permette al sistema <strong>di</strong> scegliere <strong>un</strong>a delle due informazioni<br />
automaticamente, scartando l’altra;<br />
• il contesto non permette al sistema <strong>di</strong> effettuare <strong>un</strong>a scelta, in tal caso<br />
è l’utente a dover prendere <strong>un</strong>a decisione;<br />
• le informazioni sono <strong>di</strong>verse, ma confrontabili nei contenuti: il sistema,<br />
automaticamente o sotto la supervisione dell’utente, genera <strong>un</strong>a terza<br />
informazione atomica sulla base <strong>di</strong> convenzioni prefissate.<br />
L’ultimo caso è interessante perché è quello relativo all’esempio, introdotto<br />
precedentemente, <strong>di</strong> Subversion: le informazioni atomiche sono rappresentate<br />
dal contenuto <strong>di</strong> file (molto probabilmente co<strong>di</strong>ce sorgente scritto<br />
in formato testuale); quin<strong>di</strong> è possibile applicare <strong>un</strong> confronto riga per riga,<br />
operazione che permette <strong>di</strong> integrare le <strong>di</strong>fferenze nel caso in cui non siano<br />
presenti conflitti (il sistema genera automaticamente la nuova versione) oppure<br />
è in grado <strong>di</strong> rilevarli e permette all’utente <strong>di</strong> intervenire (il sistema<br />
genera la nuova versione sotto la supervisione dell’utente).<br />
Per quanto riguarda le informazioni primitive, occorre specificare cosa si<br />
intende per uguaglianza tra <strong>di</strong> esse. Da <strong>un</strong> p<strong>un</strong>to <strong>di</strong> vista astratto è possibile<br />
considerarle come il p<strong>un</strong>to <strong>di</strong> accesso all’informazione complessiva che si<br />
sviluppa da esse fino alle foglie, come evidenziato nel sotto paragrafo 4.2.3.<br />
Questo porta alla conclusione che il concetto <strong>di</strong> uguaglianza fra informazioni<br />
primitive non è esprimibile esclusivamente sulla base del confronto del<br />
contenuto informativo dei no<strong>di</strong> che le rappresentano, ma in generale occorre<br />
andare a considerare e confrontare ricorsivamente i no<strong>di</strong> che tali informazioni<br />
primitive aggregano. Dato che questo compito spetta ai livelli superiori<br />
146
Versioning in CISA Lo storico in CISA<br />
occorre delegare a loro anche la scelta dei criteri finalizzati alla valutazione<br />
dell’uguaglianza o meno tra informazioni <strong>di</strong> questo tipo.<br />
A seguito <strong>di</strong> questa considerazione è possibile concludere che Structure<br />
deve fornire <strong>un</strong> supporto per il merging che permetta ai livelli superiori <strong>di</strong><br />
coprire tutte gli scenari possibili.<br />
In riferimento alla figura 6.9 la seguente definizione <strong>di</strong> merging, valida<br />
al livello Structure, permette <strong>di</strong> ottenere questo risultato: fondere (merge)<br />
due elementi A e B (no<strong>di</strong> D3IM) appartenenti a branch <strong>di</strong>versi dello stesso<br />
storico, significa generare <strong>un</strong> terzo elemento C ottenuto da essi a seguito<br />
dell’esecuzione <strong>di</strong> <strong>un</strong> determinato algoritmo. Il nuovo elemento C figura nello<br />
storico come successore sia <strong>di</strong> A che <strong>di</strong> B e, per convenzione, appartiene al<br />
ramo <strong>di</strong> A. La definizione e l’esecuzione dell’algoritmo <strong>di</strong> generazione vengono<br />
lasciate al livello applicativo e possono essere quin<strong>di</strong> <strong>di</strong>versificate in base al<br />
contesto.<br />
Storico dell'elemento<br />
A<br />
B<br />
C<br />
Fusione o Merge<br />
A,B in C.<br />
Figura 6.9: Merge <strong>di</strong> due no<strong>di</strong>.<br />
Si osservi che, in questi termini, il merge è <strong>un</strong>’operazione definita fra due<br />
branch che fonde il secondo sul primo. Questo si nota anche osservando che<br />
A e B devono essere l’ultima revisione nel relativo branch, come mostrato in<br />
figura. L’operatore <strong>di</strong> “merge” non è quin<strong>di</strong> commutativo: fondere A e B su<br />
C è <strong>di</strong>verso da fondere B e A su C. Nel primo caso C appartiene al ramo <strong>di</strong> A<br />
mentre nel secondo al ramo <strong>di</strong> B.<br />
Il fatto che l’elemento C sia il successore <strong>di</strong> entrambi gli elementi si evidenzia<br />
considerando che, a seguito <strong>di</strong> <strong>un</strong>’operazione <strong>di</strong> merge, viene attuata<br />
147
Versioning in CISA Lo storico in CISA<br />
la propagazione delle versioni in modo equivalente su entrambi i branch <strong>di</strong><br />
origine.<br />
G'7 G'8<br />
A<br />
B<br />
Nuove relazioni<br />
Vecchie relazioni<br />
G''4 G''5<br />
C<br />
Abc Nuovi no<strong>di</strong><br />
Abc Vecchi no<strong>di</strong><br />
Figura 6.10: Propagazione a seguito <strong>di</strong> <strong>un</strong> merge.<br />
Facendo riferimento alla figura 6.10 G’7, prima del merge, aggrega per<br />
composizione A mentre G”4 aggrega B. L’operazione <strong>di</strong> merge ha come risultato<br />
C. La nascita <strong>di</strong> C avvia il processo <strong>di</strong> propagazione dando vita a G’8 e<br />
a G”5.<br />
Si osservi che effettuare il merge <strong>di</strong> <strong>un</strong> ramo su <strong>un</strong> altro è <strong>un</strong>’operazione<br />
che determina, per convenzione, il raggi<strong>un</strong>gimento della fine del branch; dopo<br />
aver effettuato il merge non risulta più possibile generare nuove revisioni a<br />
partire dai no<strong>di</strong> fusi l’<strong>un</strong>o con l’altro, i no<strong>di</strong> A e B dell’esempio precedente.<br />
Questa limitazione è soltanto apparente in quanto è possibile generare nuovi<br />
branch partendo da essi. In questo modo si può com<strong>un</strong>que “simulare” la<br />
strategia <strong>di</strong> lavoro che consiste nel portare avanti lo sviluppo su due branch<br />
separati integrando, quando necessario, le mo<strong>di</strong>fiche <strong>di</strong> <strong>un</strong>o nell’altro. Infatti<br />
si può pensare che C appartenga ad <strong>un</strong>o dei due branch <strong>di</strong> partenza (ad<br />
esempio quello nel quale si trova A) mentre a partire dall’altro (B) viene<br />
generato <strong>un</strong> nuovo branch sul quale continuare lo sviluppo.<br />
Un esempio relativo a questo caso è riportato in figura 6.11.a. In particolare<br />
A, B e C sono i no<strong>di</strong> che in figura sono stati creati rispettivamente al<br />
148
Versioning in CISA Lo storico in CISA<br />
tempo 1, 2 e 3. Lo sviluppo vuole essere portato avanti anche su <strong>un</strong> ramo<br />
secondario e per questo motivo viene creato, al tempo 4, <strong>un</strong> nuovo branch.<br />
Successivamente viene effettuato il merge con il ramo <strong>di</strong> sviluppo principale;<br />
si osservi che non è obbligatorio effettuare questa operazione imme<strong>di</strong>atamente<br />
in quanto è possibile creare <strong>un</strong> numero arbitrario interme<strong>di</strong>o <strong>di</strong> nuove<br />
revisioni.<br />
Tempo<br />
Storico dell'elemento<br />
1 3<br />
2<br />
Ramo Principale<br />
Branch<br />
Ramo Secondario<br />
Merge<br />
4<br />
Merge<br />
Branch<br />
a) Sequenze <strong>di</strong> branch<br />
e <strong>di</strong> merge.<br />
5<br />
6<br />
Tempo<br />
Storico dell'elemento<br />
1 3<br />
Integrazione<br />
Ramo Principale<br />
2 4<br />
Ramo Secondario<br />
b) Integrazioni a livello<br />
applicativo.<br />
5<br />
Integrazione<br />
Figura 6.11: Gestione <strong>di</strong> due rami <strong>di</strong> sviluppo concorrente.<br />
Infine <strong>un</strong>’altra strategia possibile consiste nel definire <strong>un</strong> “merge <strong>di</strong> livello<br />
applicativo” che, a partire da B, integri le mo<strong>di</strong>fiche in A generando C, senza<br />
rendere B antenato <strong>di</strong> C a livello Structure. In questo modo, partendo da<br />
B, è possibile continuare lo sviluppo generando nuove revisioni. Un esempio<br />
relativo a quest’ultimo caso è riportato in figura 6.11.b, come in precedenza,<br />
i no<strong>di</strong> A, B e C corrispondono rispettivamente a quelli creati al tempo 1, 2 e<br />
3.<br />
Gestione degli aspetti strutturali del documento<br />
Il branching e il merging sono stati definiti e <strong>di</strong>scussi, in modo rigoroso,<br />
in riferimento ad <strong>un</strong> singolo nodo D3IM oppure in riferimento al caso <strong>di</strong> <strong>un</strong><br />
nodo D3IM aggregato per composizione da altri no<strong>di</strong>.<br />
Per quanto riguarda le relazioni “figlio-genitori”, necessarie per la gestione<br />
della propagazione delle mo<strong>di</strong>fiche, l’aver considerato soltanto due livelli<br />
6<br />
149
Versioning in CISA Lo storico in CISA<br />
della gerarchia nella struttura del documento non è limitativo. Tutti i ragionamenti<br />
effettuati, possono essere ripetuti ricorsivamente permettendo quin<strong>di</strong><br />
<strong>di</strong> risalire, livello dopo livello, la struttura <strong>di</strong> <strong>un</strong> qual<strong>un</strong>que documento,<br />
in<strong>di</strong>pendentemente dalla sua <strong>di</strong>mensione.<br />
Al contrario le relazioni inverse, quelle “genitore-figli”, necessarie per modellare<br />
la struttura del documento, non vengono gestite dal livello Structure<br />
e pertanto, in questo contesto, non risulta strettamente necessario <strong>di</strong>scutere<br />
come devono essere trattate in riferimento al branching e al merging.<br />
In ogni caso il branching e il merging <strong>di</strong> <strong>un</strong> documento, visto nella sua<br />
globalità, sono strettamente legati al versioning e risulta quin<strong>di</strong> interessante<br />
presentare alc<strong>un</strong>i possibili scenari nei quali si mostra come possono essere<br />
applicati in contesti reali.<br />
Si considerino, ad esempio, dei documenti (costituiti da <strong>un</strong> numero arbitrario<br />
<strong>di</strong> no<strong>di</strong>) che devono essere trattati nei branch come <strong>un</strong>’<strong>un</strong>ica entità.<br />
Questo è esattamente il caso gestito da Subversion in quanto la copia del<br />
ramo principale in <strong>un</strong> branch è ricorsiva e si sviluppa dalla ra<strong>di</strong>ce fino alle<br />
foglie dell’albero, comprendendo tutti gli elementi.<br />
Per quanto riguarda D3IM questo significa creare <strong>un</strong> branch <strong>di</strong> ogni nodo<br />
secondo le modalità esposte in precedenza e connettere il nodo che si ottiene<br />
a seguito del branch <strong>di</strong> ogni genitore al nodo ottenuto dal branch dei figli<br />
come introdotto in figura 6.6 ed ulteriormente evidenziato in figura 6.12.<br />
La fase <strong>di</strong> merging viene trattata in modo duale andando ad applicare<br />
opport<strong>un</strong>i algoritmi <strong>di</strong> confronto e generando <strong>un</strong>a nuova versione per ogni<br />
coppia <strong>di</strong> no<strong>di</strong> che vengono fusi. Si osservi che, in questo esempio, è necessario<br />
fondere tutti i no<strong>di</strong> degli alberi relativi ai documenti D1 e D2 per ottenere <strong>un</strong><br />
terzo documento che concettualmente rappresenta il risultato dell’operazione.<br />
Teoricamente niente vieta <strong>di</strong> fondere soltanto <strong>un</strong>a parte dei no<strong>di</strong> ed ottenere<br />
<strong>un</strong>a struttura ibrida nella quale non risulta possibile in<strong>di</strong>viduare tre<br />
documenti <strong>di</strong>stinti, ma parzialmente sovrapposti.<br />
Dualmente è possibile effettuare il branch anche solo su <strong>un</strong>a parte dei<br />
no<strong>di</strong> <strong>di</strong> interesse, come anticipato in figura 6.7: in questo caso il documento<br />
ottenuto con<strong>di</strong>vide <strong>un</strong>a parte della struttura con il documento <strong>di</strong> partenza.<br />
Questo modo <strong>di</strong> operare può risultare utile ad esempio quando si ha a che<br />
fare con documenti che fanno riferimento ad informazioni che non possono<br />
essere mo<strong>di</strong>ficate dall’utente. In questo caso può avere senso per l’utente<br />
effettuare il branch soltanto dei no<strong>di</strong> sotto la sua <strong>di</strong>retta responsabilità.<br />
In ogni modo, quello che è necessario evidenziare è che la consistenza<br />
150
Versioning in CISA Lo storico in CISA<br />
G<br />
F1 F2<br />
Doc. D1<br />
Branch<br />
Branch<br />
Branch<br />
Branch del<br />
documento<br />
G.1<br />
F1.1 F2.1<br />
D2 = branch <strong>di</strong> D1<br />
Figura 6.12: Branch <strong>di</strong> <strong>un</strong> intero documento.<br />
delle operazioni a livello <strong>di</strong> branch e <strong>di</strong> merge deve essere garantita dai livelli<br />
superiori a Structure, così come la struttura del documento, visto che le due<br />
entità sono strettamente correlate. Structure permette <strong>di</strong> operare creando<br />
branch o fondendoli (con merge) su singoli no<strong>di</strong> delegando ai livelli superiori<br />
l’onere <strong>di</strong> inserire all’interno <strong>di</strong> essi il contenuto corretto (sia per quanto<br />
riguarda i dati e i metadati delle informazioni atomiche, che per quanto<br />
riguarda gli aspetti legati alla struttura del documento e i metadati delle<br />
informazioni primitive).<br />
6.2.5 La navigazione nello storico<br />
Il layer Structure gestisce l’evoluzione temporale dei documenti e si attiva<br />
a seguito <strong>di</strong> richieste che nascono ai livelli superiori. La gestione interna<br />
dello storico è senz’altro necessaria, ma, affinché sia utile, occorre che questo<br />
fornisca anche dei meto<strong>di</strong> finalizzati alla navigazione all’interno dell’insieme<br />
<strong>di</strong> dati che co<strong>di</strong>ficano le varie versioni dei no<strong>di</strong>.<br />
Si ricorda che due versioni <strong>di</strong>verse della stessa informazione sono co<strong>di</strong>ficate<br />
all’interno <strong>di</strong> due no<strong>di</strong> <strong>di</strong>stinti <strong>di</strong> livello Structure i quali hanno <strong>un</strong> proprio<br />
in<strong>di</strong>rizzo <strong>un</strong>ivoco (PRI) che li identifica. Tali elementi possono essere messi<br />
in relazione tramite link <strong>di</strong> versione, ma focalizzando l’attenzione sull’entità<br />
151
Versioning in CISA Lo storico in CISA<br />
nodo, senza analizzare il suo contenuto, non è possibile <strong>di</strong>stinguere se questo<br />
contiene <strong>un</strong>a determinata versione <strong>di</strong> <strong>un</strong>a certa informazione oppure <strong>un</strong>’altra<br />
informazione. In questi termini quin<strong>di</strong> due versioni <strong>di</strong>fferenti sono considerate<br />
due informazioni <strong>di</strong>stinte come nel caso <strong>di</strong> <strong>un</strong>’informazione primitiva che<br />
aggrega, per composizione, <strong>un</strong>’altra informazione primitiva oppure <strong>di</strong> due<br />
informazioni che non hanno ness<strong>un</strong> legame fra loro.<br />
Alla luce <strong>di</strong> questa considerazione è possibile evidenziare come, senza<br />
aggi<strong>un</strong>gere ulteriori con<strong>di</strong>zioni, il livello Virtual Repository possa accedere<br />
ad ogni elemento dello storico <strong>di</strong> <strong>un</strong>a data informazione semplicemente<br />
conoscendone l’in<strong>di</strong>rizzo <strong>un</strong>ivoco PRI.<br />
Ovviamente <strong>un</strong> meccanismo <strong>di</strong> accesso <strong>di</strong> questo genere, che si basa su in<strong>di</strong>rizzamento<br />
assoluto, non può essere sufficiente per permettere <strong>un</strong>a gestione<br />
flessibile dello storico e, in questo caso, non sarebbe neanche corretto parlare<br />
<strong>di</strong> “navigazione”.<br />
La scelta effettuata consiste nell’aver previsto <strong>un</strong> meccanismo <strong>di</strong> navigazione<br />
relativo all’interno dello spazio delle versioni.<br />
L’accesso ai no<strong>di</strong> informativi avviene tramite l’in<strong>di</strong>rizzo persistente del<br />
nodo al quale può essere aggi<strong>un</strong>to <strong>un</strong> parametro <strong>di</strong> versione. Il parametro <strong>di</strong><br />
versione è facoltativo per permettere la navigazione anche in termini assoluti.<br />
L’utilizzo del parametro <strong>di</strong> versione in abbinamento ai PRI permette <strong>di</strong><br />
introdurre <strong>un</strong>a definizione formale degli in<strong>di</strong>rizzi relativi al livello Structure.<br />
Tali in<strong>di</strong>rizzi sono definiti con la sintassi esposta in in figura 6.13 con<br />
notazione BNF.<br />
::= "#"<br />
::= "R_NEXT" | "R_PREV" | "H_ROOT" |<br />
"B_ROOT" | "T_ABSLAST" | "T_RELATLAST"|<br />
"B_LAST" | "H_GRAPH"<br />
::= definizione nel paragrafo 8.3<br />
Figura 6.13: Sintassi degli in<strong>di</strong>rizzi <strong>di</strong> livello Structure.<br />
La navigazione avviene per passi e parte da <strong>un</strong>o degli elementi il cui<br />
in<strong>di</strong>rizzo persistente è noto ai livelli superiori. Prendendo come riferimento<br />
152
Versioning in CISA Lo storico in CISA<br />
il nodo in questione viene richiesto, secondo <strong>un</strong> in<strong>di</strong>rizzo relativo, <strong>un</strong> altro<br />
nodo presente nello storico della stessa informazione. L’esempio più semplice<br />
che può essere menzionato riguarda la navigazione fra <strong>un</strong>a revisione e la<br />
successiva o la precedente.<br />
Partendo, ad esempio, dall’elemento N0 è possibile procedere in avanti<br />
nelle revisioni operando nel modo seguente:<br />
N1 ← richie<strong>di</strong>(N0,rev_successiva)<br />
N2 ← richie<strong>di</strong>(N1,rev_successiva)<br />
N3 ← richie<strong>di</strong>(N2,rev_successiva)<br />
...<br />
richie<strong>di</strong>(A,B) è <strong>un</strong> metodo che permette a Virtual Repository <strong>di</strong> richiedere<br />
il nodo che partendo da A è raggi<strong>un</strong>gibile tramite il parametro <strong>di</strong> versione B.<br />
6.2.6 I parametri <strong>di</strong> versione<br />
In questo sotto paragrafo vengono descritti i parametri <strong>di</strong> versione che<br />
sono stati in<strong>di</strong>viduati e ritenuti utili nella fase <strong>di</strong> analisi.<br />
Nella definizione è stata usata la seguente convenzione: il nome del parametro<br />
è <strong>di</strong>viso, tramite il simbolo “ ”, in due parti: la prima è <strong>un</strong>a singola<br />
lettera e serve per identificare l’ambito in cui opera (i valori ammessi sono:<br />
R per revision, H per history, B per branch ed infine T per time), la seconda<br />
è <strong>un</strong>a stringa che definisce <strong>un</strong>a relazione all’interno del contesto in cui il<br />
parametro è definito.<br />
I parametri, riportati <strong>di</strong> seguito, sono accompagnati da <strong>un</strong>a breve descrizione:<br />
• R_NEXT: Revision, Next. Si riferisce alla revisione successiva del nodo<br />
corrente. Si osservi che, a seguito <strong>di</strong> <strong>un</strong>a richiesta con tale parametro<br />
<strong>di</strong> versione, possono presentarsi i seguenti casi:<br />
– non esiste la revisione successiva: la risposta è quin<strong>di</strong> negativa.<br />
Questo è il caso dell’ultimo elemento presente nel ramo;<br />
– esiste la revisione successiva: la risposta fornisce il nodo che la<br />
contiene;<br />
153
Versioning in CISA Lo storico in CISA<br />
– ortogonalmente il nodo può essere ra<strong>di</strong>ce <strong>di</strong> <strong>un</strong> branch, in questo<br />
caso la risposta contiene, se esiste, il nodo relativo alla revisione<br />
successiva e l’in<strong>di</strong>rizzo <strong>un</strong>ivoco (PRI) del primo elemento del<br />
branch. In questo modo viene sod<strong>di</strong>sfatta la richiesta relativa alla<br />
revisione successiva e i livelli superiori vengono messi a conoscenza<br />
dell’esistenza del branch con la possibilità <strong>di</strong> in<strong>di</strong>rizzarli.<br />
• R_PREV: Revision, Previous. Si riferisce alla revisione precedente del<br />
nodo corrente. In modo duale a R_NEXT possono presentarsi i seguenti<br />
casi:<br />
– non esiste la revisione precedente: la risposta è quin<strong>di</strong> negativa.<br />
Ciò si verifica solo per la ra<strong>di</strong>ce dello storico;<br />
– esiste la revisione precedente: la risposta fornisce il nodo che la<br />
contiene.<br />
– il nodo può essere stato creato come nuova revisione o in seguito<br />
ad <strong>un</strong>’operazione <strong>di</strong> merge. In quest’ultimo caso, similmente<br />
a quanto è stato definito per le <strong>di</strong>ramazioni, nella risposta sono<br />
presenti il nodo che contiene la revisione precedente (che si trova<br />
sullo stesso ramo del nodo <strong>di</strong> partenza) e l’in<strong>di</strong>rizzo <strong>un</strong>ivoco (PRI)<br />
dell’elemento precedente presente nell’altro branch.<br />
• H_ROOT: History, Root. Questo parametro <strong>di</strong> versione si riferisce alla<br />
ra<strong>di</strong>ce dello storico ovvero al primo elemento che è stato creato.<br />
• B_ROOT: Branch, Root. Si riferisce alla ra<strong>di</strong>ce del branch ovvero all’elemento<br />
che è stato preso come riferimento per creare il branch. Si<br />
osservi che per quanto riguarda i no<strong>di</strong> appartenenti al ramo principale<br />
B_ROOT coincide con H_ROOT.<br />
• T_ABSLAST: Time, Absolute Last. Elemento dello storico più recente<br />
(da <strong>un</strong> p<strong>un</strong>to <strong>di</strong> vista temporale).<br />
• T_RELATLAST: Time, Relative Last. Elemento più recente presente nello<br />
storico, relativamente al nodo <strong>di</strong> partenza ovvero per il quale tale nodo<br />
figura fra gli antenati. Equivale al T_ABSLAST dello storico ipotetico<br />
ottenuto considerando tutti i no<strong>di</strong> dello storico iniziale a partire dal<br />
nodo in esame (tale nodo rappresenta quin<strong>di</strong> la ra<strong>di</strong>ce dello storico<br />
ipotetico).<br />
154
Versioning in CISA Lo storico in CISA<br />
Storico completo dell'elemento<br />
1 2 3 13<br />
Il numero<br />
rappresenta<br />
l'istante t <strong>di</strong><br />
creazione<br />
della versione.<br />
Elemento <strong>di</strong><br />
riferimento<br />
4 6<br />
14 15 16<br />
5 7 8 10<br />
T_ABSLAST<br />
T_RELATLAST<br />
Storico<br />
ipotetico relativo<br />
9 11 12<br />
all'elemento creato al tempo t=7<br />
Figura 6.14: Esempio <strong>di</strong> elemento più recente relativamente al nodo <strong>di</strong><br />
partenza.<br />
In figura 6.14 è riportato <strong>un</strong> esempio: il nodo preso come riferimento<br />
è quello creato al tempo t=7. L’elemento T_ABSLAST relativo ad <strong>un</strong><br />
qual<strong>un</strong>que elemento dello storico, e quin<strong>di</strong> anche al nodo creato al tempo<br />
t=7, è il nodo creato al tempo t=16. La risoluzione dell’elemento<br />
T_RELATLAST, ovvero quello più recente relativamente al nodo creato a<br />
t=7, è il T_ABSLAST dello storico ipotetico <strong>di</strong> cui il nodo creato a t=7<br />
è la ra<strong>di</strong>ce e, nel caso specifico, è rappresentato dall’elemento creato al<br />
tempo t=12.<br />
A C<br />
B D<br />
Branch<br />
Ramo Principale<br />
E F<br />
B_LAST sul<br />
ramo principale<br />
B_LAST sul branch<br />
Figura 6.15: Esempi <strong>di</strong> “last” relativi al branch.<br />
155
Versioning in CISA Lo storico in CISA<br />
• B_LAST: Branch, Last. Ultima revisione del branch. In riferimento al<br />
caso riportato in figura 6.15 il B_LAST relativo ai no<strong>di</strong> A, C, E ed F è F,<br />
mentre quello relativo ai no<strong>di</strong> B e D è D.<br />
• H_GRAPH: La struttura dello storico. Quest’ultimo parametro <strong>di</strong> versione<br />
si <strong>di</strong>fferenzia dagli altri in quanto non è utilizzato per ottenere <strong>un</strong>a<br />
particolare versione <strong>di</strong> N all’interno dello storico, ma per permettere a<br />
Virtual Repository e/o Application <strong>di</strong> avere <strong>un</strong>a visione globale dello<br />
storico stesso. La struttura viene fornita, opport<strong>un</strong>amente co<strong>di</strong>ficata<br />
all’interno <strong>di</strong> <strong>un</strong> documento D3IM, sotto forma <strong>di</strong> DAG nel quale ogni<br />
elemento contiene l’in<strong>di</strong>rizzo <strong>un</strong>ivoco (PRI) del corrispondente nodo<br />
nello storico ed eventualmente altri metadati <strong>di</strong> interesse. La struttura<br />
può essere completa o parziale (ad esempio localizzata nell’intorno<br />
del nodo <strong>di</strong> riferimento) e questo aspetto viene gestito tramite <strong>un</strong> opport<strong>un</strong>o<br />
attributo specificato nella richiesta. Si osservi che lo stesso<br />
risultato che si ottiene tramite questo parametro <strong>di</strong> versione può essere<br />
raggi<strong>un</strong>to, a livello Virtual Repository, visitando tutto il grafo relativo<br />
allo storico dell’informazione <strong>di</strong> interesse tramite l’utilizzo degli altri<br />
parametri <strong>di</strong> versione che Structure mette a <strong>di</strong>sposizione. H_GRAPH non<br />
è da considerarsi quin<strong>di</strong> utile nell’ottica dell’efficacia del sistema, ma<br />
in quella dell’efficienza. I benefici <strong>di</strong> questa soluzione sono evidenti facendo<br />
in modo che Structure co<strong>di</strong>fichi (e mantenga aggiornato) il grafo<br />
associato allo storico su <strong>un</strong>’opport<strong>un</strong>a struttura dati e che quin<strong>di</strong> riesca<br />
a sod<strong>di</strong>sfare la richiesta senza effettuare la visita (al posto <strong>di</strong> Virtual<br />
Repository) <strong>di</strong> tutto lo storico. Considerando che i no<strong>di</strong> dello storico<br />
sono, per definizione, non eliminabili, la struttura può solo crescere nel<br />
tempo. Questo vincolo permette tuttavia <strong>di</strong> ideare soluzioni per la sua<br />
memorizzazione e gestione che scalino, senza <strong>di</strong>fficoltà, all’aumentare<br />
della <strong>di</strong>mensione ricorrendo ad opport<strong>un</strong>e tecniche <strong>di</strong> partizionamento.<br />
La definizione e l’introduzione effettiva <strong>di</strong> questa primitiva vengono<br />
lasciate a sviluppi futuri.<br />
156
Capitolo<br />
7<br />
Il servizio fornito dal layer Structure<br />
Nel capitolo 6 è stato affrontato il problema del versioning dell’informazione<br />
nel contesto dell’architettura CISA. Il problema è stato inquadrato,<br />
ricondotto al <strong>modello</strong> dell’informazione D3IM (descritto nei capitoli 3 e 4)<br />
ed affrontato da <strong>un</strong> p<strong>un</strong>to <strong>di</strong> vista teorico.<br />
In questo capitolo verranno trattate le varie problematiche da <strong>un</strong> p<strong>un</strong>to<br />
<strong>di</strong> vista più tecnico con la finalità <strong>di</strong> completare la progettazione, eseguita<br />
per passi successivi, dell’intero sistema e, nello specifico, del layer Structure.<br />
I compiti del layer Structure sono svolti da <strong>un</strong> <strong>un</strong>ico tipo <strong>di</strong> servizio che<br />
può essere erogato, in autonomia, da <strong>un</strong>o o più processi <strong>di</strong> livello applicativo<br />
ISO/OSI. A tal riguardo si ricorda che alc<strong>un</strong>i servizi, come quelli legati alla<br />
risoluzione dei nomi, non possono essere forniti <strong>un</strong>icamente da <strong>un</strong> solo processo,<br />
ma i vari processi devono essere in grado <strong>di</strong> cooperare. Anche se, per<br />
questa tipologia <strong>di</strong> servizio, è possibile che alc<strong>un</strong>e richieste vengano espletate<br />
esclusivamente dal processo al quale vengono rivolte questo è, a tutti gli<br />
effetti, <strong>un</strong> caso particolare.<br />
Nel contesto del layer Structure parlare <strong>di</strong> layer, <strong>di</strong> servizio o <strong>di</strong> processo<br />
è quin<strong>di</strong> del tutto equivalente (a patto <strong>di</strong> assegnare ad ogni termine il giusto<br />
significato concettuale) in quanto non vi è rischio <strong>di</strong> ambiguità.<br />
Nella prima parte del presente capitolo verranno prese in esame l’interfac-
Il servizio fornito dal layer Structure Interfacce<br />
cia che Structure fornisce a Virtual Repository e quella utilizzata da Structure<br />
per l’interazione con Replica Management.<br />
Nella seconda parte verranno introdotte, tramite il formalismo degli XML<br />
Schema, le strutture dati interne al livello.<br />
Infine, nella terza parte, verranno progettati gli algoritmi utilizzati all’interno<br />
del layer Structure con il fine <strong>di</strong> arrivare a definire esaustivamente<br />
l’implementazione del sistema, anche in sviluppi futuri.<br />
7.1 Interfacce<br />
La finalità del layer Structure è quella <strong>di</strong> fornire al layer Virtual Repository<br />
il servizio <strong>di</strong> mantenimento e memorizzazione dell’evoluzione temporale<br />
dell’informazione attraverso la definizione e gestione del relativo storico e<br />
della navigazione all’interno <strong>di</strong> esso.<br />
Per Virtual Repository il layer Structure è quin<strong>di</strong> <strong>un</strong>’entità remota alla<br />
quale effettuare richieste <strong>di</strong> servizio. Come evidenziato nel capitolo 5, per<br />
raggi<strong>un</strong>gere questo risultato occorre definire <strong>un</strong> protocollo <strong>di</strong> com<strong>un</strong>icazione<br />
che permetta alle due entità <strong>di</strong> interagire.<br />
L’interazione è basata sul para<strong>di</strong>gma client/server: il client è rappresentato<br />
da Virtual Repository che agisce da fruitore del servizio fornito da<br />
Structure, il server. In questi termini Virtual Repository agisce da attore 1 nei<br />
confronti <strong>di</strong> Structure il quale mette a <strong>di</strong>sposizione <strong>un</strong>’interfaccia attraverso<br />
la quale interagire. Tale interfaccia è mappabile sulle primitive del protocollo<br />
che vengono invocate da Virtual Repository per le richieste <strong>di</strong> servizio e<br />
la cui definizione implementativa è lasciata a sviluppi futuri. Il protocollo,<br />
definendo il formato e l’or<strong>di</strong>ne dei messaggi scambiati tra le due entità e le<br />
azioni che hanno luogo a seguito della trasmissione e/o ricezione <strong>di</strong> <strong>un</strong> messaggio<br />
(o <strong>di</strong> altri eventi), definisce l’API <strong>di</strong> com<strong>un</strong>icazione fra le logiche <strong>di</strong><br />
controllo <strong>di</strong> Virtual Repository e Structure, nell’accezione del contesto dell’interfaccia<br />
bi<strong>di</strong>mensionale descritta nel capitolo 9 nel sotto paragrafo 9.1.1.<br />
L’API così definita rappresenta, secondo l’approccio tipico delle telecom<strong>un</strong>icazioni,<br />
il Service Access Point (SAP) utilizzato da Virtual Repository per<br />
la com<strong>un</strong>icazione con Structure.<br />
Nel sotto paragrafo seguente verrà quin<strong>di</strong> introdotta l’interfaccia secondo<br />
1 Con attore si intende <strong>un</strong>’entità esterna rispetto al sistema in esame che scambia con<br />
esso messaggi in ingresso e/o in uscita. Il contesto è relativo ai <strong>di</strong>agrammi UML [RJB99].<br />
158
Il servizio fornito dal layer Structure Interfacce<br />
il formalismo dei <strong>di</strong>agrammi dei casi d’uso <strong>di</strong> UML. La finalità è quella <strong>di</strong><br />
presentare i vari tipi <strong>di</strong> richieste che possono essere effettuate ad alto livello<br />
a Structure dando, allo stesso tempo, <strong>un</strong>a breve descrizione delle azioni che<br />
vengono svolte dal layer.<br />
Successivamente viene introdotta, con la stessa modalità, l’interfaccia vista<br />
da Structure messa a <strong>di</strong>sposizione da Replica Management. Questo è utile<br />
per evidenziare come Structure si avvalga del livello Replica Management per<br />
sod<strong>di</strong>sfare le richieste effettuate da Virtual Repository.<br />
Per convenzione è stato scelto <strong>di</strong> assegnare i nomi ai casi d’uso nel modo<br />
seguente: identificativo sistema.identificativo contesto.numero. L’identificativo<br />
del sistema permette <strong>di</strong> associare il caso d’uso ad <strong>un</strong> sistema specifico,<br />
in questo caso “Str” corrisponde a Structure e “Rep” a Replica Management.<br />
L’identificativo del contesto specifica a quale entità del sistema il caso d’uso<br />
si riferisce, ad esempio “Int” è l’interfaccia. Infine il numero sequenziale<br />
permette <strong>di</strong> creare <strong>un</strong> nome <strong>un</strong>ivoco per ogni caso d’uso come richiesto per<br />
rispettare le specifiche dettate da UML.<br />
Alla fine del presente capitolo, nel paragrafo 7.3, verranno riportate alc<strong>un</strong>e<br />
considerazioni necessarie per comprendere a fondo la semantica delle<br />
primitive.<br />
7.1.1 Interfaccia mostrata a Virtual Repository<br />
Nella descrizione che segue con sistema si intende il layer Structure,<br />
principale soggetto dell’interazione.<br />
In figura 7.1 è riportato il <strong>di</strong>agramma dei casi d’uso che permette <strong>di</strong> riassumere<br />
graficamente le primitive che Structure espone a Virtual Repository.<br />
Caso d’uso: Str.Int.GET<br />
ID: UC.Str.Int.1<br />
Attori: Virtual Repository.<br />
Precon<strong>di</strong>zioni:<br />
159
Il servizio fornito dal layer Structure Interfacce<br />
Figura 7.1: Casi d’uso relativi all’interfaccia mostrata da Structure a Virtual<br />
Repository.<br />
1. Deve essere noto il PRI del nodo N.<br />
Sequenza degli eventi:<br />
1. Il caso d’uso inizia quando il Virtual Repository ha la necessità <strong>di</strong> accedere<br />
ad <strong>un</strong> elemento presente nello storico <strong>di</strong> N ed effettua la richiesta<br />
<strong>di</strong> accesso specificando il PRI <strong>di</strong> N e il parametro <strong>di</strong> versione.<br />
Il parametro <strong>di</strong> versione può essere (si ricorda che la definizione dei<br />
parametri <strong>di</strong> versione è presente nel sotto paragrafo 6.2.6 a pagina 153):<br />
• ness<strong>un</strong>o: per richiedere la versione corrente (esattamente il nodo<br />
N);<br />
• R_NEXT: per richiedere la versione successiva;<br />
• R_PREV: per richiedere la versione precedente;<br />
• H_ROOT: per richiedere la prima versione del nodo;<br />
• B_ROOT: per richiedere la ra<strong>di</strong>ce del branch (nel caso in cui il nodo<br />
appartenga al ramo principale B_ROOT coincide con H_ROOT);<br />
160
Il servizio fornito dal layer Structure Interfacce<br />
• T_ABSLAST: per richiedere l’ultima versione creata (più recente da <strong>un</strong><br />
p<strong>un</strong>to <strong>di</strong> vista temporale) presente all’interno dello storico completo;<br />
• T_RELATLAST: per richiedere l’ultima versione creata (più recente<br />
da <strong>un</strong> p<strong>un</strong>to <strong>di</strong> vista temporale) che ha il nodo <strong>di</strong> partenza fra gli<br />
antenati nello storico;<br />
• B_LAST: per richiedere l’ultima versione presente nel branch corrente;<br />
• H_GRAPH: per richiedere il DAG che rappresenta lo storico del nodo<br />
N.<br />
2. Il sistema, partendo da N, richiede a Replica Management (si faccia<br />
riferimento al caso d’uso UC.Rep.Int.1) tutti i no<strong>di</strong> necessari al raggi<strong>un</strong>gimento<br />
<strong>di</strong> Nx (nodo richiesto tramite il parametro <strong>di</strong> versione).<br />
3. Il sistema restituisce il nodo Nx a Virtual Repository oppure <strong>un</strong> messaggio<br />
<strong>di</strong> errore.<br />
Scenari secondari:<br />
1. Se viene richiesta la versione R_NEXT <strong>di</strong> <strong>un</strong> nodo nel quale hanno origine<br />
<strong>un</strong>o o più branch, il sistema risponde fornendo la nuova revisione (se<br />
esiste) e la lista <strong>di</strong> in<strong>di</strong>rizzi del primo elemento <strong>di</strong> ogni branch. Questo<br />
permette al Virtual Repository <strong>di</strong> creare <strong>un</strong>a nuova richiesta sul branch<br />
<strong>di</strong> interesse.<br />
2. Se viene richiesta la versione R_PREV <strong>di</strong> <strong>un</strong> nodo ottenuto tramite <strong>un</strong>’operazione<br />
<strong>di</strong> merge il sistema risponde fornendo la revisione precedente<br />
e l’in<strong>di</strong>rizzo del genitore presente nell’altro branch.<br />
Caso d’uso: Str.Int.COMMIT<br />
ID: UC.Str.Int.2<br />
Attori: Virtual Repository.<br />
Precon<strong>di</strong>zioni:<br />
161
Il servizio fornito dal layer Structure Interfacce<br />
1. I no<strong>di</strong> interessati devono esistere 2 ed essere stati precedentemente marcati<br />
come RELAXED, LOCKED STRONG o LOCKED SOFT dal richiedente<br />
del COMMIT, caso d’uso UC.Str.Int.5.<br />
Sequenza degli eventi:<br />
1. Il caso d’uso inizia quando il Virtual Repository ha la necessità <strong>di</strong> salvare<br />
<strong>un</strong> documento o parte <strong>di</strong> esso ed effettua la richiesta <strong>di</strong> commit<br />
specificando quali no<strong>di</strong> sono stati mo<strong>di</strong>ficati.<br />
2. Il sistema sovrascrive (riferimento ad UC.Rep.Int.2/3/4.) o crea nuove<br />
versioni <strong>di</strong> tali no<strong>di</strong> (riferimento ad UC.Rep.Int.5) in base alla politica<br />
<strong>di</strong> gestione esistente (legata allo stato UPDATE).<br />
3. Vengono eseguiti gli algoritmi <strong>di</strong> propagazione delle versioni.<br />
4. Il sistema restituisce <strong>un</strong> messaggio al Virtual Repository che può essere<br />
positivo o <strong>di</strong> errore.<br />
Caso d’uso: Str.Int.CREATE<br />
ID: UC.Str.Int.3<br />
Attori: Virtual Repository.<br />
Sequenza degli eventi:<br />
1. Il caso d’uso inizia quando Virtual Repository ha la necessità <strong>di</strong> creare<br />
<strong>un</strong> nuovo documento o <strong>di</strong> aggi<strong>un</strong>gere nuovi elementi ad <strong>un</strong> documento<br />
esistente; in entrambi i casi effettua <strong>un</strong>a richiesta <strong>di</strong> creazione <strong>di</strong> nuovi<br />
no<strong>di</strong>.<br />
2. Il sistema effettua <strong>un</strong>a richiesta <strong>di</strong> creazione a Replica Management per<br />
ogni nodo da creare (riferimento ad UC.Rep.Int.5).<br />
3. Il sistema restituisce <strong>un</strong> messaggio al Virtual Repository che può essere<br />
positivo (in tal caso contiene il PRI del nuovo nodo) o <strong>di</strong> errore.<br />
2 Per inserire nuovi elementi occorre fare riferimento al caso d’uso UC.Str.Int.3<br />
162
Il servizio fornito dal layer Structure Interfacce<br />
Caso d’uso: Str.Int.BRANCH<br />
ID: UC.Str.Int.4<br />
Attori: Virtual Repository.<br />
Precon<strong>di</strong>zioni:<br />
1. I no<strong>di</strong> <strong>di</strong> partenza devono esistere.<br />
Sequenza degli eventi:<br />
1. Il caso d’uso inizia quando Virtual Repository ha la necessità <strong>di</strong> creare<br />
<strong>un</strong> branch nello storico <strong>di</strong> <strong>un</strong>o o più no<strong>di</strong>.<br />
2. Il sistema crea <strong>un</strong> nuovo nodo (riferimento ad UC.Str.Int.3) e copia in<br />
esso il contenuto della versione in<strong>di</strong>cata del nodo <strong>di</strong> partenza oppure,<br />
se specificato da Virtual Repository, <strong>di</strong>rettamente il nuovo valore che il<br />
nodo deve assumere;<br />
3. Il sistema inserisce nell’elemento <strong>di</strong> partenza le informazioni necessarie<br />
per accedere al nuovo branch nella fase <strong>di</strong> navigazione dello storico;<br />
4. Il sistema restituisce <strong>un</strong> messaggio a Virtual Repository che può essere<br />
positivo (in tal caso contiene il PRI del nuovo nodo, ra<strong>di</strong>ce del branch)<br />
o <strong>di</strong> errore.<br />
Caso d’uso: Str.Int.MARK<br />
ID: UC.Str.Int.5<br />
Attori: Virtual Repository.<br />
Precon<strong>di</strong>zioni:<br />
163
Il servizio fornito dal layer Structure Interfacce<br />
1. I no<strong>di</strong> <strong>di</strong> interesse devono esistere.<br />
2. Il nodo non deve avere nuove versioni ovvero deve essere l’elemento più<br />
recente del branch affinché le etichette RELAXED, LOCKED STRONG<br />
o LOCKED SOFT possano essere applicate.<br />
Sequenza degli eventi:<br />
1. Il caso d’uso inizia quando Virtual Repository ha la necessità <strong>di</strong> marcare 3<br />
<strong>un</strong>a lista <strong>di</strong> no<strong>di</strong> e per farlo utilizza i seguenti parametri (i primi due<br />
possono essere applicati contemporaneamente):<br />
• OBSERVED, per mettere i no<strong>di</strong> sotto osservazione;<br />
• RELAXED, per in<strong>di</strong>care che l’utente è interessato alla mo<strong>di</strong>fica dei no<strong>di</strong><br />
(con il fine <strong>di</strong> applicare <strong>un</strong>a strategia <strong>di</strong> aggiornamento ottimistica<br />
massimizzando l’awareness <strong>di</strong> alto livello);<br />
• LOCKED_STRONG, per acquisire il lock Strong (sia in lettura che in<br />
scrittura, ve<strong>di</strong> il sotto paragrafo 4.4.2) sui no<strong>di</strong>;<br />
• LOCKED_SOFT, per acquisire il lock Soft (solo in scrittura, ve<strong>di</strong> il sotto<br />
paragrafo 4.4.2) sui no<strong>di</strong>;<br />
• NULL, per in<strong>di</strong>care che si intendono rimuovere tutte le etichette.<br />
2. Il sistema accede ai vari no<strong>di</strong> ed assegna gli identificativi in modo atomico<br />
(ulteriori dettagli saranno riportati nel paragrafo 7.3).<br />
3. Nel caso in cui tale operazione risulti possibile restituisce <strong>un</strong> messaggio<br />
positivo, altrimenti <strong>di</strong> errore.<br />
Caso d’uso: Str.Int.MERGE<br />
ID: UC.Str.Int.6<br />
Attori: Virtual Repository.<br />
Precon<strong>di</strong>zioni:<br />
3 Ulteriori dettagli sulle etichette, e in generale sul meccanismo <strong>di</strong> marcatura, verranno<br />
riportati nel sotto paragrafo 7.3.3.<br />
164
Il servizio fornito dal layer Structure Interfacce<br />
1. Devono esistere due no<strong>di</strong> Nb1 e Nb2 che rappresentato l’ultima revisione<br />
presente nei branch <strong>di</strong>stinti b1 e b2 appartenenti allo stesso storico.<br />
Sequenza degli eventi:<br />
1. Il caso d’uso inizia quando Virtual Repository ha la necessità <strong>di</strong> fondere<br />
i due branch b1 e b2 su <strong>un</strong> <strong>un</strong>ico ramo e specifica i PRI <strong>di</strong> Nb1 e Nb2 e il<br />
nodo (nuovo) Nsucc creato dall’<strong>un</strong>ione <strong>di</strong> Nb1 e Nb2.<br />
2. Il sistema crea <strong>un</strong> nuovo nodo, inserisce in esso Nsucc, lo rende successore<br />
<strong>di</strong> Nb1 ed Nb2 ed appartenente al ramo <strong>di</strong> Nb1.<br />
3. Il sistema restituisce <strong>un</strong> messaggio a Virtual Repository che può essere<br />
positivo o <strong>di</strong> errore.<br />
7.1.2 Interfaccia fornita da Replica Management<br />
In questo caso l’attore principale (il client) è Structure che richiede l’espletamento<br />
<strong>di</strong> alc<strong>un</strong>i servizi a Replica Management (il server).<br />
Nella descrizione che segue con sistema si intende quin<strong>di</strong> il Livello Replica<br />
Management, principale soggetto dell’interazione.<br />
In figura 7.1 è riportato il <strong>di</strong>agramma dei casi d’uso che permette <strong>di</strong><br />
riassumere graficamente le primitive che Replica Management fornisce a<br />
Structure.<br />
Caso d’uso: Rep.Int.GET<br />
ID: UC.Rep.Int.1<br />
Attori: Structure.<br />
Precon<strong>di</strong>zioni:<br />
1. Deve essere noto il PRI del nodo N.<br />
Sequenza degli eventi:<br />
165
Il servizio fornito dal layer Structure Interfacce<br />
Figura 7.2: Casi d’uso relativi all’interfaccia mostrata a Structure da<br />
Repository Management.<br />
1. Il caso d’uso inizia quando Structure ha la necessità <strong>di</strong> accedere all’elemento<br />
N ed effettua la richiesta <strong>di</strong> accesso specificandone il PRI.<br />
2. Il sistema recupera <strong>un</strong>a qual<strong>un</strong>que replica valida <strong>di</strong> N.<br />
3. Il sistema restituisce il nodo N a Structure oppure <strong>un</strong> messaggio <strong>di</strong> errore<br />
(se il nodo non esiste).<br />
Caso d’uso: Rep.Int.LOCK<br />
ID: UC.Rep.Int.2<br />
Attori: Structure.<br />
Precon<strong>di</strong>zioni:<br />
1. Deve essere noto il PRI del nodo N.<br />
Sequenza degli eventi:<br />
166
Il servizio fornito dal layer Structure Interfacce<br />
1. Il caso d’uso inizia quando Structure ha la necessità <strong>di</strong> accedere in modo<br />
esclusivo all’elemento N (per la lettura o per la scrittura) ed effettua la<br />
richiesta <strong>di</strong> blocco specificandone il PRI.<br />
2. Il sistema accede alla replica master sulla quale applica il lock.<br />
3. Il sistema restituisce <strong>un</strong> messaggio a Structure che può essere positivo se<br />
riesce ad applicare il lock o <strong>di</strong> errore in caso contrario (se il nodo è già<br />
bloccato oppure non esiste).<br />
Caso d’uso: Rep.Int.PUT<br />
ID: UC.Rep.Int.3<br />
Attori: Structure.<br />
Precon<strong>di</strong>zioni:<br />
1. Deve essere noto il PRI del nodo N.<br />
2. Il nodo N deve essere stato precedentemente bloccato (riferimento ad<br />
UC.Rep.Int.2) dal processo <strong>di</strong> layer Structure che intende effettuare la<br />
richiesta <strong>di</strong> aggiornamento.<br />
Sequenza degli eventi:<br />
1. Il caso d’uso inizia quando Structure ha la necessità <strong>di</strong> aggiornare l’elemento<br />
N ed effettua la richiesta PUT specificando integralmente il nuovo<br />
valore del nodo.<br />
2. Il sistema accede alla replica master sulla quale applica l’aggiornamento.<br />
3. Il sistema restituisce <strong>un</strong> messaggio a Structure che può essere positivo<br />
se l’aggiornamento riesce o <strong>di</strong> errore in caso contrario (se il nodo non è<br />
stato bloccato oppure non esiste).<br />
4. Il sistema provvede ad aggiornare le varie repliche.<br />
167
Il servizio fornito dal layer Structure Interfacce<br />
Caso d’uso: Rep.Int.UNLOCK<br />
ID: UC.Rep.Int.4<br />
Attori: Structure.<br />
Precon<strong>di</strong>zioni:<br />
1. Deve essere noto il PRI del nodo N.<br />
2. Il nodo N deve essere stato precedentemente bloccato dal processo <strong>di</strong><br />
layer Structure che intende effettuare la richiesta <strong>di</strong> rilascio del blocco.<br />
Sequenza degli eventi:<br />
1. Il caso d’uso inizia quando Structure intende rimuovere il lock da <strong>un</strong><br />
nodo bloccato ed effettua la richiesta <strong>di</strong> UNLOCK specificando il PRI<br />
del nodo N.<br />
2. Il sistema accede alla replica master sulla quale applica l’aggiornamento<br />
<strong>di</strong> stato.<br />
3. Il sistema restituisce <strong>un</strong> messaggio a Structure che può essere positivo<br />
se l’aggiornamento riesce o <strong>di</strong> errore in caso contrario (se il nodo non è<br />
stato bloccato oppure non esiste).<br />
Caso d’uso: Rep.Int.CREATE<br />
ID: UC.Rep.Int.5<br />
Attori: Structure.<br />
Sequenza degli eventi:<br />
168
Il servizio fornito dal layer Structure La struttura dati interna a Structure<br />
1. Il caso d’uso inizia quando Structure intende creare <strong>un</strong> nuovo nodo ed<br />
effettua <strong>un</strong>a richiesta CREATE.<br />
2. Il sistema crea la replica master del nuovo elemento. La primitiva prevede<br />
la possibilità <strong>di</strong> creare il nodo ed acquisirne il lock <strong>di</strong>rettamente oppure<br />
<strong>di</strong> crearlo soltanto.<br />
3. Il sistema restituisce <strong>un</strong> messaggio a Structure che può essere positivo<br />
(in tal caso contiene il PRI del nuovo nodo) o <strong>di</strong> errore.<br />
7.2 La struttura dati interna a Structure<br />
In questo paragrafo viene introdotta la struttura dati necessaria per definire,<br />
gestire e mantenere lo storico <strong>di</strong> <strong>un</strong>’informazione che, in questo caso, è<br />
da considerarsi come nodo del layer Structure.<br />
La struttura viene definita tramite <strong>un</strong> XML Schema, standard preso come<br />
riferimento in CISA per la modellazione dei dati, del formato dei messaggi<br />
dei protocolli, eccetera 4 .<br />
Nel sotto paragrafo successivo i vari elementi dello Schema verranno commentati,<br />
operazione necessaria per comprendere a fondo sia la loro f<strong>un</strong>zione<br />
che gli algoritmi descritti successivamente, nel paragrafo 7.3.<br />
7.2.1 XML Schema<br />
In questo paragrafo viene riportato lo XML Schema che permette <strong>di</strong> descrivere<br />
i no<strong>di</strong> D3IM a livello Structure sia in formato testuale che in formato<br />
grafico nelle figure 7.3 e 7.4. Tali figure evidenziano la struttura, i dati e i<br />
metadati presenti in <strong>un</strong> nodo senza entrare nel dettaglio della sintassi degli<br />
XML Schema. In particolare la prima rappresenta <strong>un</strong>a visione generale della<br />
struttura tralasciando i link <strong>di</strong> versione (ovvero i link che permettono <strong>di</strong> generare<br />
le relazioni fra no<strong>di</strong> all’interno dello storico), la seconda rappresenta<br />
proprio tali link.<br />
Lo Schema non è stato commentato in quanto, in caso contrario, sarebbe<br />
risultato eccessivamente <strong>di</strong>spersivo. Un’accurata descrizione <strong>di</strong> esso è com<strong>un</strong>que<br />
presente nel sotto paragrafo successivo; gli elementi vengono descritti<br />
nello stesso or<strong>di</strong>ne con il quale compaiono nello Schema.<br />
4 La scelta <strong>di</strong> XML per la modellazione dei dati è stata dettata dalla flessibilità,<br />
compatibilità e portabilità che questo standard offre [Fra05].<br />
169
Il servizio fornito dal layer Structure La struttura dati interna a Structure<br />
Lo Schema è il seguente:<br />
<br />
<br />
<br />
<br />
<br />
XML Schema - Definizione no<strong>di</strong> D3IM a livello Structure <strong>di</strong> CISA<br />
Author: Davide Chini<br />
Date: 09/03/2006<br />
Revision: 0.1<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
170
Il servizio fornito dal layer Structure La struttura dati interna a Structure<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
171
Il servizio fornito dal layer Structure La struttura dati interna a Structure<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
172
Il servizio fornito dal layer Structure La struttura dati interna a Structure<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
7.2.2 Descrizione dello XML Schema<br />
La prima entità () serve per<br />
includere <strong>un</strong> altro Schema, per la precisione pri.xsd, che contiene la definizione<br />
degli in<strong>di</strong>rizzi <strong>un</strong>ivoci e persistenti (PRI) definiti in D3IM (evidenziata<br />
in figura 7.5).<br />
Si osservi che nel paragrafo 8.3 sarà riportata <strong>un</strong> descrizione dettagliata<br />
degli in<strong>di</strong>rizzi PRI e <strong>un</strong>a loro definizione formale sia tramite espressione regolare<br />
(presente all’interno del tag xs:pattern in figura 7.5) che notazione<br />
BNF.<br />
Le entità successive definiscono sign e updateStateEnum.<br />
Il primo <strong>di</strong> essi contiene “la firma” che Structure applica al nodo in fase<br />
<strong>di</strong> creazione e/o <strong>di</strong> mo<strong>di</strong>fica e contiene tutti i parametri ritenuti utili per<br />
173
Il servizio fornito dal layer Structure La struttura dati interna a Structure<br />
node<br />
header<br />
body<br />
anyType<br />
0..*<br />
nodeId<br />
concurrency<br />
structure<br />
history<br />
anyElement<br />
0..*<br />
0..*<br />
observed<br />
relaxed<br />
child<br />
parent<br />
historyId<br />
versionId<br />
created<br />
mo<strong>di</strong>fied<br />
update<br />
versionLinks<br />
lockStrong<br />
Figura 7.3: Albero del XML Schema: visione globale.<br />
0..*<br />
0..*<br />
lockSoft<br />
+<br />
+<br />
+<br />
174
Il servizio fornito dal layer Structure La struttura dati interna a Structure<br />
history<br />
histotyId<br />
versionId<br />
created<br />
mo<strong>di</strong>fied<br />
update<br />
versionLinks<br />
+<br />
+<br />
0..1<br />
0..*<br />
0..2<br />
0..1<br />
0..1<br />
revisionNext<br />
branch<br />
revisionPrevious<br />
branchRoot<br />
historyRoot<br />
timeLast<br />
firstRevision<br />
branchLast<br />
Figura 7.4: Albero del XML Schema: particolare dei link <strong>di</strong> versione.<br />
<br />
<br />
<br />
value="urn:pri:(0\.|([1-9][0-9]*)\.)*(0|([1-9][0-9]*))<br />
/[0-9a-zA-Z\-_.,();:=+$!~*’]+"<br />
<br />
<br />
<br />
Figura 7.5: XML Schema che rappresenta gli in<strong>di</strong>rizzi PRI.<br />
l’identificazione dell’operazione. Si osservi che la definizione <strong>di</strong> tale elemento<br />
può essere estesa e/o mo<strong>di</strong>ficata. L’elemento structProcessId rappresen-<br />
175
Il servizio fornito dal layer Structure La struttura dati interna a Structure<br />
ta l’identificativo <strong>un</strong>ivoco del processo <strong>di</strong> livello Structure che ha effettuato<br />
l’operazione (<strong>di</strong> creazione e/o mo<strong>di</strong>fica); occorre definire <strong>un</strong> meccanismo che<br />
permetta <strong>di</strong> assegnare dei nomi <strong>un</strong>ivoci ai processi CISA (è opport<strong>un</strong>o che tale<br />
meccanismo sia <strong>un</strong>ificato all’interno <strong>di</strong> tutta l’architettura). Una possibile<br />
soluzione è quella <strong>di</strong> proiettare i singoli processi all’interno dello dei spazio<br />
dei nomi D3IM; è possibile ottenere questo risultato assegnando ad essi alc<strong>un</strong>i<br />
nomi logici, <strong>un</strong> nome <strong>un</strong>ivoco (il cui valore sarebbe quello da inserire<br />
nell’elemento structProcessId in esame) e <strong>un</strong> URL (che permette l’in<strong>di</strong>viduazione<br />
e quin<strong>di</strong> l’accesso del processo in rete) esattamente come avviene<br />
per le informazioni primitive.<br />
Il secondo, updateStateEnum, rappresenta l’enumerazione dei possibili<br />
stati ass<strong>un</strong>ti da UPDATE: FROZEN e CHANGING.<br />
L’elemento successivo, node, definisce formalmente il nodo nel contesto<br />
del layer Structure. Tale elemento, come evidenziato in figura 7.3, è sud<strong>di</strong>viso<br />
in due sezioni: header e body. Questa <strong>di</strong>stinzione è stata introdotta nel<br />
paragrafo 6.2.1 ed è conseguenza dell’imbustamento, operazione che viene<br />
effettuata in quanto CISA è <strong>un</strong>’architettura stratificata.<br />
All’interno dell’elemento body viene infatti inserita la co<strong>di</strong>fica del nodo<br />
definita a livello Virtual Repository senza che Structure (information hi<strong>di</strong>ng)<br />
sia interessato ad interpretarne il contenuto.<br />
L’elemento header contiene invece tutti i dati e metadati <strong>di</strong> competenza<br />
del layer Structure e quin<strong>di</strong> definiti in questo contesto. Sono presenti quattro<br />
gruppi <strong>di</strong> elementi:<br />
• nodeId: non è <strong>un</strong> vero e proprio gruppo, in quanto è <strong>un</strong> <strong>un</strong>ico elemento<br />
e rappresenta l’in<strong>di</strong>rizzo <strong>un</strong>ivoco del nodo (PRI);<br />
• concurrency: gruppo che contiene le informazioni necessarie per la<br />
gestione della concorrenza negli accessi;<br />
• structure: gruppo che contiene tutti gli elementi necessari alla rappresentazione<br />
degli aspetti strutturali dei documenti D3IM;<br />
• history: gruppo che contiene tutti gli elementi necessari alla gestione<br />
e al mantenimento dello storico.<br />
Per quanto riguarda nodeId non occorre specificare altro.<br />
Il gruppo concurrency contiene le etichette, introdotte con il caso d’uso<br />
UC.Str.Int.5, per la gestione della concorrenza. In particolare ad ogni nodo<br />
176
Il servizio fornito dal layer Structure La struttura dati interna a Structure<br />
può essere applicato <strong>un</strong> numero arbitrario <strong>di</strong> etichette observed e relaxed<br />
ed <strong>un</strong>a etichetta a scelta tra lockStrong e lockSoft. Ogni etichetta è <strong>un</strong><br />
elemento <strong>di</strong> tipo pri e tale in<strong>di</strong>rizzo serve ad identificare l’entità (Avatar<br />
dell’utente) che l’ha creata.<br />
Il gruppo structure contiene due tipi <strong>di</strong> elementi: i figli del nodo (child),<br />
che rappresentano le relazioni <strong>di</strong> aggregazione per composizione, e i genitori<br />
(parent), che rappresentano le relazioni inverse. Il sistema deve quin<strong>di</strong> garantire<br />
la consistenza della struttura: per ogni relazione child presente da<br />
<strong>un</strong> generico nodo Np verso <strong>un</strong>o dei propri figli Nc deve esistere <strong>un</strong>a relazione<br />
parent in Nc verso Np e viceversa.<br />
Si osservi che le relazioni parent hanno <strong>un</strong> attributo (backPropagation)<br />
booleano (non presente in figura 7.3, si faccia quin<strong>di</strong> riferimento allo Schema<br />
in formato testuale) che permette <strong>di</strong> stabilire se per quel particolare genitore<br />
è attiva o meno la propagazione all’in<strong>di</strong>etro delle versioni.<br />
Il gruppo history contiene vari elementi, descritti <strong>di</strong> seguito:<br />
• historyId: identificativo dello storico. Per convenzione è stato scelto<br />
<strong>di</strong> utilizzare il PRI del nodo ra<strong>di</strong>ce dello storico, in<strong>di</strong>rizzo <strong>un</strong>ivoco per<br />
definizione;<br />
• versionId: identificativo della versione all’interno dello storico. La<br />
sintassi è definita tramite l’espressione regolare [Goy06] riportata in<br />
figura 7.6. Tale espressione regolare permette <strong>di</strong> rappresentare la cate-<br />
([1-9][0-9]+\.[1-9][0-9]*\.)*[1-9][0-9]*<br />
Figura 7.6: Espressione regolare che definisce gli identificativi <strong>di</strong> versione.<br />
goria delle stringhe contenenti <strong>un</strong> numero arbitrario positivo <strong>di</strong> elementi<br />
costituiti da cifre terminanti con <strong>un</strong> p<strong>un</strong>to e <strong>un</strong>a sequenza terminale <strong>di</strong><br />
cifre. Le sequenze <strong>di</strong> cifre rappresentano numeri interi e non possono<br />
iniziare con “0”. Il numero <strong>di</strong> caratteri “.” deve essere pari, vale a <strong>di</strong>re<br />
che la quantità <strong>di</strong> sequenze <strong>di</strong> cifre presenti è sempre <strong>di</strong>spari. Il motivo<br />
<strong>di</strong> questo vincolo sarà chiarito più avanti.<br />
177
Il servizio fornito dal layer Structure La struttura dati interna a Structure<br />
Ad esempio, appartengono a questa classe le seguenti stringhe: “21”,<br />
“8.9.12”, eccetera. Non appartengono a questa classe le seguenti stringhe:<br />
“7.”, “.12”, “01.3”, “Ver=1.4”, “8.9.12.4”, eccetera. In particolare<br />
l’ultima mostrata non è valida in quanto è presente <strong>un</strong>a quantità<br />
pari (non <strong>di</strong>spari) <strong>di</strong> sequenze <strong>di</strong> cifre. La struttura dell’identificativo<br />
Identificatore<br />
assoluto del branch<br />
N 1 .N 2 . ... .N n .B id .R id<br />
Identificatore<br />
della ra<strong>di</strong>ce<br />
del branch<br />
Identificatore<br />
della revisione<br />
Identificatore<br />
relativo del<br />
branch<br />
Figura 7.7: Convenzione sui nomi dei no<strong>di</strong> relativi allo storico.<br />
è riportata in figura 7.7.<br />
Tale rappresentazione permette <strong>di</strong> in<strong>di</strong>viduare <strong>un</strong>ivocamente le versioni<br />
all’interno dello storico e il branch <strong>di</strong> appartenenza.<br />
Per convenzione le prime N −1 cifre rappresentano l’identificatore assoluto<br />
del branch all’interno dello storico. Questo identificatore si ottiene<br />
aggi<strong>un</strong>gendo al nome del nodo dal quale il branch è stato creato <strong>un</strong>a<br />
cifra sequenziale, l’identificatore relativo del branch. In questo modo<br />
il primo branch del nodo “X.Y.Z” è “X.Y.Z.1”, il secondo branch è<br />
“X.Y.Z.2”, eccetera.<br />
In ogni branch è presente almeno <strong>un</strong> nodo e l’ultima cifra del nome<br />
identifica la revisione relativamente al branch. In riferimento all’esempio<br />
precedente la prima revisione nel primo branch è “X.Y.Z.1.1”, la<br />
seconda revisione nel primo branch è “X.Y.Z.1.2”, la n-esima revisione<br />
nel m-esimo branch è “X.Y.Z.m.n”;<br />
• created: rappresenta la data e l’ora <strong>di</strong> creazione dell’elemento e contiene<br />
l’identificativo del processo <strong>di</strong> livello Structure che lo ha creato.<br />
Inoltre, nell’ipotesi in cui ogni azione che si sviluppa nel sistema sia riconducibile<br />
ad <strong>un</strong> Avatar, contiene anche l’identificativo (PRI) <strong>di</strong> tale<br />
Avatar;<br />
• mo<strong>di</strong>fied: contiene le medesime informazioni del parametro created<br />
178
Il servizio fornito dal layer Structure La struttura dati interna a Structure<br />
con la <strong>di</strong>fferenza che viene aggiornato ad ogni mo<strong>di</strong>fica <strong>di</strong> <strong>un</strong> qual<strong>un</strong>que<br />
elemento presente nel nodo (sia nel caso <strong>di</strong> sovrascritture dei contenuti<br />
che <strong>di</strong> aggiornamento dei metadati, ad esempio a seguito dell’aggi<strong>un</strong>ta<br />
del link <strong>di</strong> versione verso la revisione successiva);<br />
• update: rappresenta lo stato che stabilisce la politica <strong>di</strong> gestione del nodo.<br />
I valori ammessi sono changing e frozen: nel primo caso le richieste<br />
<strong>di</strong> aggiornamento vengono gestite con sovrascrittura, nel secondo<br />
tramite la nascita <strong>di</strong> nuove revisioni (e la relativa propagazione);<br />
• versionLinks: gruppo <strong>di</strong> elementi che serve per co<strong>di</strong>ficare i link <strong>di</strong><br />
versione verso gli altri no<strong>di</strong>. Tali elementi sono:<br />
– revisionNext: in<strong>di</strong>rizzo del nodo che rappresenta la nuova revisione;<br />
– branch: elemento complesso che contiene i dati relativi al branch<br />
ra<strong>di</strong>cato nel nodo. Tali dati sono:<br />
∗ firstRevision: in<strong>di</strong>rizzo del nodo che rappresenta la prima<br />
revisione del branch;<br />
∗ branchLast: in<strong>di</strong>rizzo dell’ultimo nodo presente nel branch.<br />
Questo campo, per motivi <strong>di</strong> efficienza, è presente solo nella<br />
ra<strong>di</strong>ce del branch. A seguito <strong>di</strong> <strong>un</strong>a richiesta <strong>di</strong> accesso al<br />
branchLast l’algoritmo viene eseguito in due passi: nel primo<br />
si accede alla ra<strong>di</strong>ce del branch e nel secondo all’elemento<br />
richiesto. I vantaggi <strong>di</strong> questa soluzione sono evidenti nel<br />
caso <strong>di</strong> nascita <strong>di</strong> <strong>un</strong>a nuova revisione. Se ogni nodo del ramo<br />
possedesse l’in<strong>di</strong>rizzo del branchLast, il tempo necessario per<br />
la nascita <strong>di</strong> <strong>un</strong>a nuova revisione scalerebbe linearmente con il<br />
numero <strong>di</strong> revisioni del branch (tutti i riferimenti andrebbero<br />
aggiornati). Al contrario, la modalità attuata, permette <strong>di</strong><br />
aggiornare soltanto l’elemento ra<strong>di</strong>ce (operazione che avviene<br />
in tempo costante rispetto agli elementi nello storico) senza<br />
penalizzare eccessivamente la fase accesso (ulteriori dettagli<br />
saranno riportati nel paragrafo 7.3);<br />
– revisionPrevious: in<strong>di</strong>rizzo del nodo che rappresenta la revisione<br />
precedente rispetto alla corrente;<br />
179
Il servizio fornito dal layer Structure Introduzione agli algoritmi<br />
– branchRoot: in<strong>di</strong>rizzo del nodo che rappresenta la ra<strong>di</strong>ce del branch;<br />
– historyRoot: in<strong>di</strong>rizzo del nodo ra<strong>di</strong>ce dello storico, secondo le<br />
convenzioni utilizzate è il nodo con identificativo “1”;<br />
– timeLast: in<strong>di</strong>rizzo del nodo che, considerando l’intero storico,<br />
è stato introdotto più recentemente. Questo campo, per motivi<br />
<strong>di</strong> efficienza, è presente solo nella ra<strong>di</strong>ce <strong>di</strong> ogni branch e valgono<br />
tutte le considerazioni riportate per il caso del branchLast. In<br />
particolare deve memorizzare l’in<strong>di</strong>rizzo dell’ultimo elemento inserito<br />
nel ramo principale oppure in <strong>un</strong>o dei branch <strong>di</strong> cui il nodo<br />
è ra<strong>di</strong>ce. Si osservi che nella ra<strong>di</strong>ce dello storico il campo time-<br />
Last assume il significato dell’elemento inserito più recentemente<br />
in assoluto ed è il valore a cui occorre fare riferimento per la risoluzione<br />
del parametro <strong>di</strong> versione T_ABSLAST. I valori timeLast<br />
presenti nelle ra<strong>di</strong>ci dei vari branch servono per risolvere le richieste<br />
relative al parametro T_RELATLAST come sarà più chiaro in<br />
seguito.<br />
7.3 Introduzione agli algoritmi<br />
Il questo paragrafo verranno introdotti gli algoritmi che il sistema <strong>di</strong> versioning<br />
dovrà implementare, in modo particolare verrà messo in evidenza il<br />
comportamento <strong>di</strong> ogni processo <strong>di</strong> livello Structure a seguito delle richieste<br />
<strong>di</strong> servizio effettuate da Virtual Repository (tramite l’interfaccia descritta nel<br />
sotto paragrafo 7.1.1). Inoltre questo p<strong>un</strong>to <strong>di</strong> vista permette <strong>di</strong> evidenziare<br />
come Structure si relazioni con Replica Management tramite l’interfaccia<br />
descritta nel sotto paragrafo 7.1.2.<br />
Infine verranno introdotte alc<strong>un</strong>e problematiche che sorgono nella progettazione<br />
<strong>di</strong> <strong>un</strong> sistema complesso come CISA, per esempio quelle legate<br />
alla gestione della concorrenza per mantenere lo spazio delle informazioni<br />
consistente.<br />
I formalismi utilizzati per la descrizione degli algoritmi sono sostanzialmente<br />
due: il linguaggio naturale e i <strong>di</strong>agrammi <strong>di</strong> sequenza definiti in UML<br />
([RJB99]).<br />
180
Il servizio fornito dal layer Structure Introduzione agli algoritmi<br />
7.3.1 Accesso ai documenti<br />
L’accesso alle informazioni è <strong>un</strong>’operazione che viene avviata dai livelli<br />
<strong>di</strong> CISA che si trovano sopra a Structure. L’aggregazione dei no<strong>di</strong> che costituiscono<br />
i documenti viene svolta da Virtual Repository. In particolare si<br />
ricorda che le relazioni fra no<strong>di</strong> previste in D3IM sono <strong>di</strong> due tipologie: link<br />
<strong>di</strong> riferimento e link <strong>di</strong> composizione.<br />
La prima categoria <strong>di</strong> link è equivalente alle informazioni atomiche, pertanto<br />
viene definita e gestita integralmente ai livelli superiori; naturalmente<br />
anche per quanto riguarda il versioning viene trattata come tale. Un’informazione<br />
atomica varia se viene mo<strong>di</strong>ficata la coppia “” ovvero,<br />
nel caso in esame, il link stesso. Non vi è correlazione con le eventuali mo<strong>di</strong>fiche<br />
all’elemento riferito. Si osservi che si considera in<strong>di</strong>rettamente mo<strong>di</strong>ficata<br />
l’informazione primitiva che la incapsula e sulla quale vengono applicati gli<br />
algoritmi <strong>di</strong> versioning.<br />
La seconda categoria <strong>di</strong> link è strettamente legata al concetto <strong>di</strong> propagazione<br />
delle mo<strong>di</strong>fiche e pertanto la gestione interna dei link <strong>di</strong> composizione<br />
è a carico del layer Structure. A seguito <strong>di</strong> <strong>un</strong>a richiesta <strong>di</strong> accesso ad <strong>un</strong><br />
elemento da parte <strong>di</strong> Virtual Repository, il layer Structure fornisce quin<strong>di</strong> il<br />
contenuto del body del nodo (definito nel layer stesso, paragrafo 7.2) e, in<br />
<strong>un</strong>’opport<strong>un</strong>a struttura dati, la lista dei figli aggregati per composizione.<br />
In questo modo Virtual Repository può analizzare il contenuto <strong>di</strong> sua competenza<br />
(presente nel body <strong>di</strong> livello Structure) ed estrarre i link <strong>di</strong> riferimento<br />
co<strong>di</strong>ficati come informazioni atomiche.<br />
A questo p<strong>un</strong>to Virtual Repository ha a <strong>di</strong>sposizione tutti i link uscenti dal<br />
nodo e può selezionare quelli <strong>di</strong> interesse sui quali, ricorsivamente, proseguire<br />
nell’accesso per la visita dell’intero documento.<br />
7.3.2 Uso del parametro <strong>di</strong> versione<br />
Nella descrizione della modalità <strong>di</strong> accesso appena introdotta non viene<br />
fatto riferimento al parametro <strong>di</strong> versione.<br />
Si ricorda che il parametro <strong>di</strong> versione è stato introdotto per permettere<br />
la navigazione all’interno dello storico delle informazioni, quin<strong>di</strong> in questo<br />
sotto paragrafo verrà descritto come viene utilizzato.<br />
Si ricorda anche che il meccanismo <strong>di</strong> propagazione permette <strong>di</strong> riportare<br />
le mo<strong>di</strong>fiche attuate ai no<strong>di</strong> che si trovano più in basso nella gerarchia del<br />
documento verso quelli che si trovano più in alto. Questo vuol <strong>di</strong>re che ogni<br />
181
Il servizio fornito dal layer Structure Introduzione agli algoritmi<br />
mo<strong>di</strong>fica ad <strong>un</strong> qual<strong>un</strong>que elemento del documento si ripercuote fino alla<br />
sua ra<strong>di</strong>ce. In altre parole, partendo dalla revisione corretta della ra<strong>di</strong>ce del<br />
documento, è possibile ottenere la configurazione completa <strong>di</strong> esso applicando<br />
l’algoritmo ricorsivo descritto in precedenza (che opera con in<strong>di</strong>rizzamento<br />
assoluto).<br />
Senza escludere la possibilità che Virtual Repository richieda tutti i no<strong>di</strong><br />
del documento esplicitando <strong>un</strong> particolare parametro <strong>di</strong> versione, l’approccio<br />
convenzionale <strong>di</strong> accesso all’informazione <strong>versionata</strong> consiste nel reperire la<br />
versione voluta della ra<strong>di</strong>ce del documento e poi, ricorsivamente, accedere ai<br />
livelli inferiori della gerarchia senza parametro <strong>di</strong> versione.<br />
Infatti, operando in questo modo, si ha la garanzia (fornita dal meccanismo<br />
<strong>di</strong> propagazione) che il documento ricostruito sia consistente sia nei<br />
contenuti che nella struttura.<br />
Accesso alla versione<br />
Per il layer Structure, in<strong>di</strong>pendentemente dalla politica stabilita e utilizzata<br />
dai layer superiori, l’accesso ad <strong>un</strong>’informazione tramite parametro <strong>di</strong><br />
versione è relativo ad <strong>un</strong> singolo nodo. In questo sotto paragrafo verranno<br />
brevemente descritti alc<strong>un</strong>i dei possibili meccanismi per l’accesso ad <strong>un</strong>a<br />
specifica versione:<br />
• R_NEXT, R_PREV, H_ROOT, B_ROOT: in riferimento allo Schema riportato<br />
nel sotto paragrafo 7.2.1 ed alla figura 7.4, l’accesso da parte del layer<br />
Structure a questo tipo <strong>di</strong> informazioni (che avviene a seguito <strong>di</strong> <strong>un</strong>a<br />
richiesta <strong>di</strong> tipo GET(PRI+PAR_VER) da parte <strong>di</strong> Virtual Repository),<br />
avviene in due passi <strong>di</strong> elaborazione:<br />
1. accesso al nodo <strong>di</strong> partenza tramite <strong>un</strong>a richiesta GET(PRI) a<br />
Replica Management (riferimento UC.Rep.Int.1);<br />
2. ricerca dell’in<strong>di</strong>rizzo della versione voluta all’interno della sezione<br />
header → history → versionLinks e successivo accesso tramite<br />
GET a Replica Management;<br />
• T_ABSLAST, B_LAST: in questo caso l’accesso avviene in tre passi:<br />
1. accesso al nodo <strong>di</strong> partenza tramite <strong>un</strong>a richiesta GET(PRI) a<br />
Replica Management;<br />
182
Il servizio fornito dal layer Structure Introduzione agli algoritmi<br />
2. ricerca dell’in<strong>di</strong>rizzo della ra<strong>di</strong>ce dello storico (in caso <strong>di</strong> richiesta<br />
<strong>di</strong> accesso a T_ABSLAST) o della ra<strong>di</strong>ce del branch (in caso <strong>di</strong><br />
B_LAST) nella sezione: header → history → versionLinks e<br />
successivo accesso tramite GET a Replica Management;<br />
3. ricerca dell’in<strong>di</strong>rizzo della versione voluta all’interno della sezione:<br />
header → history → versionLinks e accesso, finale, tramite<br />
GET a Replica Management.<br />
La figura 7.8 mostra i tre passi necessari per l’in<strong>di</strong>rizzamento e l’accesso<br />
al “last” sia nel caso in cui il “last” sia relativo all’ultimo elemento<br />
mo<strong>di</strong>ficato cronologicamente (parametro <strong>di</strong> versione T_ABSLAST) che<br />
nel caso in cui sia relativo all’ultima revisione del branch (parametro <strong>di</strong><br />
versione B_LAST). Nel primo caso il nodo identificato con R1 rappresenta<br />
la ra<strong>di</strong>ce dello storico, nel secondo caso la ra<strong>di</strong>ce del branch.<br />
(2) first<br />
R1 R2 R3 R4 R5<br />
(3) last<br />
Figura 7.8: Accesso al nodo “last” in tempo costante.<br />
• T_RELATLAST: in questo caso l’accesso avviene in N passi (con N inferiore<br />
o uguale al numero <strong>di</strong> elementi presenti dal nodo <strong>di</strong> partenza alla<br />
fine del ramo a cui appartiene):<br />
1. accesso al nodo <strong>di</strong> partenza tramite <strong>un</strong>a richiesta GET(PRI) a<br />
Replica Management;<br />
2. ricerca dell’in<strong>di</strong>rizzo della revisione successiva all’interno della sezione:<br />
header → history → versionLinks ed accesso ad essa<br />
tramite GET a Replica Management. Questo p<strong>un</strong>to si ripete fino<br />
(1)<br />
183
Il servizio fornito dal layer Structure Introduzione agli algoritmi<br />
al raggi<strong>un</strong>gimento della fine del ramo oppure al raggi<strong>un</strong>gimento <strong>di</strong><br />
<strong>un</strong> nodo che è ra<strong>di</strong>ce <strong>di</strong> <strong>un</strong>o o più branch;<br />
3. nel caso del raggi<strong>un</strong>gimento del termine del ramo l’ultima revisione<br />
rappresenta l’elemento voluto altrimenti viene effettuata la<br />
ricerca dell’in<strong>di</strong>rizzo del timeLast (che, per come è stato definito,<br />
rappresenta l’elemento voluto) all’interno della sezione: header →<br />
history → versionLinks e accesso, finale, tramite GET a Replica<br />
Management.<br />
Questo algoritmo può essere reso più chiaro se applicato ad <strong>un</strong> esempio<br />
concreto. A tal proposito si faccia riferimento alla figura 6.14 presente<br />
nel paragrafo 6.2.6 a pagina 155. La sequenza degli eventi è la seguente:<br />
– viene richiesto il T_RELATLAST del nodo creato al tempo t=7;<br />
– partendo dal nodo creato a t=7 l’algoritmo procede con la scansione<br />
delle revisioni successive fino al raggi<strong>un</strong>gimento della fine del<br />
branch a cui tale nodo appartiene oppure <strong>di</strong> <strong>un</strong> nodo ra<strong>di</strong>ce <strong>di</strong> <strong>un</strong>o<br />
o più branch. Il nodo <strong>di</strong> partenza può sod<strong>di</strong>sfare imme<strong>di</strong>atamente<br />
<strong>un</strong>a, o entrambe, le con<strong>di</strong>zioni. Nel caso in cui vengono verificate<br />
entrambe ha la precedenza il fatto che il nodo è ra<strong>di</strong>ce <strong>di</strong> <strong>un</strong>o o<br />
più branch. Nell’esempio si avanza fino al nodo creato al tempo<br />
t=8, ra<strong>di</strong>ce <strong>di</strong> <strong>un</strong> branch;<br />
– se il nodo a cui l’algoritmo è gi<strong>un</strong>to è l’ultima revisione del ramo il<br />
risultato è il nodo stesso. Invece se, come nell’esempio, è la ra<strong>di</strong>ce<br />
<strong>di</strong> <strong>un</strong>o o più branch, contiene l’in<strong>di</strong>rizzo dell’elemento voluto nel<br />
link <strong>di</strong> versione timeLast.<br />
In figura 7.9 è mostrato il <strong>di</strong>agramma <strong>di</strong> sequenza relativo ad <strong>un</strong>a richiesta<br />
<strong>di</strong> accesso al documento da parte dell’utente. Le interazioni fra utente e<br />
Application e fra Application e Virtual Repository non interessano in questo<br />
contesto e non sono descritte in modo formale.<br />
La sequenza degli eventi è la seguente:<br />
• l’utente richiede il documento all’applicazione agendo sull’interfaccia<br />
utente che questa fornisce;<br />
• Application richiede, tramite <strong>un</strong>a chiamata all’opport<strong>un</strong>a primitiva, il<br />
documento a Virtual Repository (passo 2);<br />
184
Il servizio fornito dal layer Structure Introduzione agli algoritmi<br />
Figura 7.9: Diagramma <strong>di</strong> sequenza relativo all’accesso ad <strong>un</strong> documento.<br />
• al passo 3, Virtual Repository richiede la ra<strong>di</strong>ce a Structure specificandone<br />
l’in<strong>di</strong>rizzo <strong>un</strong>ivoco pri ed, eventualmente, il parametro <strong>di</strong> versione<br />
invocando la primitiva GET (UC.Str.Int.1);<br />
• al passo 4 Structure richiede a Replica Management il nodo corrispondente<br />
all’in<strong>di</strong>rizzo specificato (pri);<br />
• nel caso in cui Virtual Repository non abbia specificato il parametro <strong>di</strong><br />
versione i passi 5 e 6 non vengono eseguiti. Viceversa Structure (passo<br />
5) analizza l’header del nodo e sceglie il link <strong>di</strong> versione da seguire.<br />
Tale link specifica l’in<strong>di</strong>rizzo PRI nella nuova revisione la quale (passo<br />
6) viene richiesta a Replica Management. Se il parametro <strong>di</strong> versione è<br />
R_NEXT, R_PREV, H_ROOT oppure B_ROOT la procedura termina in quanto<br />
il nodo richiesto a Replica Management è quello voluto. Viceversa se il<br />
parametro <strong>di</strong> versione è T_ABSLAST o B_LAST occorre <strong>un</strong> altro passo <strong>di</strong><br />
elaborazione e, in tal caso, vengono ripetuti <strong>un</strong>’ulteriore volta i passi 5<br />
e 6. Infine se il parametro <strong>di</strong> versione è T_RELATLAST occorrono altri<br />
185
Il servizio fornito dal layer Structure Introduzione agli algoritmi<br />
passi <strong>di</strong> elaborazione e, in tal caso, vengono ripetuti i passi 5 e 6 quanto<br />
necessario;<br />
• i passi 7 ed 8 servono per recuperare (ricorsivamente) tutti i no<strong>di</strong> del<br />
documento che alla fine viene fatto pervenire ad Application e mostrato<br />
all’utente. Si osservi che normalmente in questa fase, ver par non<br />
viene specificato in quanto, <strong>un</strong>a volta in<strong>di</strong>viduata la versione corretta<br />
della ra<strong>di</strong>ce, si ricostruisce correttamente la configurazione voluta del<br />
documento seguendo i link verso i figli con parametro <strong>di</strong> versione nullo.<br />
7.3.3 Mo<strong>di</strong>fica <strong>di</strong> documenti<br />
L’operazione <strong>di</strong> mo<strong>di</strong>fica delle informazioni è senza dubbio più complessa<br />
rispetto a quella <strong>di</strong> in<strong>di</strong>rizzamento ed accesso illustrata precedentemente. Si<br />
tratta infatti <strong>di</strong> <strong>un</strong>’operazione <strong>di</strong>struttiva e pertanto deve essere rigidamente<br />
regolamentata per evitare problematiche <strong>di</strong> inconsistenza dei dati dovute ad<br />
eventuali accessi concorrenti.<br />
Il livello Structure, compatibilmente con la visione che ha dell’informazione<br />
e collaborando con i livelli ad esso a<strong>di</strong>acenti, permette <strong>di</strong> implementare<br />
le politiche <strong>di</strong> accesso e <strong>di</strong> authoring concorrente previste nel <strong>modello</strong> D3IM<br />
e descritte nel paragrafo 4.4.2.<br />
Si ricorda che le politiche attuate sono le seguenti:<br />
• Strong: blocca in scrittura e in lettura tutti i no<strong>di</strong> interessati all’apertura<br />
della sessione.<br />
• Soft: blocca i no<strong>di</strong> in scrittura lasciando la possibilità <strong>di</strong> accesso in<br />
lettura.<br />
• Relaxed: consente <strong>di</strong> effettuare authoring concorrente tramite l’approccio<br />
copy-merge.<br />
Le prime due prevedono il blocco esclusivo <strong>di</strong> <strong>un</strong> insieme <strong>di</strong> no<strong>di</strong> appartenenti<br />
ad <strong>un</strong>o o più documenti. La scelta dei no<strong>di</strong> sui quali acquisire il lock è<br />
<strong>di</strong> competenza dei livelli superiori a Structure in quanto si basa sugli aspetti<br />
strutturali del documento.<br />
La Relaxed, permette <strong>di</strong> attuare politiche ottimistiche e, in prima approssimazione,<br />
si potrebbe pensare che non sia necessario contrassegnare i no<strong>di</strong><br />
186
Il servizio fornito dal layer Structure Introduzione agli algoritmi<br />
che si intende mo<strong>di</strong>ficare. In CISA invece si è scelto <strong>di</strong> applicare ad essi <strong>un</strong>’etichetta<br />
il cui <strong>un</strong>ico aspetto f<strong>un</strong>zionale è relativo all’aumento dell’awareness<br />
<strong>di</strong> alto livello.<br />
Infine è stato in<strong>di</strong>viduato <strong>un</strong> ulteriore caso, utile per aumentare ulteriormente<br />
l’awareness <strong>di</strong> alto livello. Questo risultato può essere ottenuto<br />
prevedendo due tipologie <strong>di</strong> etichette: <strong>un</strong>a, già descritta, relativa ai no<strong>di</strong> sui<br />
quali si intende effettuare <strong>un</strong>a mo<strong>di</strong>fica; l’altra relativa agli elementi <strong>di</strong> interesse<br />
coinvolti in sola lettura per i quali si intende ricorrere allo schema <strong>di</strong><br />
interazione Publish & Subscribe [Inn04].<br />
La finalità del primo tipo <strong>di</strong> etichetta è quella <strong>di</strong> aumentare l’awareness degli<br />
altri utenti che possono essere interessati al nodo sul quale si sta operando.<br />
Dualmente il secondo tipo <strong>di</strong> etichetta serve per aumentare il proprio livello<br />
<strong>di</strong> awareness, fornendo all’utente <strong>un</strong> metodo per essere informato su eventuali<br />
mo<strong>di</strong>fiche effettuate dagli altri utenti sui no<strong>di</strong> <strong>di</strong> interesse. Si noti che<br />
l’introduzione del meccanismo <strong>di</strong> notifica visto nel capitolo 5 permetterebbe<br />
<strong>di</strong> informare l’utente in modalità push.<br />
Alla luce <strong>di</strong> queste considerazioni sono state identificate le quattro etichette<br />
applicabili tramite l’operazione <strong>di</strong> “marcatura” del nodo descritte nel<br />
caso d’uso UC.Str.Int.5 (a pagina 163):<br />
• OBSERVED 5 , per mettere i no<strong>di</strong> sotto osservazione;<br />
• RELAXED, per in<strong>di</strong>care che l’utente è interessato alla mo<strong>di</strong>fica del nodo;<br />
• LOCKED_STRONG, per acquisire il lock Strong (sia in lettura che in scrittura)<br />
sul nodo;<br />
• LOCKED_SOFT, per acquisire il lock Soft (solo in scrittura) sul nodo;<br />
• NULL, per in<strong>di</strong>care che si intendono rimuovere tutte le etichette.<br />
Si osservi che le prime due etichette possono essere applicate contemporaneamente<br />
6 e che il loro inserimento in <strong>un</strong> nodo è <strong>un</strong>’operazione <strong>di</strong>struttiva<br />
e quin<strong>di</strong> occorre trattarla come tale.<br />
In conclusione l’operazione <strong>di</strong> marcatura dei no<strong>di</strong> deve essere effettuata<br />
prima <strong>di</strong> ogni operazione <strong>di</strong> mo<strong>di</strong>fica. Nella figura 7.10 viene descritta la<br />
sequenza dei passi che devono essere svolti per applicare la marcatura:<br />
5Serve per effettuare l’equivalente della sottoscrizione definita nel contesto dello schema<br />
<strong>di</strong> interazione Publish & Subscribe.<br />
6Le etichette LOCKED_STRONG e LOCKED_SOFT vengono utilizzate in modo esclusivo in<br />
quanto garantiscono, per definizione, che ness<strong>un</strong> altro possa mo<strong>di</strong>ficare il nodo.<br />
187
Il servizio fornito dal layer Structure Introduzione agli algoritmi<br />
• l’utente (o per suo conto l’applicazione) stabilisce la lista dei no<strong>di</strong><br />
da mo<strong>di</strong>ficare e le politiche <strong>di</strong> accesso da applicare. Inoltre vengono<br />
in<strong>di</strong>viduati eventuali no<strong>di</strong> da mettere sotto osservazione;<br />
Figura 7.10: Diagramma <strong>di</strong> sequenza relativo alla prenotazione per la<br />
mo<strong>di</strong>fica <strong>di</strong> <strong>un</strong> documento.<br />
• Virtual Repository viene messo nella con<strong>di</strong>zione <strong>di</strong> effettuare la richiesta<br />
<strong>di</strong> marcatura dei no<strong>di</strong> (passi 1 e 2);<br />
• Virtual Repository effettua la richiesta <strong>di</strong> marcatura tramite la primitiva<br />
MARK. La richiesta viene effettuata fornendo <strong>un</strong>a tabella (table)<br />
nella quale vengono in<strong>di</strong>cati tutti i no<strong>di</strong> da marcare con le relative etichette.<br />
La finalità <strong>di</strong> questo approccio è <strong>di</strong> garantire al Livello Virtual<br />
Repository che l’operazione <strong>di</strong> marcatura avvenga in modo atomico: se<br />
tutti i no<strong>di</strong> sono etichettabili l’operazione riesce, altrimenti fallisce;<br />
• al passo 4 viene richiesto il LOCK in modo esclusivo su tutti i no<strong>di</strong> a<br />
Replica Management 7 ;<br />
7 Si ipotizza che l’operazione <strong>di</strong> LOCK restituisca <strong>un</strong> parametro che permetta, se ne-<br />
188
Il servizio fornito dal layer Structure Introduzione agli algoritmi<br />
• al passo 5 il sistema applica le etichette;<br />
• al passo 6 viene richiesto il rilascio del LOCK.<br />
Lo scenario appena mostrato si riferisce al caso in cui l’operazione MARK<br />
riesce con successo. Si osservi che la politica descritta deve essere in grado<br />
<strong>di</strong> gestire correttamente il ciclo relativo al passo 4 che risulta, operando in<br />
questo modo, l’<strong>un</strong>ico p<strong>un</strong>to critico dovuto alla concorrenza e sul quale occorre<br />
prestare la massima attenzione in fase progettuale. I problemi che possono<br />
sorgere sono relativi ad eventuali “deadlock” e in generale sono quelli che<br />
tipicamente si presentano nel caso in cui vengano con<strong>di</strong>vise risorse fra entità<br />
asincrone tramite politiche <strong>di</strong>“locking”. L’approfon<strong>di</strong>mento <strong>di</strong> questo aspetto<br />
viene lasciato agli sviluppi futuri.<br />
La politica descritta, nell’ipotesi <strong>di</strong> rendere “sicuro” il ciclo al passo 4, risolve<br />
il problema della concorrenza anche se è estremamente conservativa e in<br />
grado <strong>di</strong> operare solo nelle ipotesi che hanno permesso <strong>di</strong> formulare la politica<br />
<strong>di</strong> propagazione “push” descritta nel sotto paragrafo 6.2.3 (a pagina 133).<br />
Il salvataggio delle informazioni è possibile soltanto se i no<strong>di</strong> <strong>di</strong> interesse<br />
sono stati precedentemente etichettati come appena descritto. Nella figura<br />
7.11 viene mostrata la sequenza temporale degli eventi nel caso in cui<br />
tutti i no<strong>di</strong> interessati si trovino nello stato FROZEN:<br />
• l’utente decide <strong>di</strong> salvare le mo<strong>di</strong>fiche e i layer Application e Virtual<br />
Repository si mettono nelle con<strong>di</strong>zioni <strong>di</strong> effettuare il commit verso<br />
Structure;<br />
• viene richiesta a Structure l’operazione COMMIT specificando <strong>un</strong>a lista<br />
(list) contenente tutti i no<strong>di</strong> mo<strong>di</strong>ficati;<br />
• il sistema richiede la versione precedente <strong>di</strong> tutti i no<strong>di</strong> presenti nella<br />
lista (passo 4);<br />
• il sistema (followBackPropagation()) segue i link <strong>di</strong> propagazione all’in<strong>di</strong>etro<br />
richiedendo tutti i no<strong>di</strong> interessati in modo ricorsivo al passo 5,<br />
applicando il meccanismo <strong>di</strong> propagazione “push”;<br />
• il sistema applica ai no<strong>di</strong> il LOCK al passo 6, dato che conosce esattamente<br />
quali sono quelli interessati dalla mo<strong>di</strong>fica;<br />
cessario, <strong>di</strong> determinare se il nodo richiesto precedentemente non sia stato nel frattempo<br />
mo<strong>di</strong>ficato. Altrimenti, per avere la garanzia <strong>di</strong> consistenza, occorre effettuare nuovamente<br />
la GET dei no<strong>di</strong> acquisiti.<br />
189
Il servizio fornito dal layer Structure Introduzione agli algoritmi<br />
Figura 7.11: Diagramma <strong>di</strong> sequenza relativo alla richiesta <strong>di</strong> salvataggio <strong>di</strong><br />
<strong>un</strong> documento.<br />
• il sistema crea la nuova revisione <strong>di</strong> ogni nodo (passo 7);<br />
• il sistema richiede al passo 8 il salvataggio <strong>di</strong> tutti i no<strong>di</strong> coinvolti fino al<br />
passo precedente in quanto in quelli appena creati deve essere inserito<br />
il valore aggiornato dell’informazione mentre in quelli già esistenti (che<br />
contengono le revisioni precedenti) occorre aggiornare i link <strong>di</strong> versione.<br />
Si osservi che il <strong>di</strong>agramma <strong>di</strong> sequenza non è esaustivo in quanto occorre<br />
andare ad aggiornare anche i link <strong>di</strong> versione presenti nella ra<strong>di</strong>ce <strong>di</strong><br />
190
Il servizio fornito dal layer Structure Introduzione agli algoritmi<br />
ogni branch che si incontra fino al raggi<strong>un</strong>gimento del ramo principale<br />
e nella ra<strong>di</strong>ce dello storico <strong>di</strong> ogni nodo. Nella ra<strong>di</strong>ce del branch <strong>di</strong> appartenenza<br />
del nodo occorre aggiornare i link branchLast e timeLast,<br />
mentre in tutti gli altri soltanto timeLast. Si capisce quin<strong>di</strong> che l’inserimento<br />
<strong>di</strong> <strong>un</strong>a nuova versione, dal p<strong>un</strong>to <strong>di</strong> vista dell’aggiornamento<br />
dei parametri legati allo storico, è <strong>un</strong>’operazione che scala linearmente<br />
con il numero <strong>di</strong> branch. Questo non rappresenta <strong>un</strong> problema in<br />
quanto il numero <strong>di</strong> branch è <strong>un</strong> parametro che deve essere tenuto sotto<br />
controllo per non rendere lo storico stesso eccessivamente complesso da<br />
trattare da parte dell’utente;<br />
• il sistema rilascia il LOCK su tutti i no<strong>di</strong> come ultimo passo.<br />
Si osservi che tutte le considerazioni riguardanti l’accesso concorrente in<br />
scrittura e l’atomicità della primitiva MARK possono essere estese anche al<br />
caso del COMMIT.<br />
Il concetto <strong>di</strong> sessione<br />
Il para<strong>di</strong>gma <strong>di</strong> interazione REST prevede che le entità interessate siano,<br />
per quanto possibile, stateless. Seguendo questa filosofia il concetto <strong>di</strong><br />
sessione, così come previsto ed introdotto in UEVM, viene gestito in modo<br />
implicito: si assume che l’apertura della sessione avvenga nel momento in cui<br />
i no<strong>di</strong> vengono marcati e che si abbia la chiusura della stessa in concomitanza<br />
della fase <strong>di</strong> COMMIT.<br />
La chiusura implicita della sessione è attuata nel <strong>di</strong>agramma <strong>di</strong> sequenza<br />
<strong>di</strong> figura 7.11. Il sistema infatti, partendo dalla lista dei no<strong>di</strong> effettivamente<br />
mo<strong>di</strong>ficati, segue i link <strong>di</strong> propagazione all’in<strong>di</strong>etro per in<strong>di</strong>viduare tutti i<br />
no<strong>di</strong> interessati dalla propagazione. Per ogn<strong>un</strong>o <strong>di</strong> essi viene creata <strong>un</strong>a e<br />
<strong>un</strong>a sola nuova versione in<strong>di</strong>pendentemente dal fatto che quel nodo venga<br />
incontrato <strong>un</strong>a o più volte durante la risalita nella gerarchia dei no<strong>di</strong>. Tale<br />
versione comprende tutte le variazioni effettuate sui <strong>di</strong>scendenti durante la<br />
sessione.<br />
Servizi <strong>di</strong> branching e <strong>di</strong> merging<br />
Le primitive necessarie per effettuare le operazioni <strong>di</strong> branch e <strong>di</strong> merge<br />
sono state progettate in modo tale che operino anch’esse su <strong>un</strong>a lista <strong>di</strong> no<strong>di</strong><br />
con la finalità <strong>di</strong> rendere tali operazioni atomiche per Virtual Repository.<br />
191
Il servizio fornito dal layer Structure Introduzione agli algoritmi<br />
Per quanto riguarda il BRANCH è possibile affermare che può essere affrontato<br />
con le stesse modalità descritte per l’operazione <strong>di</strong> COMMIT con la <strong>di</strong>fferenza<br />
che non è necessario marcare precedentemente i no<strong>di</strong> <strong>di</strong> partenza in quanto,<br />
avendo il significato logico <strong>di</strong> copia dell’informazione, non occorre prevedere<br />
ness<strong>un</strong> meccanismo che aumenti l’awareness <strong>di</strong> alto livello. Ad<strong>di</strong>rittura applicare<br />
le etichette, come descritto per il caso <strong>di</strong> mo<strong>di</strong>fica dell’informazione,<br />
sarebbe <strong>un</strong>’operazione fuorviante per l’utente.<br />
L’operazione <strong>di</strong> MERGE può essere ricondotta al caso <strong>di</strong> mo<strong>di</strong>fica dell’informazione,<br />
pertanto viene svolta secondo le medesime modalità. Questa<br />
similitu<strong>di</strong>ne deriva dal fatto che effettuare <strong>un</strong> MERGE equivale a creare <strong>un</strong>a<br />
nuova revisione sul ramo verso il quale si attua la fusione, con la <strong>di</strong>fferenza<br />
che, in questo caso, devono essere aggiornati anche i link <strong>di</strong> versione presenti<br />
sui no<strong>di</strong> che si trovano sull’altro branch.<br />
192
Capitolo<br />
8<br />
Il servizio <strong>di</strong> risoluzione dei nomi<br />
I nomi user-friendly (HFN) sono stati introdotti nel capitolo 4 (in particolare<br />
nel sotto paragrafo 4.2.1 a pagina 86) al fine <strong>di</strong> colmare il <strong>di</strong>vario tra la<br />
denominazione interna al sistema con identificativi <strong>un</strong>ici (URN) e le esigenze<br />
<strong>di</strong> alto livello dell’utente. Il principale vantaggio è la possibilità <strong>di</strong> realizzare<br />
visioni multiple della stessa risorsa, simulando contesti coerenti all’esperienza<br />
quoti<strong>di</strong>ana degli utenti. Il sistema degli URN consente l’in<strong>di</strong>rizzamento <strong>di</strong><br />
insiemi <strong>di</strong> repliche che sono singolarmente accessibili a basso livello tramite<br />
URL.<br />
Nel <strong>modello</strong> stratificato CISA ogni livello ha bisogno <strong>di</strong> <strong>un</strong> in<strong>di</strong>rizzo che<br />
<strong>di</strong>stingua il p<strong>un</strong>to <strong>di</strong> accesso sull’interfaccia. In particolare i nomi HFN sono<br />
adatti ad in<strong>di</strong>rizzare le entità <strong>di</strong> Virtual Repository Layer, mentre gli URN<br />
rispondono alle esigenze <strong>di</strong> <strong>un</strong>icità delle entità dei livelli Structure. Infine<br />
gli URL si prestano per l’accesso alle risorse, <strong>di</strong> competenza del Replica<br />
Management Layer.<br />
I tre spazi dei nomi devono essere tra loro relazionati attraverso due meccanismi<br />
<strong>di</strong> risoluzione: il primo si occupa <strong>di</strong> risolvere HFN in URN ed il<br />
secondo si occupa <strong>di</strong> risolvere URN in URL. La risoluzione deve essere possibile<br />
anche in modo inverso, ovvero dato <strong>un</strong> URL <strong>di</strong> <strong>un</strong>a replica deve essere<br />
possibile risalire al rispettivo URN, e quin<strong>di</strong> a tutti i possibili HFN.<br />
I concetti alla base del sistema sono fondamentalmente analoghi alle speci-
Il servizio <strong>di</strong> risoluzione dei nomi Requisiti dei nomi<br />
fiche generali del DNS (Domain Name System) [Moc87a, Moc87b]. Si ricorda<br />
che i principali componenti del DNS sono:<br />
• Domain Name Space: spazio dei nomi è strutturato ad albero;<br />
• Name Server: programmi che detengono la struttura ad albero del dominio<br />
e l’insieme delle informazioni correlate. Un name server è detto<br />
Authority per alc<strong>un</strong>e parti del Name Space. Le autorità sono organizzate<br />
in <strong>un</strong>ità chiamate Zone, le quali possono essere automaticamente<br />
<strong>di</strong>stribuite.<br />
• Resolver: programmi che estraggono l’informazione dai Name Server<br />
in risposta alle richieste dei client.<br />
Nel sistema in <strong>di</strong>scussione la risoluzione è affidata a server strettamente<br />
correlati al responsabile dell’informazione. Sebbene in seguito l’informazione<br />
possa migrare, il servizio <strong>di</strong> risoluzione è marginalmente incurante <strong>di</strong> questo<br />
aspetto: l’accesso e la risoluzione sono due attività completamente in<strong>di</strong>pendenti.<br />
Questo approccio consente <strong>di</strong> rispondere al requisito <strong>di</strong> mantenere,<br />
quando possibile, il legame con la sorgente. Si prevede quin<strong>di</strong> che la risoluzione<br />
rimanga sempre in carico ai server <strong>di</strong> risoluzione <strong>di</strong> proprietà dell’organizzazione<br />
<strong>di</strong> cui fa parte il responsabile che inserisce la prima (ed <strong>un</strong>ica)<br />
volta l’informazione.<br />
8.1 Requisiti dei nomi<br />
Il sistema è caratterizzato da tre tipologie <strong>di</strong> nomi: HFN, URN e URL.<br />
Questi sono utilizzati per finalità <strong>di</strong>verse. Mentre per URN ed URL esistono<br />
delle specifiche standar<strong>di</strong>zzate, per gli HFN esiste <strong>un</strong>a forte esigenza, ma<br />
ness<strong>un</strong> vincolo precisamente <strong>di</strong>chiarato. In particolare i requisiti <strong>di</strong> base<br />
degli URN coincidono con quelli degli URI (Uniform Resource Identifier), in<br />
quanto gli URN ne costituiscono <strong>un</strong> sottoinsieme.<br />
Il sistema delle applicazioni ha bisogno <strong>di</strong> ricercare ed identificare le informazioni<br />
che devono essere elaborate. Al crescere della connettività della<br />
rete la capacità <strong>di</strong> usare risorse remote, in<strong>di</strong>pendentemente gestite, <strong>di</strong>venta<br />
<strong>un</strong>a necessità prioritaria.<br />
Un URN identifica <strong>un</strong> insieme <strong>di</strong> repliche ovvero <strong>un</strong>’<strong>un</strong>ità <strong>di</strong> informazione,<br />
mentre <strong>un</strong> URL identifica la locazione dell’istanza <strong>di</strong> <strong>un</strong>a risorsa all’interno<br />
194
Il servizio <strong>di</strong> risoluzione dei nomi Requisiti dei nomi<br />
dell’insieme. La risorsa, identificata prima tramite <strong>un</strong> URN e poi acceduta<br />
tramite <strong>un</strong> URL, può risiedere in <strong>un</strong>o o più host, può muoversi o non essere<br />
<strong>di</strong>sponibile a tutti.<br />
Un URL in<strong>di</strong>ca <strong>un</strong>a particolare replica <strong>di</strong> <strong>un</strong>a risorsa e dove questa risiede,<br />
mentre la risorsa stessa è in<strong>di</strong>cata dagli URN. Sotto questo p<strong>un</strong>to <strong>di</strong><br />
vista l’obiettivo degli URN è fornire <strong>un</strong> identificatore globalmente <strong>un</strong>ico e<br />
persistente, usabile anche per riconoscere e per accedere alle caratteristiche<br />
della risorsa (Uniform Resource Characteristic, URC) o alla risorsa stessa.<br />
In questo paragrafo verranno formulati i requisiti degli HFN e brevemente<br />
riportati quelli degli URN al fine <strong>di</strong> delineare le principali caratteristiche e<br />
presupposti per la definizione dei rispettivi spazi <strong>di</strong> nomi per CISA. Per<br />
quanto riguarda gli URL il sistema è completamente definito in [BLMM94].<br />
8.1.1 Requisiti per gli HFN<br />
Il sistema dei nomi ad alto livello in relazione all’architettura CISA deve<br />
essere:<br />
• comprensibile e facilmente usabile dall’essere umano;<br />
• facilmente memorizzabile e ricollegabile ad <strong>un</strong> contesto;<br />
• riferito alla struttura dell’ambiente virtuale;<br />
• facilmente analizzabile da <strong>un</strong> elaboratore;<br />
• non legato alla locazione delle risorse fisiche utilizzate;<br />
• tale da facilitare la navigazione;<br />
• composto da parole semplici.<br />
8.1.2 Requisiti per gli URN<br />
La persistenza <strong>di</strong> <strong>un</strong> identificativo in<strong>di</strong>ca l’in<strong>di</strong>pendenza dalla mutabilità<br />
dell’ambiente. L’assegnazione è immutabile, in quanto la mutabilità <strong>di</strong> <strong>un</strong>a<br />
risorsa è in<strong>di</strong>pendente dall’assegnazione del relativo identificativo.<br />
Affermare che <strong>un</strong> URN è persistente, cioè che ha <strong>un</strong> l<strong>un</strong>go tempo <strong>di</strong> vita,<br />
comporta assumere come valide le seguenti proprietà:<br />
195
Il servizio <strong>di</strong> risoluzione dei nomi Requisiti dei nomi<br />
• mobilità: le repliche possono muoversi fisicamente da <strong>un</strong>a macchina<br />
all’altra; i responsabili possono spostarsi all’interno dell’organizzazione<br />
oppure le organizzazioni autoritative possono <strong>un</strong>irsi, trasformarsi o<br />
<strong>di</strong>vidersi;<br />
• evoluzione: il sistema è continuamente in evoluzione cioè nuovi sottosistemi<br />
e protocolli possono essere creati ed i vecchi aggiornati.<br />
Requisiti non f<strong>un</strong>zionali<br />
Portata globale. Un URN è <strong>un</strong> nome globale, la cui portata non implica<br />
<strong>un</strong>a locazione. Ov<strong>un</strong>que ha lo stesso significato.<br />
Unicità globale. Lo stesso URN non può essere assegnato a due o più<br />
<strong>di</strong>fferenti risorse (che non siano repliche).<br />
Persistenza. Il tempo <strong>di</strong> vita <strong>di</strong> <strong>un</strong> URN è indefinito, cioè <strong>un</strong>a volta creato<br />
non è rimovibile. Questa ass<strong>un</strong>zione implica che <strong>un</strong> URN è globalmente <strong>un</strong>ico<br />
per sempre e può essere utilizzato per riferire <strong>un</strong>a risorsa oltre il tempo <strong>di</strong><br />
vita della risorsa stessa.<br />
Scalabilità. Gli URN possono essere assegnati a qualsiasi risorsa che deve<br />
essere mantenuta <strong>di</strong>sponibile in rete per <strong>un</strong> tempo indefinito.<br />
Supporto Legacy. Lo schema deve permettere il supporto a sistemi <strong>di</strong><br />
nomi già esistenti, come ad esempio DOI (Digital Object Identifier) [Fou04]<br />
e ISBN.<br />
Esten<strong>di</strong>bile. Lo schema degli URN deve permettere la crescita dello spazio<br />
dei nomi.<br />
In<strong>di</strong>pendenza. L’autorità che assegna i nomi è l’<strong>un</strong>ica responsabile nel<br />
determinare le con<strong>di</strong>zioni sull’emissione del nome.<br />
Risolubile. Un URN non deve ostacolare la risoluzione (ovvero la traduzione<br />
in URL). In particolare deve esistere <strong>un</strong> meccanismo flessibile che traduca<br />
<strong>un</strong> URN in <strong>un</strong> URL.<br />
196
Il servizio <strong>di</strong> risoluzione dei nomi LRI: gli identificatori logici delle risorse<br />
8.1.3 Requisiti sulla co<strong>di</strong>fica<br />
In aggi<strong>un</strong>ta ai precedenti requisiti ne esistono ulteriori, relativi alla co<strong>di</strong>fica<br />
e valevoli sia per HFN che per URN.<br />
Coerente ad altre co<strong>di</strong>fiche. La co<strong>di</strong>fica deve essere il più possibile<br />
coerente con altri schemi <strong>di</strong> nomi già esistenti.<br />
Semplicità del confronto. L’algoritmo per confrontare tra loro gli URN<br />
(HFN), intesi come stringhe, deve essere semplice, locale e deterministico.<br />
Trascrivibile dall’uomo. Per l’uomo deve essere possibile trascrivere gli<br />
URN (per gli HFN tale operazione deve risultare il più semplice possibile)<br />
per cui devono essere:<br />
• composti da <strong>un</strong>a sequenza sufficientemente limitata <strong>di</strong> caratteri;<br />
• case insensitive;<br />
• non complicati dall’uso <strong>di</strong> simboli speciali.<br />
Trasportabile. Un URN (HFN) è tale da essere identicamente trasportabile<br />
sia nei messaggi dei com<strong>un</strong>i protocolli Internet sia su carta.<br />
Trattabile dalla macchina. Un URN (HFN) deve essere processabile dai<br />
calcolatori.<br />
Riconoscibile. La co<strong>di</strong>fica <strong>di</strong> <strong>un</strong> URN (HFN) deve essere riconoscibile<br />
durante il parsing <strong>di</strong> <strong>un</strong> testo.<br />
8.2 LRI: gli identificatori logici delle risorse<br />
Si definisce identificatore logico <strong>di</strong> <strong>un</strong>a risorsa (LRI, Logical Resource<br />
Identifier) <strong>un</strong> nome HFN, appartenente all’insieme degli URI. Il nome è composto<br />
da più parti sud<strong>di</strong>vise dal carattere “/” ed ogni singola parte rappresenta<br />
<strong>un</strong>’entità logica dell’ambiente virtuale. L’insieme delle parti, separate<br />
da “/”, rappresenta il percorso. L’ultima entità è quella che si vuole in<strong>di</strong>viduare.<br />
L’intero percorso assieme all’entità da in<strong>di</strong>viduare è il nome logico<br />
197
Il servizio <strong>di</strong> risoluzione dei nomi LRI: gli identificatori logici delle risorse<br />
dell’entità. Il formato completo è illustrato in figura 8.1 con notazione BNF<br />
(Backus-Naur Form).<br />
Si osservi che l’insieme <strong>di</strong> caratteri utilizzabile per la definizione<br />
dei nomi è quello definito nel contesto degli URI [BLFIM98].<br />
Questa soluzione è stata scelta in base a quelle che sono state ritenute<br />
le esigenze attuali del progetto e può essere estesa, in modo da permettere<br />
l’agevole co<strong>di</strong>fica <strong>di</strong> stringhe appartenenti anche ad altri i<strong>di</strong>omi, nel momento<br />
in cui questo risulti necessario. A tal proposito è possibile fare riferimento<br />
agli Internationalized Resource Identifiers (IRI) descritti in [DWSC05].<br />
::= <br />
::= "lri://"()<br />
::= (/)*<br />
::= <br />
::= <br />
::= ";" | ":" | "&" | "=" | "+" | "$" | "," |<br />
"-" | "_" | "." | "!" | "~" | "*" | "’" |<br />
"(" | ")" | "a" | "b" | "c" | "d" | "e" |<br />
"f" | "g" | "h" | "i" | "j" | "k" | "l" |<br />
"m" | "n" | "o" | "p" | "q" | "r" | "s" |<br />
"t" | "u" | "v" | "w" | "x" | "y" | "z" |<br />
"A" | "B" | "C" | "D" | "E" | "F" | "G" |<br />
"H" | "I" | "J" | "K" | "L" | "M" | "N" |<br />
"O" | "P" | "Q" | "R" | "S" | "T" | "U" |<br />
"V" | "W" | "X" | "Y" | "Z" | "0" | "1" |<br />
"2" | "3" | "4" | "5" | "6" | "7" | "8" |<br />
"9"<br />
Figura 8.1: Sintassi dei Logical Name.<br />
Essendo i World ed i Group due concetti totalmente <strong>di</strong>sgi<strong>un</strong>ti, la sintassi<br />
del nome per i due casi è mutuamente esclusiva. Il percorso è utilizzato<br />
per effettuare tale <strong>di</strong>stinzione. Dato che gli Stuff e gli Avatar non possono<br />
contenere ness<strong>un</strong>a altra entità, quando vengono in<strong>di</strong>cati, <strong>di</strong>ventano necessariamente<br />
elementi terminali del nome. Opzionalmente ogni entità può essere<br />
specificata con la relativa estensione: .avt per gli Avatar, .grp per i Group,<br />
.stf per gli Stuff e .wrl per i World.<br />
Nel caso particolare degli Stuff, che nel <strong>modello</strong> CISA si specializzano in<br />
documenti D3IM, il nome può essere seguito da <strong>un</strong> ulteriore identificativo.<br />
198
Il servizio <strong>di</strong> risoluzione dei nomi PRI: gli identificatori persistenti<br />
Alc<strong>un</strong>i esempi <strong>di</strong> LRI ben formati sono:<br />
lri://world1.wrl/world2.wrl lri://world1.wrl/stuff1.stf<br />
lri://group1.grp/avtar2.grp lri://group1.grp/group2.grp<br />
lri://world1/world2/wolrd3/stuff2.stf<br />
Eventualmente il client (Application Layer) può applicare delle semplificazioni<br />
con la finalità <strong>di</strong> rendere i nomi ancora più amichevoli: potrebbero<br />
essere previsti il completamento automatico ed i suggerimenti in linea quando<br />
<strong>un</strong>a parte del nome non è coerente con la sintassi.<br />
Per l’assegnazione dei nomi è necessario <strong>un</strong> Authority, che eventualmente<br />
può coincidere con l’utente stesso.<br />
8.3 PRI: gli identificatori persistenti<br />
Ogni entità è globalmente <strong>un</strong>ica nel sistema da p<strong>un</strong>to <strong>di</strong> vista concettuale,<br />
è replicata varie volte (repliche fisiche, a basso livello) ed identificata dagli<br />
utenti tramite l’assegnazione <strong>di</strong> <strong>un</strong> numero arbitrario <strong>di</strong> LRI (alias, ad alto<br />
livello). Ogni entità dovrà avere quin<strong>di</strong> <strong>un</strong> identificativo <strong>un</strong>ico (URN) e persistente,<br />
assegnato nell’intero <strong>un</strong>iverso. L’assegnazione deve essere autonoma<br />
rispetto alla struttura organizzativa che ne detiene la responsabilità.<br />
Tali URN associati all’entità vengono pertanto chiamati identificatori<br />
persistenti della risorsa (PRI, Persistent Resource Identifier).<br />
In figura 8.2 è presente <strong>un</strong>a definizione dei PRI per l’architettura CISA<br />
espressa con il formalismo delle espressioni regolari 1 [Goy06].<br />
urn:pri:(0\.|([1-9][0-9]*)\.)*(0|([1-9][0-9]*))<br />
/[0-9a-zA-Z\-_.,();:=+$!~*’]+<br />
Figura 8.2: Espressione regolare che definisce i PRI in CISA.<br />
In figura 8.3 è riportata <strong>un</strong>a definizione equivalente con notazione BNF.<br />
Si osservi che la definizione prevede l’uso <strong>di</strong> <strong>un</strong> set <strong>di</strong> caratteri derivato<br />
da quello ammesso per gli URI [BLFIM98]. Questo però non esclude la<br />
1 La stringa che la rappresenta è stata sud<strong>di</strong>visa in due righe per motivi tipografici.<br />
199
Il servizio <strong>di</strong> risoluzione dei nomi PRI: gli identificatori persistenti<br />
possibilità che, in sviluppi futuri, la classe <strong>di</strong> stringhe valide per la descrizione<br />
dei PRI venga estesa.<br />
::= "urn:"":"<br />
::= "pri"<br />
::= "/"<br />
::= (dot-number)+<br />
::= (characters)+<br />
::= "."<br />
::= "0" | (+)<br />
::= "1" | "2" | "3" | "4" | "5" |<br />
"6" | "7" | "8" | "9"<br />
::= "0" | "1" | "2" | "3" | "4" |<br />
"5" | "6" | "7" | "8" | "9"<br />
::= <br />
::= ";" | ":" | "=" | "+" | "$" | "," | "-" |<br />
"_" | "." | "!" | "~" | "*" | "’" | "(" |<br />
")" | "a" | "b" | "c" | "d" | "e" | "f" |<br />
"g" | "h" | "i" | "j" | "k" | "l" | "m" |<br />
"n" | "o" | "p" | "q" | "r" | "s" | "t" |<br />
"u" | "v" | "w" | "x" | "y" | "z" | "A" |<br />
"B" | "C" | "D" | "E" | "F" | "G" | "H" |<br />
"I" | "J" | "K" | "L" | "M" | "N" | "O" |<br />
"P" | "Q" | "R" | "S" | "T" | "U" | "V" |<br />
"W" | "X" | "Y" | "Z" | "0" | "1" | "2" |<br />
"3" | "4" | "5" | "6" | "7" | "8" | "9"<br />
Figura 8.3: Sintassi dei PRI in CISA espressa tramite BNF.<br />
La parte ha <strong>un</strong> formato simile a quello delle net-loc<br />
degli URL, con la <strong>di</strong>fferenza che, nel caso in esame, si utilizzano nomi <strong>di</strong> tipo<br />
numerico separati dal p<strong>un</strong>to. La sequenza <strong>di</strong> numeri non in<strong>di</strong>ca il server in<br />
cui viene prodotta l’informazione, ma il server autoritativo per la risoluzione<br />
da PRI ad URL, <strong>di</strong> cui sarà affrontata la <strong>di</strong>scussione più avanti nel capitolo.<br />
Ogni volta che nel sistema viene creata <strong>un</strong>’entità, oltre al nome logico,<br />
viene associato anche <strong>un</strong> nome <strong>di</strong> portata locale anch’esso numerico. Il valore<br />
viene assegnato automaticamente dal sistema della risoluzione dei nomi.<br />
Avendo definito quattro tipologie <strong>di</strong> entità, è possibile sfruttarle per creare<br />
altrettanti sotto-spazi <strong>di</strong> nomi locali. Ciò consente l’eventuale possibilità <strong>di</strong><br />
riutilizzare <strong>un</strong>a parte dell’identificativo locale per entità <strong>di</strong> tipo <strong>di</strong>verso.<br />
200
Il servizio <strong>di</strong> risoluzione dei nomi Logical DNS<br />
Dalla definizione si può notare che effettivamente il PRI è completamente<br />
in<strong>di</strong>pendente dal LRI e dall’URL. Inoltre non è presente ness<strong>un</strong> riferimento<br />
alla locazione fisica, in quanto si assume che in generale il sistema <strong>di</strong><br />
produzione ed il servizio <strong>di</strong> risoluzione siano mantenuti <strong>di</strong>stinti.<br />
Alc<strong>un</strong>i esempi <strong>di</strong> PRI ben formati sono:<br />
urn:pri:1/10 urn:pri:0.0.3/10.2<br />
urn:pri:2.0/qwerty-123 urn:pri:1.1.2/3\(12x)zxcvb<br />
urn:pri:4.7.0.0/4e1243bd22c66e76c2ba9eddc1f91394e57f9f83<br />
8.4 Logical DNS<br />
Gli LRI sono stati introdotti per identificare all’interno dell’ambiente<br />
virtuale le entità logiche Stuff, World, Group e Avatar. Tali identificativi<br />
consentono <strong>di</strong> in<strong>di</strong>care le entità presenti all’interno dell’ambiente virtuale<br />
(Virtual Repository <strong>di</strong> CISA). Il formato degli LRI è definito in modo tale<br />
da essere mnemonico, facilmente usabile dall’utente, riconducibile ad certo<br />
contesto e completamente in<strong>di</strong>pendente dalla locazione fisica delle risorse.<br />
Come mostrato in figura 8.4 è possibile associare più LRI ad <strong>un</strong>o stesso<br />
PRI. Il PRI è <strong>un</strong> identificativo <strong>un</strong>ivoco utilizzato per riferirsi ad <strong>un</strong> nodo<br />
della struttura dell’albero del documento.<br />
LRI LRI<br />
PRI<br />
URL URL URL<br />
Figura 8.4: Associazione tra LRI, PRI ed URL.<br />
Una volta che il PRI è stato creato, rimane associato alla risorsa in<strong>di</strong>pendentemente<br />
dal suo tempo <strong>di</strong> vita: al momento in cui la risorsa abbandona<br />
definitivamente il sistema, il PRI viene com<strong>un</strong>que mantenuto e non è più<br />
riutilizzabile per ness<strong>un</strong> altro scopo.<br />
201
Il servizio <strong>di</strong> risoluzione dei nomi Logical DNS<br />
In analogia al DNS viene introdotto il servizio <strong>di</strong> risoluzione <strong>di</strong> <strong>un</strong> LRI<br />
in PRI: il Logical Domain Name System (LDNS). L’insieme <strong>di</strong> tutti gli LRI<br />
prende il nome <strong>di</strong> Logical Name Space (LNSP). L’insieme <strong>di</strong> nomi è costituito<br />
da due alberi <strong>di</strong>stinti: <strong>un</strong>o per World e Stuff e l’altro per Group e Avatar.<br />
Dal p<strong>un</strong>to <strong>di</strong> vista del meccanismo <strong>di</strong> risoluzione le due strutture sono<br />
trattate in modo equivalente: ciò che è definito per <strong>un</strong>a è facilmente esten<strong>di</strong>bile<br />
all’altra. Viene considerato quin<strong>di</strong> l’albero costituito dai soli World e<br />
Stuff.<br />
Un esempio dell’organizzazione dello spazio dei nomi è riportato in figura<br />
8.5. Ogni nodo dell’albero rappresenta <strong>un</strong> World. All’interno <strong>di</strong> ogni nodo<br />
possono essere contenuti <strong>un</strong>o o più Stuff. Il numero <strong>di</strong> no<strong>di</strong>, così come il<br />
numero <strong>di</strong> Stuff in ogni nodo non è prefissato in quanto la creazione dei nomi<br />
<strong>di</strong>pende dall’attività degli utenti. Rispetto al DNS, dove i no<strong>di</strong> <strong>di</strong> primo<br />
livello risultano predeterminati e <strong>di</strong> numero molto inferiore rispetto ai no<strong>di</strong><br />
degli altri livelli, si ha la possibilità <strong>di</strong> creare <strong>un</strong>a struttura arbitraria.<br />
lri://world1.wrl<br />
lri://world1.wrl/ci10.stf<br />
lri://world1.wrl/ci11.stf<br />
lri://<br />
lri://worldZ.wrl<br />
lri://worldZ.wrl/pa3.stf<br />
lri://worldZ/worldA.wrl<br />
lri://worldZ/worldA.wrl/es2.stf<br />
Figura 8.5: Esempio <strong>di</strong> Logical Name Space.<br />
Il LDNS organizza l’albero rappresentante il LNSP in zone. Si definisce<br />
zona <strong>un</strong> sotto albero del LNSP contenente almeno <strong>un</strong> World e tale che per<br />
ogni World contenuto comprenda anche i relativi Stuff. In figura 8.6 è evidenziato<br />
<strong>un</strong> esempio con <strong>un</strong>a possibile sud<strong>di</strong>visione in cinque zone. In figura 8.7<br />
202
Il servizio <strong>di</strong> risoluzione dei nomi Logical DNS<br />
è rappresentato lo stesso albero collassato in zone. Per motivi grafici non<br />
sono riportati gli eventuali Stuff contenuti nei World.<br />
Si definisce albero <strong>di</strong> zone, quell’albero ottenuto dall’albero del Logical<br />
Name Space attraverso la sostituzione del sotto albero della zona con <strong>un</strong><br />
<strong>un</strong>ico nodo, chiamato nodo <strong>di</strong> zona. Al nuovo albero si applicano tutte le<br />
definizioni <strong>di</strong> <strong>un</strong> qualsiasi altro albero, sostituendo la parola nodo con zona.<br />
Ad esempio le definizioni <strong>di</strong> zona padre e zona figlio sono analoghe a quelle<br />
<strong>di</strong> nodo padre e nodo figlio. La ra<strong>di</strong>ce è detta zona top.<br />
La definizione <strong>di</strong> zona estende quella fornita dalle specifiche del DNS: in<br />
questo caso è necessario associare ai no<strong>di</strong> dell’albero anche gli Stuff che questi<br />
contengono, in modo che anch’essi risultino appartenenti alla zona. World e<br />
domini possono essere considerati equivalenti così come i sotto-domini possono<br />
essere paragonati ai sotto-mon<strong>di</strong>. Infatti è sempre possibile definire <strong>un</strong><br />
dominio (World) che sia contenuto all’interno <strong>di</strong> <strong>un</strong> altro dominio (World),<br />
mentre gli Stuff possono solamente essere contenuti. Separare <strong>un</strong>o Stuff<br />
dal proprio World non fornisce ness<strong>un</strong> vantaggio, anzi si perde il contesto<br />
e l’organizzazione logica dello spazio dei nomi.<br />
Il LDNS è costituito da <strong>un</strong> vasto database <strong>di</strong> nomi <strong>di</strong>stribuito su <strong>un</strong> insieme<br />
<strong>di</strong> server. In analogia al DNS i server contenenti gli LRI, con i relativi<br />
PRI, sono chiamati Logical Name Server (LNS). Ciasc<strong>un</strong> LNS è responsabile<br />
(autoritativo) <strong>di</strong> almeno <strong>un</strong>a zona ovvero <strong>di</strong> <strong>un</strong> nodo dell’albero delle zone.<br />
Si assume quin<strong>di</strong> che esista <strong>un</strong> algoritmo capace <strong>di</strong> <strong>di</strong>stribuire le zone sull’insieme<br />
dei server ed assegnare ad <strong>un</strong> Logical Name Server più <strong>di</strong> <strong>un</strong>a zona da<br />
gestire.<br />
Il LDNS è <strong>un</strong> servizio <strong>di</strong>stribuito e come tale utilizza, quando necessario,<br />
<strong>un</strong>o o più LNS per la risoluzione <strong>di</strong> <strong>un</strong> LRI. Il sistema è provvisto <strong>di</strong> <strong>un</strong> meccanismo<br />
in grado <strong>di</strong> assicurare la risoluzione <strong>di</strong> <strong>un</strong> LRI, qual<strong>un</strong>que sia il LRI<br />
in oggetto e qual<strong>un</strong>que sia il LNS utilizzato (si osservi che l’in<strong>di</strong>rizzo <strong>di</strong> almeno<br />
<strong>un</strong> LNS deve essere noto al client). Il f<strong>un</strong>zionamento è analogo a quello<br />
del DNS dove ogni computer connesso ad Internet utilizza i DNS assegnati<br />
dal proprio fornitore <strong>di</strong> accesso, ma potrebbe (autorizzazioni permettendo)<br />
utilizzare <strong>un</strong>o qual<strong>un</strong>que dei server DNS presenti in rete.<br />
Consideriamo <strong>un</strong>a generica richiesta verso <strong>un</strong>o dei LNS. Si possono verificare<br />
i seguenti casi:<br />
1. il server contattato è in grado <strong>di</strong> risolvere <strong>di</strong>rettamente il nome;<br />
2. il server contattato non è in grado <strong>di</strong> risolvere <strong>di</strong>rettamente il nome.<br />
203
Il servizio <strong>di</strong> risoluzione dei nomi Logical DNS<br />
zona 1<br />
W1<br />
W3 W2<br />
W3<br />
W4<br />
W3 W5 W6<br />
W7 W8<br />
W3 W9<br />
zona 3<br />
W10<br />
zona 2<br />
zona top<br />
zona 4 zona 5<br />
Figura 8.6: Esempio <strong>di</strong> sud<strong>di</strong>visione in zone del LNSP.<br />
W3<br />
zona top<br />
zona 1 zona 4 zona 5<br />
zona 3 zona 2<br />
Figura 8.7: Esempio <strong>di</strong> albero delle zone.<br />
204
Il servizio <strong>di</strong> risoluzione dei nomi Logical DNS<br />
Il primo caso si verifica quando il LRI appartiene alla zona gestita dal<br />
LNS a cui è stata inviata la richiesta, mentre nel secondo caso la risoluzione<br />
necessita <strong>di</strong> <strong>un</strong>’ulteriore richiesta, a partire dal LNS in questione, verso il<br />
server LNS autoritativo sul nome. La richiesta viene sottoposta ad alc<strong>un</strong>i<br />
LNS finché non viene trovato il server autoritativo. Il risultato viene fatto<br />
pervenire al LNS <strong>di</strong> partenza, il quale si occuperà <strong>di</strong> rispondere.<br />
Affinché il proce<strong>di</strong>mento illustrato sia fattibile occorre che ogni LNS sia<br />
dotato <strong>di</strong> <strong>un</strong>a lista <strong>di</strong> riferimenti verso altri LNS. La lista manterrà le informazioni<br />
sulle zone gestite, cioè su <strong>un</strong>a porzione del Logical Name Space.<br />
Ogni LNS per ogni zona gestita deve mantenere i seguenti riferimenti:<br />
• riferimento al LNS autoritativo per la zona top (ra<strong>di</strong>ce);<br />
• riferimento al LNS autoritativo della zona padre del LNS corrente;<br />
• riferimenti ai LNS autoritativi delle zone figlio del LNS corrente.<br />
L’algoritmo per la risoluzione <strong>di</strong> <strong>un</strong> nome è il seguente:<br />
1. si elimina il nome dell’ultima entità presente in del LRI:<br />
partendo dalla fine del nome si eliminano verso sinistra tutti i caratteri<br />
fino ad incontrare il carattere “/” (compreso);<br />
2. si effettua la nuova ricerca nella lista dei riferimenti:<br />
(a) se esiste <strong>un</strong> riferimento ad <strong>un</strong> LNS autoritativo per il LRI, viene<br />
effettuata <strong>un</strong>a richiesta <strong>di</strong> risoluzione del nome <strong>di</strong> partenza (quello<br />
completo) verso tale LNS;<br />
(b) se non esiste ness<strong>un</strong> riferimento si ritorna al passo 1.<br />
Si può notare che nella iterazione al p<strong>un</strong>to 1 è possibile incorrere in lri://<br />
che rappresenta l’Universe del Logical Name Space. Ogni Logical Name Server<br />
contiene nella propria lista <strong>un</strong> riferimento relativo al server autoritativo<br />
alla zona top.<br />
In conformità allo standard XDI/XRI [Fra05], il meccanismo <strong>di</strong> risoluzione<br />
prevede due modalità operative: con e senza Look-Ahead. Tali modalità<br />
<strong>di</strong>fferiscono nel metodo col il quale viene portato a termine il p<strong>un</strong>to 2.a:<br />
• senza Look-Ahead ogni LNS interpellato propaga la richiesta verso il<br />
server seguente mettendosi in attesa della risposta. In questo modo la<br />
richiesta si propaga attraverso <strong>un</strong>a sequenza <strong>di</strong> LNS e la risposta segue<br />
il cammino inverso, come mostrato in figura 8.8;<br />
205
Il servizio <strong>di</strong> risoluzione dei nomi Logical DNS<br />
Figura 8.8: Risoluzione senza Look-Ahead.<br />
• con Look-Ahead ogni LNS interpellato, anziché inoltrare <strong>di</strong>rettamente<br />
la richiesta al server seguente, invia all’elemento che lo precede l’in<strong>di</strong>rizzo<br />
<strong>di</strong> tale server. In questo modo esiste <strong>un</strong> elemento centrale che<br />
effettua le richieste ai server <strong>di</strong> interesse, come mostrato in figura 8.9.<br />
Figura 8.9: Risoluzione con Look-Ahead.<br />
Per comprendere come sono strutturate le liste e l’algoritmo <strong>di</strong> risoluzio-<br />
206
Il servizio <strong>di</strong> risoluzione dei nomi Logical DNS<br />
ne è utile considerare la figura 8.7 e procedere con <strong>un</strong> esempio. Prima <strong>di</strong><br />
tutto devono essere definite le liste in accordo alle regole precedentemente<br />
en<strong>un</strong>ciate. Inoltre si supponga che:<br />
• la zona top, la zona 1, la zona 4 e la zona 5 siano gestite da Logical<br />
Name Server <strong>di</strong>stinti a cui, rispettivamente, siano assegnati i nomi <strong>di</strong><br />
LNS-top, LNS-1, LNS-4, LNS-5;<br />
• la zona 2 e la zona 3 siano gestite da <strong>un</strong> <strong>un</strong>ico LNS (LNS-2,3).<br />
Per cui le liste assumono la seguente forma:<br />
1. LNS-top.<br />
2. LNS-1.<br />
3. LNS-4.<br />
4. LNS-5.<br />
• Riferimenti ai LNS autoritativi per le zone figlio:<br />
– riferimento a LNS-1;<br />
– riferimento a LNS-4;<br />
– riferimento a LNS-5.<br />
• Riferimenti ai LNS autoritativi per le zone figlio:<br />
– riferimento al LNS-2,3.<br />
• Riferimento al LNS autoritativo per la zona padre:<br />
– riferimento al LNS-top.<br />
• Riferimento al LNS autoritativo per la zona top:<br />
– riferimento al LNS-top.<br />
• Riferimento al LNS autoritativo per la zona padre:<br />
– riferimento al LNS-top.<br />
• Riferimento al LNS autoritativo per la zona top:<br />
– riferimento al LNS-top.<br />
• Riferimento al LNS autoritativo per la zona padre:<br />
207
Il servizio <strong>di</strong> risoluzione dei nomi Logical DNS<br />
– riferimento al LNS-top;<br />
• Riferimento al LNS autoritativo per la zona top:<br />
5. LNS-2,3.<br />
– riferimento al LNS-top;<br />
• Riferimento al LNS autoritativo per la zona padre:<br />
– riferimento al LNS-1.<br />
• Riferimento al LNS autoritativo per la zona top:<br />
– riferimento al LNS-top.<br />
Si supponga che il LRI da risolvere sia:<br />
lri://world1/world4/world8.wrl<br />
e che la richiesta venga rivolta a LNS-2,3. LNS-2,3 è autoritativo delle zone 2<br />
e 3, che ovviamente riguardano World <strong>di</strong>versi da quelli espressi nel LRI preso<br />
in esempio.<br />
Sotto queste ipotesi, LNS-2,3 verifica che lri://world1/world4 non è <strong>di</strong><br />
sua competenza, per cui viene inviata <strong>un</strong>a richiesta verso LNS-1 per risolvere<br />
lri://world1/world4/world8.<br />
Da questo p<strong>un</strong>to in poi le modalità con e senza Look-Ahead procedono<br />
in modo <strong>di</strong>verso:<br />
• Senza Look-Ahead. LNS-1 non è autoritativo, quin<strong>di</strong> inoltra la richiesta<br />
a LNS-top. Analogamente LNS-top richiede la risoluzione a LNS-5.<br />
LNS-5 è autoritativo sul LRI, per cui la risoluzione avviene e la risposta<br />
ripercorre il cammino inverso:<br />
LNS-5 → LNS-top → LNS-1 → LNS-2,3 → Client.<br />
• Con Look-Ahead: LNS-1 non è autoritativo quin<strong>di</strong> invia a LNS-2,3<br />
l’in<strong>di</strong>rizzo <strong>di</strong> LNS-top. LNS-2,3 inoltra la richiesta completa a LNS-top.<br />
LNS-top non è autoritativo quin<strong>di</strong> invia a LNS-2,3 l’in<strong>di</strong>rizzo <strong>di</strong> LNS-5.<br />
LNS-2,3 inoltra la richiesta completa a LNS-5 il quale è autoritativo sul<br />
LRI e fornisce a LNS-2,3 la risoluzione.<br />
In figura 8.10 sono riportati i cammini or<strong>di</strong>nati delle richieste e delle<br />
risposte nei due casi.<br />
208
Il servizio <strong>di</strong> risoluzione dei nomi Logical DNS<br />
Senza Look-Ahead<br />
Richiesta<br />
Risposta<br />
Con Look-Ahead<br />
Richiesta<br />
Risposta<br />
2 3<br />
1<br />
1<br />
5<br />
2<br />
6<br />
LNS -top<br />
LNS -1 LNS -5<br />
3<br />
4<br />
LNS -2,3<br />
Figura 8.10: Richieste ricorsive per la risoluzione.<br />
4<br />
5<br />
6<br />
209
Il servizio <strong>di</strong> risoluzione dei nomi Logical DNS<br />
8.4.1 Supporto alla navigazione<br />
Il meccanismo <strong>di</strong> risoluzione è efficace nell’ipotesi in cui l’utente conosca<br />
esattamente il nome della risorsa alla quale intende accedere. Questo scenario<br />
si presenta in varie circostanze considerando che è l’utente ad assegnare<br />
i nomi e che può farlo seguendo delle proprie convenzioni che possono essere<br />
applicate in qual<strong>un</strong>que momento anche per risalire al nome della risorsa voluta.<br />
Allo stesso modo niente vieta <strong>di</strong> ipotizzare che l’utente salvi (ad esempio<br />
in <strong>un</strong> documento D3IM <strong>di</strong> sua proprietà) i nomi delle risorse <strong>di</strong> interesse. Affidare<br />
all’utente l’onere della completa gestione dei nomi però può risultare<br />
<strong>un</strong>’operazione complessa e oltretutto non permette <strong>di</strong> sfruttare al meglio le<br />
capacità del sistema gerarchico dei nomi logici.<br />
Per supportare l’utente nella navigazione dello spazio dei nomi il sistema<br />
fornisce la possibilità <strong>di</strong> effettuare <strong>un</strong>a richiesta <strong>di</strong> “appartenenza a” su <strong>un</strong><br />
world che, come risultato, fornisce la lista degli in<strong>di</strong>rizzi <strong>di</strong> tutti gli elementi<br />
in esso contenuti. Con questo meccanismo la navigazione nello spazio dei<br />
nomi logici risulta del tutto equivalente a quella su file system.<br />
Si osservi che la complessità <strong>di</strong> questo tipo <strong>di</strong> richiesta è poco superiore a<br />
quella <strong>di</strong> <strong>un</strong>a richiesta <strong>di</strong> risoluzione. Una volta effettuata la richiesta ad <strong>un</strong><br />
server qual<strong>un</strong>que l’algoritmo <strong>di</strong> ricerca del server autoritativo sul word è lo<br />
stesso rispetto al caso della risoluzione. Tale server memorizza per ipotesi la<br />
lista degli in<strong>di</strong>rizzi relativi a tutti gli elementi contenuti nel world in esame<br />
e può fornirla al richiedente come avviene per la risposta ad <strong>un</strong>a generica<br />
richiesta <strong>di</strong> risoluzione.<br />
La complessità può essere superiore in quanto a priori non sono state fatte<br />
ipotesi sul numero <strong>di</strong> elementi che possono essere contenuti in <strong>un</strong> world, ma<br />
possono essere previsti dei meccanismi finalizzati a limitare la <strong>di</strong>mensione<br />
della lista che i vari server devono manipolare.<br />
8.4.2 Espansione del Logical Name Space<br />
Il sistema è composto da <strong>un</strong> certo numero <strong>di</strong> server per la risoluzione,<br />
ciasc<strong>un</strong>o dei quali ha in carico <strong>un</strong> certo numero <strong>di</strong> zone. Il p<strong>un</strong>to critico del<br />
servizio <strong>di</strong> risoluzione è la creazione <strong>di</strong> nuove entità World e Group in quanto<br />
tale operazione determina l’espansione e la gerarchia del Name Space.<br />
A sua volta la sud<strong>di</strong>visione in zone del Name Space consente <strong>di</strong> assegnare<br />
l’autorità sui sotto alberi ad opport<strong>un</strong>i server LNS. Essendo gli Stuff e gli<br />
210
Il servizio <strong>di</strong> risoluzione dei nomi Logical DNS<br />
Avatar fortemente legati al World ed al Group a cui appartengono, dovranno<br />
essere gestiti dal LNS autoritativo su quel World e Group.<br />
Il proce<strong>di</strong>mento che verrà illustrato per i World è facilmente esten<strong>di</strong>bile<br />
ai Group, ed ulteriormente semplificato nel caso della creazione <strong>di</strong> Stuff e<br />
Avatar, grazie alle precedenti considerazioni.<br />
È importante premettere che solo l’Avatar con gli opport<strong>un</strong>i permessi<br />
potrà creare <strong>un</strong> nuovo World all’interno <strong>di</strong> <strong>un</strong>o già esistente. Ovviamente si<br />
assume che l’Universe (la ra<strong>di</strong>ce del Name Space) esista ed abbia già <strong>un</strong> LNS<br />
che la risolve.<br />
Per semplicità si consideri nuovamente la figura 8.6 e si supponga che esista<br />
lri://W1/W4/W8 entro cui si vuole creare il World lri://W1/W4/W8/W11.<br />
Affinché l’operazione abbia successo deve:<br />
• essere creata e memorizzata l’entità;<br />
• essere aggiornato il database dei nomi.<br />
Una volta che l’entità lri://W1/W4/W8/W11 è stata creata, deve essere resa<br />
in<strong>di</strong>rizzabile, così che la sua esistenza risulti effettiva (solo successivamente è<br />
in<strong>di</strong>viduabile e quin<strong>di</strong> da ritenersi esistente), chiedendo al sistema LDNS la<br />
gestione del nome.<br />
Le conseguenze possibili, relative alla gestione della porzione <strong>di</strong> LNSP che<br />
inizia da lri://W1/W4/W8/W11, sono le seguenti:<br />
• estensione <strong>di</strong> <strong>un</strong>a zona: lri://W1/W4/W8/W11 entra nella zona 5, per<br />
cui sarà gestito da LNS-5;<br />
• partizione <strong>di</strong> <strong>un</strong>a zona esistente: si crea la zona 6 con la relativa<br />
assegnazione ad <strong>un</strong> LNS.<br />
Si può osservare che, dal p<strong>un</strong>to <strong>di</strong> vista dell’Avatar creatore, tutto dovrebbe<br />
semplicemente ridursi ad <strong>un</strong>a richiesta al servizio LDNS:<br />
Add-New-World(lri://W1/W4/W8/W11)<br />
con risposta positiva o <strong>di</strong> errore.<br />
Nel caso in cui debba essere creata <strong>un</strong>a nuova zona, tra i vari meccanismi<br />
mascherati all’Avatar, interni al sistema LDNS, vi sarà quello che stabilisce<br />
quale server LNS gestirà la nuova zona. Il principale server can<strong>di</strong>dato per<br />
l’autorità è quello, tra i <strong>di</strong>sponibili, che risulterà più “vicino” alla sorgente <strong>di</strong><br />
informazione in oggetto.<br />
211
Il servizio <strong>di</strong> risoluzione dei nomi Logical DNS<br />
La <strong>di</strong>sponibilità <strong>di</strong> <strong>un</strong> server può essere stabilita impostando soglie sul<br />
carico <strong>di</strong> lavoro sopportato: <strong>un</strong> compromesso tra numero <strong>di</strong> accessi consentiti<br />
per <strong>un</strong>ità <strong>di</strong> tempo e massimo numero <strong>di</strong> entità risolvibili. Il concetto <strong>di</strong><br />
vicinanza non è tanto riferito alla <strong>di</strong>stanza geografica, quanto alla capacità<br />
dei collegamenti. In <strong>un</strong> sistema <strong>di</strong> com<strong>un</strong>icazione la banda <strong>di</strong>sponibile e il<br />
tempo <strong>di</strong> ro<strong>un</strong>d-trip [KR03] giocano <strong>un</strong> ruolo non in<strong>di</strong>fferente nell’usabilità<br />
delle applicazioni <strong>di</strong> rete.<br />
Aggiornamento del database<br />
Ogni server LNS ha nella sua configurazione i riferimenti ai server figlio,<br />
e questi conoscono almeno l’in<strong>di</strong>rizzo del LNS server autoritativo sulla ra<strong>di</strong>ce<br />
dell’albero del Logical Name Space; a partire da queste informazioni è possibile,<br />
man mano che l’albero dei LRI si espande, coprirlo con <strong>un</strong> processo <strong>di</strong><br />
auto-configurazione.<br />
Volendo menzionare <strong>un</strong> esempio, nel momento in cui <strong>un</strong> Avatar richiede<br />
Add-New-World(lri://W1/W4/W8/W11), interagendo con <strong>un</strong> LDNS, dà inizio<br />
ad <strong>un</strong>a catena <strong>di</strong> richieste che, in <strong>un</strong> numero finito <strong>di</strong> passi, incorre nel server<br />
autoritativo <strong>di</strong> lri://W1/W4/W8 (in questo caso LNS-5). LNS-5 può accollarsi<br />
la gestione del nuovo World oppure delegarla ad <strong>un</strong> server <strong>di</strong> più basso livello<br />
nella gerarchia.<br />
All’inizio lo spazio dei nomi è vuoto ovvero il LNSP è costituito dalla<br />
sola ra<strong>di</strong>ce ed esiste <strong>un</strong> solo server LNS capace <strong>di</strong> risolvere in PRI gli LRI<br />
del tipo lri://something.ext. Complessivamente nel sistema sono già stati<br />
installati altri server LNS, che però non hanno ancora in carico ness<strong>un</strong>a zona.<br />
Quando <strong>un</strong> Avatar desidera creare <strong>un</strong> nuovo World (W_new), deve in<strong>di</strong>care<br />
il World (W_parent) destinato a contenerlo e richiedere la registrazione ad<br />
<strong>un</strong>o dei server LNS. Una volta identificato ricorsivamente il LNS che ha il<br />
compito <strong>di</strong> risolverlo, questo deve:<br />
• mantenere il PRI per la risoluzione;<br />
• com<strong>un</strong>icare al LNS autoritativo su W_parent che lui è autoritativo per<br />
il nuovo World (W_new);<br />
• rispondere alla richiesta <strong>di</strong> creazione.<br />
Procedendo <strong>di</strong> questo passo, si popola l’albero dei nomi e vengono configurati<br />
automaticamente tutti i server. Il proce<strong>di</strong>mento garantisce la <strong>di</strong>stribuzione<br />
del database dei nomi e la consistenza della risoluzione.<br />
212
Il servizio <strong>di</strong> risoluzione dei nomi Localization Service<br />
8.4.3 Proprietà<br />
Il Logical Domain Name System, per come è stato definito e per la forte<br />
analogia con il DNS, può vantare le seguenti proprietà:<br />
• garantisce la risoluzione <strong>di</strong> tutto il Logical Name Space;<br />
• è facilmente esten<strong>di</strong>bile;<br />
• è scalabile;<br />
• è facilmente aggiornabile;<br />
• è rapido nelle mo<strong>di</strong>fiche al LNSP.<br />
Alle precedenti proprietà si può aggi<strong>un</strong>gere la tolleranza ai guasti ridondando<br />
gli apparati costituenti il sistema. Si possono introdurre, così come<br />
avviene per il DNS, dei server LNS secondari. In questo modo i server si<br />
classificano non solo in base al livello a cui appartengono, ma anche alla<br />
<strong>di</strong>stinzione tra server primari e secondari.<br />
È importante osservare che la scalabilità <strong>di</strong> LDNS è <strong>di</strong> minore portata<br />
rispetto a quella del DNS, in quanto il primo permette <strong>un</strong>a totale libertà<br />
nella creazione dei no<strong>di</strong> già a partire dal primo livello. Si ricorda che nel<br />
DNS i no<strong>di</strong> <strong>di</strong> primo livello sono prefissati e limitati nel numero. Tale libertà<br />
potrebbe portare ad <strong>un</strong>a crescita non efficiente dell’albero, ma d’altra parte<br />
è <strong>un</strong> eventuale rischio che vale la pena correre per consentire <strong>un</strong>a gestione<br />
più rapida nella creazione e nella mo<strong>di</strong>fica del LNSP.<br />
8.5 Localization Service<br />
Nel precedente paragrafo è stato affrontato il problema della risoluzione <strong>di</strong><br />
<strong>un</strong> LRI in PRI. Ora è necessario definire <strong>un</strong> servizio che consenta la risoluzione<br />
<strong>di</strong> PRI in URL: tale servizio prende il nome <strong>di</strong> Localization Service (LS).<br />
Al fine <strong>di</strong> introdurre l’architettura <strong>di</strong> LS, è conveniente fare riferimento<br />
al formato dei PRI definito in figura 8.3. La parte è<br />
simile a quella delle net-loc degli URL, con la <strong>di</strong>fferenza che i nomi sono<br />
stringhe <strong>di</strong> numeri separate da <strong>un</strong> p<strong>un</strong>to.<br />
La scelta del formato consente <strong>di</strong> organizzare il servizio LS attraverso <strong>un</strong>a<br />
struttura ad albero come quella mostrata nell’esempio <strong>di</strong> figura 8.11. Ciò è<br />
efficace per ottenere la massima espan<strong>di</strong>bilità, scalabilità e garanzia <strong>di</strong> <strong>un</strong>a<br />
213
Il servizio <strong>di</strong> risoluzione dei nomi Localization Service<br />
risoluzione <strong>di</strong>stribuita <strong>di</strong> tutti gli identificativi in URL, in modo del tutto<br />
analogo al DNS.<br />
0<br />
0.0 1.0<br />
0.0.0<br />
0.1.0<br />
1<br />
0.1<br />
Figura 8.11: Esempio <strong>di</strong> LS.<br />
Ogni server LS è autoritativo per tutti i PRI che hanno come parte<br />
il nome del server stesso. La prima cifra a partire<br />
da destra rappresenta la ra<strong>di</strong>ce (server top) della gerarchia dei server LS. Le<br />
cifre successive, da destra verso sinistra, in<strong>di</strong>cano i server <strong>di</strong> livello inferiore.<br />
Analogamente al LDNS, anche per il Localization Service le richieste possono<br />
essere effettuate ad <strong>un</strong> qualsiasi server. Affinché il processo <strong>di</strong> risoluzione<br />
dei PRI vada a buon fine ogni server LS top deve mantenere <strong>un</strong>a lista <strong>di</strong><br />
riferimento verso gli altri server top.<br />
Analogamente a LDNS devono essere definite delle liste <strong>di</strong> riferimenti<br />
contenenti:<br />
• il riferimento al server padre;<br />
• i riferimenti ai server figlio;<br />
• il riferimento al server top.<br />
Nel caso in cui il server LS interrogato non sia autoritativo sui PRI richiesti<br />
è possibile, grazie ai riferimenti nelle liste, raggi<strong>un</strong>gere il server LS<br />
autoritativo. La catena della risoluzione è simile a quella presentata per il<br />
LDNS in figura 8.10, dove però i server in gioco sono LS.<br />
Le considerazioni ed il confronto tra LS e DNS sono quasi equivalenti a<br />
quelle già esposte riguardo a LDNS e DNS. Nel caso LS la scalabilità del<br />
sistema è esattamente paragonabile a quella del DNS, visto che è possibile<br />
214
Il servizio <strong>di</strong> risoluzione dei nomi Risoluzione inversa<br />
affidare allo stesso sistema la decisione su quanti nuovi server ra<strong>di</strong>ce creare<br />
e quando crearli. Inoltre la procedura <strong>di</strong> aggiornamento risulta semplificata,<br />
dato che non esiste il concetto <strong>di</strong> zona. La <strong>di</strong>stribuzione può essere calcolata<br />
per ottimizzare la ricerca e l’aggiornamento.<br />
8.6 Risoluzione inversa<br />
La risoluzione inversa deve essere tale da consentire la risalita da <strong>un</strong> URL<br />
ai corretti LRI.<br />
Anche in questo caso il meccanismo deve essere sud<strong>di</strong>viso in due sta<strong>di</strong><br />
(figura 8.12):<br />
1. risoluzione inversa da URL a PRI;<br />
2. risoluzione inversa da PRI a LRI.<br />
LRI LRI<br />
PRI<br />
URL URL URL<br />
Figura 8.12: Schema per la risoluzione inversa.<br />
Riferendosi allo spazio dei nomi in generale, al fine <strong>di</strong> effettuare la risoluzione<br />
inversa, può risultare conveniente adottare lo stesso principio del<br />
reverse lookup del DNS, in quanto tale tecnica:<br />
• è efficace;<br />
• sfrutta l’infrastruttura utilizzata per la risoluzione <strong>di</strong>retta.<br />
Nel DNS gli IP sono riformulati a livello logico sotto <strong>un</strong>o speciale dominio,<br />
chiamato in-addr.arpa. Il reverse lookup viene visto come <strong>un</strong>a risoluzione<br />
215
Il servizio <strong>di</strong> risoluzione dei nomi Risoluzione inversa<br />
<strong>di</strong>retta. Supponendo che <strong>un</strong> client voglia conoscere <strong>un</strong> hostname associato a<br />
192.0.2.25 formula <strong>un</strong>a richiesta <strong>di</strong> risoluzione <strong>di</strong>retta <strong>di</strong> 25.2.0.192.inaddr.arpa.<br />
Il meccanismo, riferito all’esempio <strong>di</strong> conversione IP in hostname, è il<br />
seguente:<br />
• il resolver DNS inverte la notazione decimale dell’IP e l’aggi<strong>un</strong>ge a<br />
.in-addr.arpa: 25.2.0.192.in-addr.arpa;<br />
• il resolver cerca il record per 25.2.0.192.in-addr.arpa;<br />
– il resolver DNS chiede la risoluzione <strong>di</strong> 25.2.0.192.in-addr.arpa<br />
al server ra<strong>di</strong>ce;<br />
– il server ra<strong>di</strong>ce formula la richiesta al server autoritativo sulla<br />
classe A, la quale copre gli IP che iniziano per 192 (192.inaddr.arpa);<br />
– la catena <strong>di</strong> richieste prosegue fino a quando non viene raggi<strong>un</strong>to<br />
il server autoritativo su 25.0.2.192.in-addr.arpa;<br />
– il server autoritativo risponde con l’hostname.<br />
Per quanto concerne la risoluzione da URL a PRI questo metodo non è<br />
<strong>di</strong>rettamente attuabile a causa del formato dei nomi in esame, ma, relativamente<br />
all’architettura CISA, esiste <strong>un</strong> altro metodo molto efficiente che<br />
permette <strong>di</strong> ottenere il PRI richiesto senza chiamare in causa i server <strong>di</strong> risoluzione.<br />
Noto l’URL è infatti sufficiente accedere alla replica dell’informazione<br />
che, se è <strong>un</strong> elemento definito nello spazio delle informazioni D3IM ha,<br />
al proprio interno memorizzato per ipotesi, l’in<strong>di</strong>rizzo PRI che la identifica<br />
<strong>un</strong>ivocamente.<br />
Noto l’URL è quin<strong>di</strong> sufficiente accedere alla replica ed estrarre l’in<strong>di</strong>rizzo<br />
richiesto.<br />
Una volta ottenuto il PRI deve avvenire il secondo passo della risoluzione<br />
inversa per determinare gli LRI. Le associazioni “” vengono<br />
memorizzate nel server LS autoritativo sul PRI in modo equivalente alle associazioni<br />
“” utilizzate per la risoluzione <strong>di</strong>retta. In questo modo<br />
l’algoritmo <strong>di</strong> risoluzione inversa da PRI in LRI è equivalente a quello descritto<br />
per la risoluzione <strong>di</strong>retta; l’<strong>un</strong>ica <strong>di</strong>fferenza consiste nel fatto che il server<br />
autoritativo sul PRI reperisce <strong>un</strong>a tipologia <strong>di</strong> associazioni anziché l’altra.<br />
216
Il servizio <strong>di</strong> risoluzione dei nomi Risoluzione inversa<br />
Un problema <strong>di</strong> cui occorre prendere atto è che deve essere garantita la<br />
consistenza fra le associazioni “”, presenti nei vari server LDNS<br />
autoritativi sugli LRI associati al PRI, e quelle “” presenti sul<br />
server LS autoritativo sul PRI.<br />
Questa osservazione è utile per introdurre <strong>un</strong> secondo problema che deve<br />
essere affrontato e risolto. Gli spazi dei nomi sono stati definiti in modo<br />
da garantire la scalabilità del sistema al crescere del numero degli stessi. In<br />
particolare possono essere associati <strong>un</strong> numero arbitrario <strong>di</strong> LRI ad <strong>un</strong> PRI<br />
in quanto è possibile ripartire l’onere della loro risoluzione su <strong>di</strong> <strong>un</strong> numero<br />
alto a piacere <strong>di</strong> server LDSN. Anche il numero <strong>di</strong> PRI esistenti nel sistema<br />
può crescere, a patto <strong>di</strong> far crescere in modo equivalente il numero <strong>di</strong> server<br />
LS per la relativa risoluzione in URL.<br />
Si osservi che il numero <strong>di</strong> URL associato ad <strong>un</strong> determinato PRI non<br />
può crescere a piacere in quanto tali URL, per le ipotesi operative fatte,<br />
sono tutti memorizzati nel server LS autoritativo sul PRI. La capacità <strong>di</strong><br />
memorizzazione, la potenza computazionale e la velocità <strong>di</strong> connessione alla<br />
rete <strong>di</strong> <strong>un</strong> <strong>un</strong>ico sistema non possono essere rese gran<strong>di</strong> a piacere a causa<br />
dei limiti tecnologici esistenti. Nel caso specifico questo non rappresenta <strong>un</strong><br />
problema in quanto il numero <strong>di</strong> URL associate ad <strong>un</strong> PRI equivale al numero<br />
<strong>di</strong> repliche dell’informazione identificata da tale PRI e pertanto, anche se non<br />
è corretto stabilire <strong>un</strong> valore massimo ammissibile a priori, questa grandezza<br />
può essere tenuta sotto controllo.<br />
Viceversa il numero <strong>di</strong> LRI associati ad <strong>un</strong> PRI è <strong>un</strong>a grandezza sulla<br />
quale non può essere fatta alc<strong>un</strong>a ipotesi e che può essere quin<strong>di</strong> arbitrariamente<br />
grande. In riferimento al problema introdotto in precedenza il numero<br />
<strong>di</strong> associazioni “” presenti nel server LS autoritativo sul PRI può<br />
essere quin<strong>di</strong> arbitrariamente grande vanificando tutte le ipotesi <strong>di</strong> scalabilità<br />
dello spazio dei nomi.<br />
Per minimizzare l’impatto <strong>di</strong> questo inconveniente sono state in<strong>di</strong>viduate<br />
due strade alternative che eventualmente possono essere percorse entrambe:<br />
• sud<strong>di</strong>visione degli LRI in due categorie:<br />
– LRI risolvibili inversamente partendo dal PRI associato;<br />
– LRI non risolvibili inversamente partendo dal PRI associato;<br />
• risoluzione inversa iterativa.<br />
217
Il servizio <strong>di</strong> risoluzione dei nomi Risoluzione inversa<br />
La prima soluzione prevede la definizione <strong>di</strong> due tipologie <strong>di</strong> nomi logici<br />
in modo da poter escludere tutti quei nomi per i quali non c’è interesse ad<br />
effettuare la risoluzione inversa. In questo modo si riduce il numero assoluto<br />
<strong>di</strong> elementi da trattare, ma non è com<strong>un</strong>que possibile dare delle garanzie sul<br />
numero <strong>di</strong> elementi per i quali la risoluzione inversa è necessaria, pertanto il<br />
problema non può considerarsi risolto.<br />
La seconda soluzione permette <strong>di</strong> introdurre <strong>un</strong> limite superiore al numero<br />
<strong>di</strong> coppie “” presenti in ogni server LS. Il nome “risoluzione<br />
inversa iterativa” deriva dal fatto che per portare a termine l’operazione il<br />
client deve effettuare iterativamente <strong>un</strong> certo numero <strong>di</strong> richieste. Per ogni<br />
richiesta il server LS autoritativo sul PRI da risolvere è <strong>di</strong>verso. In questo<br />
modo il carico <strong>di</strong> lavoro e la capacità <strong>di</strong> memorizzazione possono essere <strong>di</strong>stribuiti<br />
su <strong>un</strong> numero <strong>di</strong> server sufficientemente elevato al fine <strong>di</strong> garantire<br />
l’efficacia e l’efficienza dell’operazione.<br />
Vista delle righe <strong>di</strong> interesse<br />
della tabella con le associazioni<br />
“” nel server LS<br />
autoritativo su “0”<br />
PRI LRI o Partizioni<br />
urn:pri:0/da_risolvere<br />
lri://1<br />
urn:pri:0/da_risolvere lri://2<br />
urn:pri:0/da_risolvere lri://3<br />
urn:pri:0/da_risolvere urn:pri:1/partizione2<br />
Vista delle righe <strong>di</strong> interesse<br />
della tabella con le associazioni<br />
“” nel server LS<br />
autoritativo su “1”<br />
PRI LRI o Partizioni<br />
urn:pri:1/partizione2<br />
lri://4<br />
urn:pri:1/partizione2 lri://5<br />
urn:pri:1/partizione2 urn:pri:2/partizione3<br />
urn:pri:1/partizione2 urn:pri:3/partizione4<br />
Figura 8.13: Tabelle necessarie per la risoluzione inversa iterativa.<br />
Il meccanismo sul quale si basa la risoluzione inversa iterativa è molto<br />
semplice. L’insieme <strong>di</strong> LRI associati al PRI <strong>di</strong> interesse viene partizionato in<br />
<strong>un</strong> numero sufficientemente grande <strong>di</strong> sottoinsiemi i quali vengono <strong>di</strong>stribuiti<br />
su server LS <strong>di</strong>stinti. Il client effettua <strong>un</strong> richiesta <strong>di</strong> risoluzione inversa per<br />
ogni partizione. Ad ogni sottoinsieme viene assegnato <strong>un</strong> in<strong>di</strong>rizzo PRI che<br />
218
Il servizio <strong>di</strong> risoluzione dei nomi Risoluzione inversa<br />
per il primo sottoinsieme coincide con il PRI <strong>di</strong> cui è richiesta la risoluzione<br />
inversa.<br />
Quest’ultima ipotesi, se il numero <strong>di</strong> associazioni “” è sufficientemente<br />
basso, permette <strong>di</strong> ricondurre il caso della risoluzione inversa<br />
iterativa al caso più semplice introdotto all’inizio <strong>di</strong> questo paragrafo.<br />
In quest’ultimo caso la risoluzione avviene nel modo convenzionale: il<br />
client effettua la richiesta sul PRI <strong>di</strong> interesse e si vede recapitare l’insieme<br />
completo <strong>di</strong> LRI associati.<br />
Supponendo invece <strong>di</strong> superare il numero massimo <strong>di</strong> coppie gestibili da<br />
<strong>un</strong> <strong>un</strong>ico server LS, entra in gioco il meccanismo <strong>di</strong> partizionamento. Viene<br />
generato <strong>un</strong> nuovo PRI e viene associato ad esso il gruppo <strong>di</strong> LRI in eccesso.<br />
In riferimento alla figura 8.13 il PRI <strong>di</strong> cui è richiesta la risoluzione inversa<br />
è urn:pri:0/da_risolvere. Il client effettua la richiesta <strong>di</strong> risoluzione che,<br />
tramite i medesimi meccanismi descritti per la risoluzione <strong>di</strong>retta, gi<strong>un</strong>ge<br />
al server LS autoritativo sul PRI. Il server restituisce la lista <strong>di</strong> elementi<br />
associati al PRI (nello specifico sono tre LRI: lri://1, lri://2 e lri://3)<br />
e l’insieme <strong>di</strong> PRI che identificano le partizioni note al server LS (in questo<br />
caso urn:pri:1/partizione2).<br />
Il client procede iterativamente con la risoluzione dei PRI che identificano<br />
le varie partizioni e, nell’esempio, richiede la risoluzione dell’in<strong>di</strong>rizzo ricevuto<br />
con la risposta al passo precedente: urn:pri:1/partizione2. Siccome il<br />
server autoritativo in questo caso è 1, l’algoritmo è effettivamente <strong>di</strong>stribuito.<br />
La risposta a questa richiesta <strong>di</strong> risoluzione contiene altri due in<strong>di</strong>rizzi LRI<br />
da associare al PRI iniziale (lri://4 e lri://5) e gli in<strong>di</strong>rizzi <strong>di</strong> altre due<br />
partizioni.<br />
Si osservi che tramite <strong>un</strong>a scelta oculata dei PRI delle partizioni è possibile<br />
realizzare <strong>un</strong> albero. Partendo da <strong>un</strong>o specifico PRI questo aspetto<br />
mette il client nelle con<strong>di</strong>zioni <strong>di</strong> in<strong>di</strong>viduare, se esiste, <strong>un</strong> particolare in<strong>di</strong>rizzo<br />
LRI associato a tale PRI con <strong>un</strong> numero <strong>di</strong> iterazioni che cresce in<br />
modo logaritmico rispetto al numero complessivo <strong>di</strong> LRI associati al PRI <strong>di</strong><br />
partenza.<br />
Questo è possibile assegnando i nomi alle partizioni in modo coerente<br />
al loro contenuto. Per esempio si può pensare <strong>di</strong> creare <strong>un</strong> primo livello<br />
<strong>di</strong> partizioni costituito da due sottoinsiemi identificati rispettivamente dai<br />
seguenti PRI:<br />
• urn:pri:1/partizione_0-9A-M;<br />
219
Il servizio <strong>di</strong> risoluzione dei nomi Risoluzione inversa<br />
• urn:pri:1/partizione_N-Z;<br />
contenenti tutti gli LRI il cui inizia con <strong>un</strong> carattere nell’intervallo<br />
A-M e numeri o N-Z rispettivamente. In questo esempio gli<br />
LRI:<br />
• lri://dati/...;<br />
• lri://ANNI/...;<br />
• lri://123/...;<br />
appartengono alla prima partizione, mentre:<br />
• lri://Utenti/...;<br />
• lri://zn5n2f20th1/...)<br />
appartengono alla seconda.<br />
Procedendo ricorsivamente è possibile sud<strong>di</strong>videre ulteriormente le partizioni<br />
in sotto partizioni, per la prima ad esempio:<br />
• urn:pri:1/sottopartizione_0-9;<br />
• urn:pri:1/sottopartizione_A;<br />
• urn:pri:1/sottopartizione_B;<br />
• urn:pri:1/sottopartizione_...;<br />
• urn:pri:1/sottopartizione_M)<br />
e così via.<br />
Si noti che il server autoritativo relativo ad ogni partizione è sempre<br />
1. Questo perché, se il carico lo permette, non è necessario sud<strong>di</strong>videre le<br />
partizioni fra server LS <strong>di</strong>stinti. Nell’esempio i primi due livelli dell’albero<br />
delle partizioni sono mantenuti sullo stesso server LS mentre i sotto livelli<br />
successivi potrebbero essere inseriti in server <strong>di</strong>versi.<br />
La verifica dell’esistenza <strong>di</strong> LRI associati ad <strong>un</strong>o specifico PRI può risultare<br />
particolarmente utile in <strong>un</strong>’ottica <strong>di</strong> salvaguar<strong>di</strong>a della privacy e dell’equo<br />
trattamento dei dati personali in quanto è <strong>un</strong>o strumento che permette all’entità,<br />
a cui i dati sensibili sono riferiti, <strong>di</strong> controllare chi li gestisce (operazione<br />
che avviene in<strong>di</strong>rettamente conoscendo i nomi logici) ed eventualmente<br />
<strong>di</strong> in<strong>di</strong>viduare se <strong>un</strong>a particolare organizzazione li sta gestendo.<br />
220
Il servizio <strong>di</strong> risoluzione dei nomi Ottimizzare le prestazioni<br />
8.7 Ottimizzare le prestazioni<br />
Il caching del DNS è ampiamente utilizzato per migliorare le prestazioni<br />
rispetto al ritardo e per ridurre il numero <strong>di</strong> messaggi DNS nella rete. L’idea<br />
è molto semplice: quando <strong>un</strong> server dei nomi riceve <strong>un</strong>a correlazione per<br />
qualche hostname, esso la deposita nella sua memoria locale (<strong>di</strong> massa o<br />
volatile), mentre il messaggio attraversa la catena dei server <strong>di</strong> nomi.<br />
Data <strong>un</strong>a correlazione hostname/IP, memorizzata in cache, se al server<br />
dei nomi arriva <strong>un</strong>a successiva richiesta per lo stesso hostname, esso può<br />
fornire l’IP desiderato anche se non è autoritativo. Questi dati solitamente<br />
vengono cancellati dopo <strong>un</strong> certo tempo (dell’or<strong>di</strong>ne <strong>di</strong> giorni).<br />
Per entrambi i servizi <strong>di</strong> risoluzione può essere utile dotare ogni server<br />
(LDNS e LS) <strong>di</strong> <strong>un</strong>a cache del tutto simile a quella del DNS. Però se le<br />
mo<strong>di</strong>fiche allo spazio dei nomi logici risultano molto frequenti, la cache può<br />
causare problemi nel raggi<strong>un</strong>gere le risorse desiderate.<br />
Consideriamo la seguente con<strong>di</strong>zione critica:<br />
• nel sistema viene cancellata <strong>un</strong>’entità nell’ambiente virtuale. In realtà<br />
l’entità continua a sopravvivere, si ricor<strong>di</strong> che il suo PRI è persistente.<br />
La cancellazione opera solo a livello logico;<br />
• <strong>un</strong> qualche LNS non autoritativo ha in cache i valori necessari per la<br />
risoluzione dell’entità cancellata;<br />
• in <strong>un</strong> secondo tempo viene creata <strong>un</strong>a nuova entità con lo stesso nome<br />
logico.<br />
Sotto queste ipotesi <strong>un</strong>a richiesta <strong>di</strong> risoluzione, che si imbatte nel LNS in<br />
oggetto, ha associata <strong>un</strong>a risposta che in<strong>di</strong>ca <strong>un</strong>a risorsa non più valida.<br />
Per risolvere il problema possono essere trascurate, sotto opport<strong>un</strong>e ipotesi,<br />
le informazioni presenti in cache, ad esempio introducendo <strong>un</strong> tipo <strong>di</strong><br />
richiesta specifico per lo scopo. È ipotizzabile l’uso <strong>di</strong> <strong>un</strong> opport<strong>un</strong>o <strong>di</strong>mensionamento<br />
dei tempi <strong>di</strong> permanenza in cache oppure potrebbero essere<br />
previsti protocolli per il mantenimento della coerenza, ad esempio basati su<br />
<strong>un</strong> catalogo. Le varie alternative dovranno essere oggetto <strong>di</strong> stu<strong>di</strong>o in sviluppi<br />
futuri.<br />
221
Capitolo<br />
9<br />
Protocolli <strong>di</strong> com<strong>un</strong>icazione e<br />
architettura <strong>di</strong> rete in CISA<br />
9.1 Interfacce e protocolli<br />
CISA è <strong>un</strong>’architettura implementata tramite <strong>un</strong>a griglia <strong>di</strong> calcolatori<br />
che ospitano processi, è <strong>un</strong> sistema <strong>di</strong>stribuito il cui stato evolve nel tempo.<br />
L’evoluzione temporale è guidata dal fatto che si verificano eventi (come ad<br />
esempio azioni dell’utente o richieste <strong>di</strong> servizio provenienti dalla rete) che<br />
determinano l’attivazione dei processi che la costituiscono. Come evidenziato<br />
in precedenza, nel momento in cui <strong>un</strong> processo sta operando, ha la necessità<br />
<strong>di</strong> com<strong>un</strong>icare con altri processi, per richiedere servizi, necessari per portare<br />
a termine la propria mansione.<br />
L’interazione fra i processi in gioco, entità <strong>di</strong> livello applicativo della pila<br />
ISO/OSI, avviene tramite scambio <strong>di</strong> messaggi spe<strong>di</strong>ti attraverso la rete<br />
sfruttando i servizi messi a <strong>di</strong>sposizione dal livello OSI sottostante.<br />
Affinché tale interazione risulti possibile occorre com<strong>un</strong>que definire specifici<br />
protocolli <strong>di</strong> com<strong>un</strong>icazione <strong>di</strong> livello applicativo che permettono la<br />
com<strong>un</strong>icazione end-to-end fra i processi in gioco.<br />
A tal proposito si consideri la seguente definizione, riportata in [KR03]:<br />
“Un protocollo definisce il formato e l’or<strong>di</strong>ne dei messaggi
Protocolli <strong>di</strong> com<strong>un</strong>icazione e architettura <strong>di</strong> rete in CISA Interfacce e protocolli<br />
scambiati tra due o più entità com<strong>un</strong>icanti, così come le azioni<br />
che hanno luogo a seguito della trasmissione e/o ricezione <strong>di</strong><br />
<strong>un</strong> messaggio o <strong>di</strong> altri eventi”.<br />
Questa definizione evidenzia quin<strong>di</strong> <strong>un</strong>a duplice natura del protocollo: da<br />
<strong>un</strong> lato è necessario definire sintatticamente i messaggi scambiati fra le entità<br />
che com<strong>un</strong>icano (natura statica); dall’altro occorre definire come tali entità<br />
debbano comportarsi a seguito dei messaggi che vengono scambiati (natura<br />
<strong>di</strong>namica).<br />
Processo X<br />
Logica <strong>di</strong><br />
controllo del<br />
servizio A<br />
Gestione del<br />
protocollo <strong>di</strong><br />
livello<br />
applicativo<br />
Com<strong>un</strong>icazione<br />
end-to-end<br />
Rete<br />
Interfaccia Trasporto<br />
(Socket)<br />
Processo Y<br />
Logica <strong>di</strong><br />
controllo del<br />
servizio B<br />
Gestione del<br />
protocollo <strong>di</strong><br />
livello<br />
applicativo<br />
Figura 9.1: Bi<strong>di</strong>mensionalità dell’interfaccia fra processi.<br />
In CISA sono state definite varie tipologie <strong>di</strong> servizio ed è necessario<br />
introdurre dei protocolli finalizzati a regolare l’interazione fra i client e i<br />
processi server che li forniscono. La tipologia <strong>di</strong> servizio e il tipo <strong>di</strong> protocollo<br />
associato sono, ovviamente, entità correlate. Il protocollo, in altre parole,<br />
permette la com<strong>un</strong>icazione fra client e server attraverso <strong>un</strong>’interfaccia ben<br />
definita e specificata per lo scopo.<br />
L’interazione fra i vari sistemi che costituiscono CISA è tendenzialmente<br />
client/server e basata su <strong>un</strong> approccio REST-like: i protocolli definiti per la<br />
gestione <strong>di</strong> questo tipo <strong>di</strong> para<strong>di</strong>gma <strong>di</strong> com<strong>un</strong>icazione sono, come HTTP,<br />
request/response.<br />
223
Protocolli <strong>di</strong> com<strong>un</strong>icazione e architettura <strong>di</strong> rete in CISA Interfacce e protocolli<br />
In riferimento alla figura 9.1 il processo può essere visto come entità<br />
stratificata:<br />
• Logica <strong>di</strong> controllo del servizio. Si tratta dello strato superiore e si occupa<br />
<strong>di</strong> gestire il f<strong>un</strong>zionamento del processo (finalizzandone lo scopo<br />
all’espletamento <strong>di</strong> <strong>un</strong> particolare servizio). Prescindendo dagli aspetti<br />
implementativi del trasporto e della sintassi dei messaggi, si occupa<br />
esclusivamente del loro aspetto semantico.<br />
• Gestione del protocollo <strong>di</strong> livello applicativo. Si tratta dello strato inferiore<br />
e si occupa della gestione dei messaggi a più basso livello (sintassi).<br />
Inoltre si occupa <strong>di</strong> interfacciarsi alla rete e gestire la com<strong>un</strong>icazione<br />
con gli altri processi.<br />
Un primo vantaggio che deriva da questo approccio è che risulta possibile<br />
definire ed implementare la logica <strong>di</strong> controllo in<strong>di</strong>pendentemente dalla<br />
strategia utilizzata per il trasporto dei messaggi in rete. Questo permette <strong>di</strong><br />
prevedere algoritmi <strong>di</strong> gestione del processo <strong>di</strong> trasporto operanti in modo<br />
<strong>di</strong>verso ed interscambiabili. Ad esempio <strong>un</strong>o <strong>di</strong> essi potrebbe utilizzare <strong>un</strong><br />
socket TCP ed inoltrare i messaggi byte per byte; <strong>un</strong> altro li potrebbe incapsulare<br />
nella loro interezza in <strong>un</strong> messaggio HTTP; <strong>un</strong> altro ancora potrebbe<br />
utilizzare SMTP 1 e così via (HTTPS, FTP, etc.).<br />
Risulta possibile inoltre implementare la logica <strong>di</strong> controllo anche prescindendo<br />
dal sistema operativo in uso e conseguentemente questa, fissato <strong>un</strong><br />
particolare linguaggio <strong>di</strong> programmazione, è platform-in<strong>di</strong>pendent.<br />
Il sottosistema de<strong>di</strong>cato alla gestione del protocollo <strong>di</strong> livello applicativo<br />
deve interfacciarsi con il sistema operativo (del calcolatore che ospita il<br />
processo) per l’accesso alla rete. Questa operazione avviene ricorrendo a specifiche<br />
librerie, <strong>di</strong>pendenti dal linguaggio <strong>di</strong> programmazione e in alc<strong>un</strong>i casi<br />
dalla piattaforma, che mettono a <strong>di</strong>sposizione del programmatore predeterminate<br />
interfacce software (API) finalizzate ad utilizzare i servizi messi a<br />
<strong>di</strong>sposizione dal layer OSI sottostante.<br />
Con le premesse <strong>di</strong> cui sopra l’eventuale in<strong>di</strong>pendenza delle librerie dalla<br />
piattaforma è <strong>un</strong>a caratteristica che permette <strong>di</strong> assicurare, fissato il linguaggio,<br />
l’in<strong>di</strong>pendenza dalla piattaforma del co<strong>di</strong>ce sorgente relativo a tutto il<br />
1 La scelta <strong>di</strong> SMTP non è stata casuale (è possibile ricorrere anche ad altri protocolli)<br />
in quanto si può ipotizzare l’esistenza <strong>di</strong> particolari messaggi <strong>di</strong> importanza rilevante che<br />
potrebbero essere inoltrati per posta elettronica certificata e che avrebbero quin<strong>di</strong> anche<br />
valenza giuri<strong>di</strong>ca.<br />
224
Protocolli <strong>di</strong> com<strong>un</strong>icazione e architettura <strong>di</strong> rete in CISA Interfacce e protocolli<br />
processo. In riferimento alla pila Internet, considerando la semplicità dell’interfaccia<br />
che questa mette a <strong>di</strong>sposizione al livello applicativo (socket),<br />
è com<strong>un</strong>que preve<strong>di</strong>bile che il porting [Por06] da <strong>un</strong>a piattaforma all’altra<br />
sia <strong>un</strong>’operazione poco costosa, a patto <strong>di</strong> ricorrere ad <strong>un</strong>a programmazione<br />
oculata (in implementazioni object-oriented sfruttando alc<strong>un</strong>i dei Pattern <strong>di</strong><br />
programmazione più noti in letteratura [GHJV95]).<br />
I processi che costituiscono CISA sono interconnessi tramite rete pertanto<br />
ogn<strong>un</strong>o <strong>di</strong> essi, sia che appartenga a servizi <strong>di</strong>versi oppure allo stesso servizio,<br />
può essere implementato secondo strategie <strong>di</strong>fferenti a patto <strong>di</strong> rispettare le<br />
specifiche del protocollo <strong>di</strong> intercom<strong>un</strong>icazione. Tali strategie forniscono la<br />
possibilità <strong>di</strong> scegliere il linguaggio e lo stile <strong>di</strong> programmazione, il sistema<br />
operativo e la piattaforma hardware dell’host.<br />
Mo<strong>di</strong>fiche più sostanziali che influenzano il f<strong>un</strong>zionamento della logica <strong>di</strong><br />
controllo sono altresì possibili, anche se risultano operazioni più complesse.<br />
In questo caso occorre aggiornare il protocollo in esame in modo da rendere<br />
esplicite all’esterno le mo<strong>di</strong>fiche comportamentali dell’entità.<br />
Una fase iniziale <strong>di</strong> handshaking (esplicita o implicita) permette ai due<br />
processi interessati alla com<strong>un</strong>icazione <strong>di</strong> stabilire con quale versione del protocollo<br />
<strong>di</strong>alogare. Se la scelta ricade sulla versione precedente è perché <strong>un</strong>o<br />
dei due processi non è aggiornato e l’altro, affinché la com<strong>un</strong>icazione sia possibile,<br />
può adeguarsi comportandosi secondo le modalità operative precedenti.<br />
Viceversa, se la scelta ricade sull’ultima versione, entrambi i processi sono<br />
aggiornati e pertanto possono utilizzare il nuovo protocollo e comportarsi<br />
secondo le nuove modalità.<br />
9.1.1 Interfaccia bi<strong>di</strong>mensionale<br />
Come già anticipato, all’interno del processo sono stati in<strong>di</strong>viduati due<br />
sottosistemi <strong>di</strong>stinti: <strong>un</strong>a logica <strong>di</strong> controllo, che si occupa <strong>di</strong> implementare<br />
le f<strong>un</strong>zionalità richieste dall’applicazione, ed <strong>un</strong> sistema de<strong>di</strong>cato alla gestione<br />
della com<strong>un</strong>icazione.<br />
Tale sistema si inquadra come sotto-livello <strong>di</strong> applicazione della pila OSI<br />
posizionato a contatto con l’interfaccia inferiore del livello. In realtà alc<strong>un</strong>e<br />
delle f<strong>un</strong>zioni espletate sono in<strong>di</strong>viduabili all’interno del livello presentazione<br />
<strong>di</strong> OSI, ma dettagliare la descrizione a tal p<strong>un</strong>to non è vantaggioso. Conviene<br />
considerare il sistema de<strong>di</strong>cato alla gestione della com<strong>un</strong>icazione come<br />
<strong>un</strong>ica entità appartenente al livello applicativo <strong>di</strong> OSI e non sud<strong>di</strong>viderlo ul-<br />
225
Protocolli <strong>di</strong> com<strong>un</strong>icazione e architettura <strong>di</strong> rete in CISA Interfacce e protocolli<br />
teriormente in due sottosistemi <strong>un</strong>o <strong>di</strong> livello applicativo e l’altro <strong>di</strong> livello<br />
presentazione.<br />
L’acronimo IACS, Inter-Application Comm<strong>un</strong>ication System è stato ideato<br />
per riferirsi al sistema de<strong>di</strong>cato alla gestione della com<strong>un</strong>icazione fra i<br />
processi (ovvero le applicazioni).<br />
Quin<strong>di</strong> all’interno <strong>di</strong> <strong>un</strong> processo è possibile in<strong>di</strong>viduare due interfacce <strong>di</strong>stinte<br />
(si faccia riferimento alla figura 9.2, nella quale sono state “localizzate”<br />
anche le rispettive API):<br />
• Interfaccia (inferiore) fra processo (in particolare IACS) e sistema operativo:<br />
questa interfaccia permette l’invio e la ricezione dei dati ed è<br />
utilizzabile ricorrendo alla specifica API messa a <strong>di</strong>sposizione tramite<br />
opport<strong>un</strong>e librerie (normalmente fornite dal sistema operativo stesso).<br />
• Interfaccia (superiore) fra logica <strong>di</strong> controllo e IACS: questa interfaccia,<br />
ragionando in modo equivalente al caso precedente, permette alla logica<br />
<strong>di</strong> controllo <strong>di</strong> scambiare messaggi, entità più astratta rispetto all’invio<br />
e alla ricezione dei dati <strong>di</strong>scussi al p<strong>un</strong>to precedente, ricorrendo alla<br />
specifica API messa a <strong>di</strong>sposizione da IACS.<br />
In questi termini è opport<strong>un</strong>o pensare <strong>di</strong> implementare sotto forma <strong>di</strong> libreria<br />
gli IACS relativi ai vari protocolli. Questa soluzione è quella più logica<br />
e più efficiente, ma non è l’<strong>un</strong>ica. In particolare, qualora il numero <strong>di</strong> sistemi<br />
operativi e <strong>di</strong> linguaggi <strong>di</strong> programmazione si frammentasse eccessivamente,<br />
dando vita ad <strong>un</strong> numero <strong>di</strong> varianti elevato per le quali mantenere separate<br />
le implementazioni delle varie librerie dovesse <strong>di</strong>ventare <strong>un</strong>’operazione troppo<br />
costosa, è possibile realizzare <strong>un</strong>’implementazione stand-alone <strong>di</strong> IACS raggi<strong>un</strong>gibile<br />
via rete tramite RPC (Remote Call Procedure). In questo modo,<br />
a patto <strong>di</strong> ricorrere ad <strong>un</strong> meccanismo per RPC standar<strong>di</strong>zzato ed aperto,<br />
il sistema IACS risulta del tutto svincolato dalla logica <strong>di</strong> controllo e quin<strong>di</strong><br />
i due sistemi, adesso considerati strettamente correlati, <strong>di</strong>venterebbero<br />
in<strong>di</strong>pendenti e implementabili in modo autonomo.<br />
Prendendo come esempio il caso riportato in figura 9.2 è possibile entrare<br />
più nel dettaglio della descrizione dell’interfaccia fra logica <strong>di</strong> controllo ed<br />
IACS e della descrizione <strong>di</strong> tale <strong>di</strong>spositivo.<br />
L’API fornita da IACS mostra alla logica <strong>di</strong> controllo le primitive del<br />
protocollo sotto forma <strong>di</strong> interfaccia software: nell’esempio get(lri); e<br />
put(doc);. Invocando tali primitive la logica <strong>di</strong> controllo effettua delle<br />
operazioni che, a livello concettuale, sono request.<br />
226
Protocolli <strong>di</strong> com<strong>un</strong>icazione e architettura <strong>di</strong> rete in CISA Interfacce e protocolli<br />
Logica <strong>di</strong> Controllo<br />
del servizio<br />
Politiche <strong>di</strong> gestione del protocollo<br />
IACS<br />
response(msg);<br />
Response<br />
Processo X<br />
Request<br />
get(lri); put(doc);<br />
Politiche <strong>di</strong> gestione del protocollo<br />
Generazione, ricezione e gestione<br />
messagggio serializzato<br />
Gestione del trasporto a<br />
basso livello (gestione<br />
socket, incapsulamento<br />
su HTTP, etc.)<br />
Client<br />
Request<br />
Rete<br />
Server<br />
Figura 9.2: Inter-Application Comm<strong>un</strong>ication System.<br />
IACS <strong>di</strong>spone <strong>di</strong> <strong>un</strong>a logica interna che gli fornisce la facoltà <strong>di</strong> interpretare<br />
le richieste ed operare <strong>di</strong> conseguenza. Il caso più semplice è quello nel<br />
quale il processo client <strong>di</strong>spone soltanto del socket Client (in basso a destra<br />
nella figura) aperta all’avvio del sistema che interconnette in modo persistente<br />
tale processo con il processo server relativo al servizio che intende<br />
richiedere. Il processo server, dualmente, <strong>di</strong>spone soltanto del socket Server.<br />
Il meccanismo <strong>di</strong> f<strong>un</strong>zionamento, a seguito <strong>di</strong> <strong>un</strong>a richiesta proveniente dalla<br />
logica <strong>di</strong> controllo, è il seguente:<br />
• la politica <strong>di</strong> gestione del protocollo permette <strong>di</strong> creare il messaggio da<br />
inviare al server;<br />
Socket<br />
Socket<br />
API<br />
API<br />
227
Protocolli <strong>di</strong> com<strong>un</strong>icazione e architettura <strong>di</strong> rete in CISA Interfacce e protocolli<br />
• il messaggio viene convertito in forma serializzata, eventualmente ricorrendo<br />
alla firma <strong>di</strong>gitale e/o alla crittografia per <strong>un</strong> invio sicuro;<br />
• il sistema è in grado <strong>di</strong> effettuare l’invio sulla rete, byte per byte,<br />
incapsulando il messaggio ad esempio in HTTP, etc. come esposto<br />
precedentemente;<br />
• l’altro processo riceve dalla rete le informazioni inviate ed effettua<br />
le operazioni descritte in senso opposto fino ad invocare la primitiva<br />
richiesta sulla logica <strong>di</strong> controllo;<br />
• viene generata la response la quale ritorna al mittente seguendo il<br />
percorso inverso.<br />
All’atto pratico la logica <strong>di</strong> controllo client invoca il metodo remoto corrispondente<br />
alla primitiva del protocollo che intende chiamare sulla logica <strong>di</strong><br />
controllo server. Questo meccanismo è del tutto equivalente a quello che si<br />
verifica richiamando, attraverso il browser web, <strong>un</strong>a pagina residente su <strong>un</strong><br />
server web tramite il protocollo HTTP. Supponendo che la richiesta sia <strong>un</strong>a<br />
GET tutto succede come se il server web, al momento della ricezione del messaggio<br />
inviato dal client, invocasse <strong>un</strong> metodo interno GET(parametri); dove<br />
i parametri sono rappresentati da tutte le opzioni previste ed inviate nella<br />
richiesta tramite HTTP. Il risultato della chiamata è esattamente la pagina<br />
richiesta che viene spe<strong>di</strong>ta al client, operazione associabile a sua volta ad <strong>un</strong>a<br />
RPC nella quale il server invoca sul client il metodo response(pagina);. Il<br />
corpo <strong>di</strong> questa f<strong>un</strong>zione definita nel client provvede ad avviare la procedura<br />
<strong>di</strong> visualizzazione della pagina all’utente.<br />
Si osservi che ogni server deve essere in grado <strong>di</strong> gestire richieste provenienti<br />
da più <strong>di</strong> <strong>un</strong> client (in generale da <strong>un</strong> qual<strong>un</strong>que altro processo presente<br />
in rete). Questo aspetto viene tenuto in considerazione durante la progettazione<br />
del IACS. Il sistema resta in ascolto in rete ed applica il multiplexing<br />
delle richieste in arrivo per processarle sequenzialmente (eventualmente applicando<br />
opport<strong>un</strong>e politiche <strong>di</strong> gestione quali code con priorità); dualmente<br />
effettua <strong>un</strong> demultiplexing delle risposte per inoltrarle al corretto destinatario.<br />
In contrapposizione è possibile implementare il sistema affinché questo<br />
utilizzi <strong>un</strong> thread <strong>di</strong>verso per ogni client che richiede il servizio, ottenendo <strong>un</strong><br />
avanzamento parallelo dell’elaborazione: questo è il caso in cui sono presenti<br />
più serventi. Nella pratica verrà utilizzata <strong>un</strong>a strategia mista limitando, con<br />
opport<strong>un</strong>e politiche, il numero massimo <strong>di</strong> thread utilizzabili: se le richieste<br />
228
Protocolli <strong>di</strong> com<strong>un</strong>icazione e architettura <strong>di</strong> rete in CISA L’architettura <strong>di</strong> rete<br />
contemporanee sono in <strong>un</strong> numero inferiore a quello massimo prestabilito<br />
vengono elaborate in parallelo, altrimenti attendono in coda. Infine, se il<br />
carico è ritenuto eccessivamente alto, potrebbero essere ad<strong>di</strong>rittura rifiutate.<br />
Nel paragrafo successivo verrà descritto <strong>un</strong> esempio <strong>di</strong> IACS più articolato<br />
che permette <strong>di</strong> evidenziare ulteriormente la flessibilità <strong>di</strong> questa soluzione.<br />
9.2 L’architettura <strong>di</strong> rete<br />
Lo scenario presentato nei paragrafi precedenti evidenzia come CISA sia<br />
<strong>un</strong>’architettura totalmente <strong>di</strong>stribuita e realizzata tramite l’interconnessione<br />
<strong>di</strong> processi in rete. Un’organizzazione che intende utilizzare CISA deve<br />
<strong>di</strong>sporre <strong>di</strong> <strong>un</strong>’adeguata infrastruttura hardware/software la quale, oltre a<br />
permettere l’accesso alle risorse fornite da altre organizzazioni, permette <strong>di</strong><br />
fornire essa stessa risorse all’esterno secondo lo stesso principio utilizzato<br />
nelle reti peer-to-peer. Il principio è il medesimo, ma all’atto pratico non è<br />
corretto parlare <strong>di</strong> CISA come rete peer-to-peer in quando l’infrastruttura<br />
è com<strong>un</strong>que orientata ai servizi fruibili tramite il para<strong>di</strong>gma client/server.<br />
L’associazione con le reti peer-to-peer è valida da <strong>un</strong> p<strong>un</strong>to <strong>di</strong> vista logico in<br />
quanto l’aggi<strong>un</strong>ta <strong>di</strong> middelware nella rete permette <strong>di</strong> estenderne le potenzialità<br />
e i nuovi <strong>di</strong>spositivi avranno gli stessi “<strong>di</strong>ritti e doveri” degli apparati<br />
equivalenti già presenti. Per completare la similitu<strong>di</strong>ne si può pensare ad <strong>un</strong><br />
“macro-client”, il cui utente è <strong>un</strong>’organizzazione, che espleti tutte le f<strong>un</strong>zioni<br />
<strong>di</strong> CISA: quando l’organizzazione“apre”il proprio macro-client (attiva quin<strong>di</strong><br />
tutti i servizi CISA) si proietta in rete ed acquisisce la possibilità <strong>di</strong> accedere<br />
alle informazioni messe a <strong>di</strong>sposizione da altri utenti (organizzazioni) e <strong>di</strong><br />
fornire e rendere <strong>di</strong>sponibili a questi ultimi le proprie, così come avviene con<br />
i client peer-to-peer utilizzati per il file sharing.<br />
Lo scenario tipico, mostrato in figura 9.3, permette <strong>di</strong> evidenziare queste<br />
caratteristiche <strong>di</strong> particolare importanza.<br />
Senza escludere altre possibilità il modo più <strong>di</strong>retto per organizzare gli<br />
apparati <strong>di</strong> CISA è quello <strong>di</strong> pre<strong>di</strong>sporre <strong>un</strong>o o più server hardware (rappresentati<br />
in figura dal case <strong>di</strong> <strong>un</strong> calcolatore), vari personal computer per i client<br />
utente (rappresentati in figura da <strong>un</strong> monitor e da <strong>un</strong>a tastiera) interconnessi<br />
alla rete 2 .<br />
2 Si parla <strong>di</strong> rete e non <strong>di</strong> Internet in quanto si intende <strong>un</strong>’interconnessione fra i processi<br />
<strong>di</strong> CISA che, in via <strong>di</strong> principio, può avvenire sia tramite la rete pubblica, che attraverso<br />
<strong>un</strong>a o più reti private oppure su <strong>un</strong> insieme eterogeneo <strong>di</strong> soluzioni.<br />
229
Protocolli <strong>di</strong> com<strong>un</strong>icazione e architettura <strong>di</strong> rete in CISA L’architettura <strong>di</strong> rete<br />
V.R.,<br />
State<br />
Organizzazione A<br />
App.<br />
LS,<br />
LDNS<br />
R.M,M.D.<br />
Lan1<br />
Lan2<br />
App.<br />
Router<br />
Control<br />
Struct.<br />
Rete<br />
Organizzazione B<br />
Router<br />
V.R.,<br />
State,<br />
LDNS,<br />
LS<br />
App.<br />
Lan<br />
Figura 9.3: Esempio <strong>di</strong> scenario <strong>di</strong> utilizzo <strong>di</strong> CISA.<br />
Control<br />
Struct.,<br />
R.M.,<br />
M.D.<br />
Ogni organizzazione ha, oltre alla propria connessione alla rete, alc<strong>un</strong>i<br />
server sui quali far operare <strong>un</strong>o o più processi CISA. Niente vieta <strong>di</strong> ipotizzare<br />
l’esistenza <strong>di</strong> service provider i quali forniscono alle organizzazioni<br />
l’infrastruttura per l’accesso a CISA (accollandosi l’onere <strong>di</strong> amministrare i<br />
server) così come avviene attualmente, ad esempio, per i fornitori dell’accesso<br />
ad Internet e per i servizi <strong>di</strong> web hosting.<br />
Lo scenario prospettato presuppone che, per quanto possibile, ogni organizzazione<br />
utilizzi i servizi CISA internamente messi in opera. I motivi che<br />
spingono a formulare questa ipotesi sono vari, ad esempio vincolare l’interazione<br />
fra i server presenti all’interno della propria rete privata, semplifica<br />
l’amministrazione del sistema all’organizzazione e le permette <strong>di</strong> controllare<br />
in modo molto più <strong>di</strong>retto ed efficace tutti gli aspetti legati a questioni <strong>di</strong><br />
sicurezza.<br />
In questo scenario quin<strong>di</strong>, partendo dal livello applicativo, l’organizzazione<br />
usufruisce dei propri server 3 fino a livello Replica Management. Tale<br />
3 Per quanto riguarda il meccanismo <strong>di</strong> risoluzione si intende che la richiesta debba<br />
essere tendenzialmente effettuata al proprio server (LS o LDNS), ovviamente, a causa<br />
dell’accoppiamento presente fra i processi in gioco, tali server dovranno poter com<strong>un</strong>icare<br />
con quelli <strong>di</strong> pari livello delle altre organizzazioni.<br />
230
Protocolli <strong>di</strong> com<strong>un</strong>icazione e architettura <strong>di</strong> rete in CISA L’architettura <strong>di</strong> rete<br />
processo interpella trasversalmente quello autoritativo sulla risorsa <strong>di</strong> interesse,<br />
effettuando <strong>un</strong>a sorta <strong>di</strong> routing delle richieste. Infine, seguendo la<br />
stessa logica utilizzata per i livelli superiori, quest’ultimo processo (Replica<br />
Management) accede ai dati riferendosi ad <strong>un</strong> numero limitato e stabilito a<br />
priori <strong>di</strong> Me<strong>di</strong>um Dependent.<br />
9.2.1 Routing delle richieste<br />
Durante lo sviluppo dei vari servizi costituenti l’architettura e in <strong>un</strong>a<br />
prima fase della vita utile in produzione, ipotizzare che ogni processo conosca<br />
a priori ed in modo vincolante quali altri processi interpellare per richiedere<br />
servizi potrebbe essere l’<strong>un</strong>ica strada percorribile.<br />
Questo scenario può essere implementato ricorrendo all’uso degli IACS<br />
descritti nel paragrafo 9.1.1: ogni processo è connesso permanentemente con<br />
altri processi, noti a priori, che forniscono i servizi ad esso necessari.<br />
La questione sollevata in questo paragrafo è che tale soluzione potrebbe<br />
non essere quella ottimale. Verrano quin<strong>di</strong> introdotte strategie alternative<br />
evidenziando quali mo<strong>di</strong>fiche architetturali richiedano per essere implementate.<br />
L’ipotesi che viene mantenuta è che ogni processo che fornisce <strong>un</strong>o specifico<br />
servizio sia del tutto equivalente ad <strong>un</strong> qual<strong>un</strong>que altro processo che<br />
fornisce lo stesso servizio (per ogni possibile richiesta effettuata al processo,<br />
il comportamento percepito dal richiedente deve essere equivalente). La rimozione<br />
<strong>di</strong> questa ipotesi porterebbe ad <strong>un</strong>a completa ri-progettazione del<br />
sistema orientata verso <strong>un</strong> para<strong>di</strong>gma Web Services like.<br />
Il <strong>di</strong>scorso è <strong>di</strong>verso per quanto riguarda l’efficienza: prendendo per esempio<br />
il caso della risoluzione dei nomi, effettuare la richiesta ad <strong>un</strong> server che<br />
conosce <strong>di</strong>rettamente la risposta è certamente più efficiente rispetto ad effettuare<br />
la medesima richiesta ad <strong>un</strong> qualsiasi altro server che non la conosce e<br />
che deve, a sua volta, richiederla ad altri processi omologhi.<br />
Invece <strong>di</strong> vincolare il processo client ad usufruire <strong>di</strong> <strong>un</strong> servizio tramite<br />
<strong>un</strong> predeterminato processo server, si può ipotizzare che esista <strong>un</strong> algoritmo<br />
capace <strong>di</strong> selezionare il server che dovrebbe potenzialmente rispondere in<br />
modo più efficiente rispetto a tutti gli altri processi che erogano lo stesso<br />
tipo <strong>di</strong> servizio.<br />
Il fatto che l’algoritmo sia stocastico non va ad inficiare l’efficacia del<br />
sistema in quanto, come è stato precedentemente evidenziato, la scelta <strong>di</strong> <strong>un</strong><br />
231
Protocolli <strong>di</strong> com<strong>un</strong>icazione e architettura <strong>di</strong> rete in CISA L’architettura <strong>di</strong> rete<br />
processo, anziché <strong>di</strong> <strong>un</strong> altro omologo, non comporta <strong>di</strong>fferenze per quanto<br />
riguarda l’efficacia sull’espletamento del servizio complessivamente erogato.<br />
In questo scenario si evidenzia la natura“intelligente”del IACS. La gestione<br />
del routing delle richieste può essere delegata a tale sistema mascherandola,<br />
parzialmente o completamente, alla logica <strong>di</strong> controllo. Questo perché<br />
il <strong>di</strong>spositivo fornisce <strong>un</strong>’interfaccia software per l’accesso alle primitive del<br />
protocollo e quin<strong>di</strong> possono esistere implementazioni in grado <strong>di</strong> interpretare<br />
e prendere decisioni (ovvero applicare l’algoritmo) sulla base delle specifiche<br />
richieste (contingenti o cablate).<br />
Nell’ipotesi, peraltro realistica, in cui tale mascheramento sia completo è<br />
logico supporre che in <strong>un</strong>a prima fase dello sviluppo si proceda verso <strong>un</strong>a soluzione<br />
priva <strong>di</strong> tale f<strong>un</strong>zionalità con la consapevolezza che, qualora risultasse<br />
importante per l’efficienza globale del sistema, tale f<strong>un</strong>zionalità interna può<br />
essere aggi<strong>un</strong>ta successivamente con costi ridotti (in quanto non è necessario<br />
intervenire sul f<strong>un</strong>zionamento dei servizi, ma solo sugli IACS).<br />
Volendo escludere l’esistenza <strong>di</strong> <strong>un</strong> algoritmo efficace ed efficiente per la<br />
scelta del processo migliore con <strong>un</strong>a qualsiasi soglia <strong>di</strong> approssimazione, i<br />
ragionamenti riportati in questo paragrafo continuano ad avere rilevanza.<br />
Infatti, per migliorare ulteriormente la scalabilità e l’affidabilità locale<br />
del sistema, è com<strong>un</strong>que possibile introdurre <strong>un</strong> <strong>di</strong>spatcher all’interno del<br />
IACS che applichi politiche <strong>di</strong> bilanciamento <strong>di</strong> carico (ad esempio ro<strong>un</strong>drobin)<br />
al susseguirsi delle richieste generate dal client in modo che queste si<br />
<strong>di</strong>stribuiscano e vadano a caricare più <strong>di</strong> <strong>un</strong> server.<br />
9.2.2 Protocollo con delega<br />
Questo scenario si presenta nel caso in cui si introduca la modalità <strong>di</strong><br />
interazione con delega che risulta <strong>di</strong>versa da quella tipica client/server.<br />
In riferimento alla figura 9.4.a è possibile descrivere brevemente la classica<br />
interazione basata sul para<strong>di</strong>gma client/server. Nell’esempio si ipotizza che<br />
S0, S1 e S2 siano server tali che il primo <strong>di</strong> essi è <strong>di</strong> livello <strong>di</strong> CISA superiore<br />
mentre gli altri sono <strong>di</strong> livello inferiore. Il server S0 deve effettuare <strong>un</strong>a<br />
richiesta <strong>di</strong> servizio e si rivolge ad S1 che però non è in grado <strong>di</strong> sod<strong>di</strong>sfare<br />
tale richiesta. Conseguentemente S1 inoltra la richiesta a S2 il quale è in<br />
grado <strong>di</strong> fornire la risposta. A questo p<strong>un</strong>to S1 è in grado <strong>di</strong> rispondere a S0.<br />
In questo tipo <strong>di</strong> interazione si ha <strong>un</strong>a catena costituita da <strong>un</strong>a successione<br />
232
Protocolli <strong>di</strong> com<strong>un</strong>icazione e architettura <strong>di</strong> rete in CISA L’architettura <strong>di</strong> rete<br />
a) Para<strong>di</strong>gma<br />
client/server<br />
IACS<br />
b) Protocollo<br />
con delega<br />
Client<br />
Logica <strong>di</strong> controllo<br />
IACS<br />
Server S2<br />
Client<br />
4<br />
Server<br />
Server<br />
Logica <strong>di</strong> controllo<br />
Server S2<br />
Server S0<br />
Logica <strong>di</strong> controllo<br />
IACS<br />
4<br />
Response<br />
3<br />
Request<br />
Client<br />
Server S0<br />
Logica <strong>di</strong> controllo<br />
IACS<br />
5<br />
Response<br />
6<br />
Server<br />
3<br />
Request<br />
1<br />
Client<br />
1<br />
IACS<br />
Client<br />
2<br />
Server<br />
Logica <strong>di</strong> controllo<br />
IACS<br />
Server S1<br />
Client<br />
5<br />
2<br />
Server<br />
Logica <strong>di</strong> controllo<br />
Server S1<br />
Figura 9.4: Esempio <strong>di</strong> interazione con protocollo con delega.<br />
233
Protocolli <strong>di</strong> com<strong>un</strong>icazione e architettura <strong>di</strong> rete in CISA L’architettura <strong>di</strong> rete<br />
<strong>di</strong> request ed <strong>un</strong>a successione <strong>di</strong> response che percorre lo stesso cammino in<br />
senso inverso.<br />
In figura 9.4.b è schematizzato il comportamento del protocollo con delega<br />
<strong>di</strong> fronte allo stesso tipo <strong>di</strong> problema appena analizzato ed affrontato con il<br />
para<strong>di</strong>gma client/server. La com<strong>un</strong>icazione si sviluppa come segue:<br />
1. la logica <strong>di</strong> controllo del server S0 deve effettuare <strong>un</strong>a richiesta <strong>di</strong><br />
servizio (request) e la inoltra al proprio IACS;<br />
2. IACS sceglie S1 come server a cui rivolgersi;<br />
3. S1 non è in possesso delle informazioni necessarie per espletare il servizio<br />
richiesto da S0 oppure (pur essendo in possesso delle informazioni<br />
necessarie) conosce <strong>un</strong> server omologo S2 anch’esso in grado <strong>di</strong> fornire<br />
la risposta (e valuta che, in quel momento, S2 possa rispondere in<br />
modo più efficiente). Inoltra quin<strong>di</strong> la richiesta ad S2 a nome <strong>di</strong> S0<br />
(on behalf of S0 );<br />
4. S2 è in grado <strong>di</strong> fornire la risposta e, agendo da client, contatta l’IACS<br />
<strong>di</strong> S0;<br />
5. IACS <strong>di</strong> S0 è in grado <strong>di</strong> riconoscere questo messaggio come la response<br />
relativa alla request iniziale e la fornisce alla logica <strong>di</strong> controllo.<br />
Il meccanismo <strong>di</strong> delega viene implementato integralmente a livello <strong>di</strong><br />
IACS e come conseguenza la logica <strong>di</strong> controllo del client non percepisce ness<strong>un</strong>a<br />
<strong>di</strong>fferenza fra le due modalità operative vedendosi recapitare le response<br />
allo stesso modo.<br />
234
Conclusioni<br />
L’obiettivo del presente lavoro tesi è stato quello <strong>di</strong> progettare <strong>un</strong> <strong>modello</strong><br />
dell’informazione ed <strong>un</strong>’architettura <strong>di</strong>stribuita finalizzati al lavoro collaborativo.<br />
In questo contesto il versioning assume <strong>un</strong>’importanza <strong>di</strong> rilievo infatti<br />
permette, ad esempio, <strong>di</strong> tracciare le azioni degli utenti incrementandone<br />
l’awareness e <strong>di</strong> annullare operazioni non sod<strong>di</strong>sfacenti.<br />
Le varie tappe del lavoro hanno richiesto l’analisi <strong>di</strong> problematiche presenti<br />
in contesti <strong>di</strong>versi che partono dal Document e Content Management<br />
all’Enterprise Content Management, dai sistemi <strong>di</strong> controllo delle versioni per<br />
lo sviluppo del software agli ambienti groupware generici, dalla modellizzazione<br />
dell’informazione al calcolo <strong>di</strong>stribuito, fino all’analisi <strong>di</strong> standard per<br />
la trasmissione dei dati ed alla progettazione <strong>di</strong> protocolli <strong>di</strong> com<strong>un</strong>icazione<br />
<strong>di</strong> livello applicativo ISO/OSI.<br />
Nella prima fase del presente lavoro <strong>di</strong> tesi, relativa all’analisi dell’informazione,<br />
sono stati sintetizzati i requisiti che il <strong>modello</strong> del documento progettato,<br />
denominato “Distributed Delocalized Document Information Model”<br />
(D3IM), sod<strong>di</strong>sfa.<br />
In dettaglio è stato messo in evidenza che:<br />
• L’informazione è strutturata e la descrizione effettuata tramite l’espressività<br />
degli alberi, è stata ritenuta non sufficiente per coprire tutte le<br />
casistiche; per tale motivo si è scelto <strong>di</strong> modellare i legami fra gli elementi<br />
che costituiscono il contenuto dei documenti attraverso i DAG<br />
(Directed Acyclic Graph) rispetto ai quali gli alberi rappresentano <strong>un</strong><br />
caso particolare. Un documento D3IM è quin<strong>di</strong> <strong>un</strong> DAG i cui no<strong>di</strong>, denominati<br />
informazioni primitive, incapsulano i dati veri e propri sotto<br />
forma <strong>di</strong> coppie “”, denominate informazioni atomiche.
Conclusioni<br />
Le relazioni fra no<strong>di</strong> permettono <strong>di</strong> descrivere gli aspetti strutturali<br />
del documento che è stato definito come entità organizzata in modo<br />
gerarchico.<br />
• L’informazione primitiva ha <strong>un</strong> responsabile che è colui il quale ha la<br />
consapevolezza <strong>di</strong> dover rispondere degli effetti che possono scaturire a<br />
seguito della <strong>di</strong>vulgazione dell’informazione. Il responsabile può essere<br />
<strong>un</strong>a persona fisica o giuri<strong>di</strong>ca che, per alc<strong>un</strong>e categorie <strong>di</strong> informazioni,<br />
è stabilita dalla legge.<br />
• L’informazione è <strong>versionata</strong> e D3IM applica nativamente <strong>un</strong> proprio<br />
<strong>modello</strong> <strong>di</strong> versioning progettato, nel presente lavoro <strong>di</strong> tesi, sulla base<br />
<strong>di</strong> UEVM. Ogni documento D3IM incapsula quin<strong>di</strong> tutte le varie forme<br />
che l’informazione ha ass<strong>un</strong>to nell’intero ciclo evolutivo del documento<br />
stesso.<br />
• L’informazione è delocalizzata, <strong>di</strong>stribuita e replicata. Ogni documento<br />
è costituito da informazioni primitive, <strong>di</strong>stribuite nello spazio, ed<br />
eventualmente replicate per la tolleranza ai guasti e il bilanciamento<br />
del carico; inoltre il fruitore del documento non può inquadrarle nel<br />
contesto <strong>di</strong> <strong>un</strong>a specifica localizzazione fisica.<br />
Per perseguire queste finalità sono stati definiti tre spazi <strong>di</strong> nomi, su tre<br />
livelli <strong>di</strong>versi, relativi alle risorse. I nomi logici (Logical Resource Identifier,<br />
LRI) vengono assegnati alle informazioni primitive dall’utente e sono<br />
facilmente trattabili dall’uomo; ogni informazione primitiva può essere identificata<br />
da <strong>un</strong> numero arbitrario <strong>di</strong> LRI (alias). I nomi persistenti ed <strong>un</strong>ivoci<br />
(Persistent Resource Identifier, PRI) vengono assegnati dal sistema per l’identificazione<br />
non ambigua <strong>di</strong> ogni informazione primitiva. Infine gli Uniform<br />
Resource Locator (URL) servono per identificare e permettere l’accesso alle<br />
singole repliche.<br />
Sulla base dei principi <strong>di</strong> f<strong>un</strong>zionamento del DNS (Domain Name System)<br />
sono stati introdotti i sistemi per la risoluzione, <strong>di</strong>retta ed inversa, da LRI<br />
a PRI e da PRI ad URL chiamati rispettivamente “Logical Domain Name<br />
System” (LDNS) e “Localization Service” (LS).<br />
Sulla base del <strong>modello</strong> D3IM, nel presente lavoro <strong>di</strong> tesi, è stata progettata<br />
anche <strong>un</strong>’infrastruttura chiamata “Collaborative Information System<br />
Architecture” (CISA).<br />
236
Conclusioni<br />
Il progetto è stato eseguito secondo <strong>un</strong> approccio stratificato e sono stati<br />
in<strong>di</strong>viduati i seguenti livelli:<br />
• Application Layer, si occupa <strong>di</strong> fornire l’interfaccia all’utilizzatore del sistema<br />
e <strong>di</strong> implementare le strategie operative finalizzate al trattamento<br />
dei dati nel particolare contesto applicativo;<br />
• Virtual Repository Layer, si occupa della gestione delle identità degli<br />
utenti, della ricostruzione (aggregando informazioni primitive) e decomposizione<br />
(scomponendo informazioni primitive) dei documenti e<br />
della risoluzione dei nomi logici in persistenti tramite LDNS;<br />
• Structure Layer, si occupa della gestione delle versioni dell’informazione<br />
utilizzando il <strong>modello</strong> <strong>di</strong> versioning estensionale definito in D3IM;<br />
• Replica Management, si occupa della gestione delle repliche e dell’accesso<br />
fisico all’informazione utilizzando la risoluzione da PRI in URL<br />
fornita da LS;<br />
• Me<strong>di</strong>um Dependent Layer, fornisce il servizio <strong>di</strong> memorizzazione e <strong>di</strong><br />
accesso alle repliche.<br />
La stratificazione ha <strong>di</strong>mostrato, anche in questo caso, <strong>di</strong> fornire <strong>un</strong>’elevata<br />
modularità all’architettura, come è avvenuto nel contesto dell’internetworking;<br />
inoltre ha semplificato la progettazione ed ha fornito garanzie <strong>di</strong><br />
scalabilità. Questi ultimi aspetti sono stati ulteriormente enfatizzati dal para<strong>di</strong>gma,<br />
basato sul web (REST), a cui è stato fatto riferimento per progettare<br />
l’interazione fra i vari layer.<br />
In analogia allo stack TCP/IP, nelle specifiche <strong>di</strong> CISA, non sono stati<br />
posti vincoli relativamente ai livelli Application e Me<strong>di</strong>um Dependent, situati<br />
alle estremità della pila. Questo permetterà al sistema <strong>di</strong> evolvere nel<br />
tempo tramite l’introduzione <strong>di</strong> specifiche implementazioni interne al layer<br />
Application equivalentemente a ciò che è stato fatto per i protocolli <strong>di</strong> livello<br />
applicativo <strong>di</strong> Internet; inoltre, tramite l’implementazione <strong>di</strong> opport<strong>un</strong>i<br />
adattatori interni al layer Me<strong>di</strong>um Dependent, consente l’utilizzo <strong>di</strong> sistemi <strong>di</strong><br />
storage <strong>di</strong>versificati fornendo la stessa flessibilità attualmente presente nella<br />
scelta del mezzo fisico <strong>di</strong> trasporto dei link <strong>di</strong> rete.<br />
È importante sottolineare che ogni fase della progettazione è stata preceduta<br />
da <strong>un</strong>’accurata analisi dello stato dell’arte del settore relativo all’argomento<br />
in esame, al fine <strong>di</strong> ricercare modelli e/o sistemi a cui fare riferimento.<br />
237
Conclusioni<br />
Come già osservato è stato fatto uso dell’approccio stratificato, tipico delle<br />
telecom<strong>un</strong>icazioni, utilizzato per la definizione dello scheletro dell’architettura;<br />
dell’approccio REST per il para<strong>di</strong>gma <strong>di</strong> interazione; dei principi operativi<br />
del DNS (Domain Name System) per la progettazione dei sistemi <strong>di</strong><br />
risoluzione; <strong>di</strong> standard quali XML per la definizione dei modelli dei dati.<br />
Nel presente lavoro <strong>di</strong> tesi, per progettare il versioning in D3IM, si è fatto<br />
riferimento al <strong>modello</strong> UEVM che si è <strong>di</strong>mostrato il più efficiente, efficace<br />
ed evoluto relativamente a questo ambito. Ciò ha permesso la realizzazione<br />
<strong>di</strong> <strong>un</strong> <strong>modello</strong> <strong>di</strong> versioning estensionale che ha il vantaggio <strong>di</strong> consentire il<br />
recupero, in ogni momento, della versione corretta dell’informazione strutturata,<br />
definita in D3IM, esattamente come è stata creata. Si osservi come il<br />
para<strong>di</strong>gma non estensionale, utilizzato per la sua semplicità in altri sistemi<br />
presenti sul mercato, <strong>di</strong>mostri alc<strong>un</strong>i limiti proprio nella gestione degli aspetti<br />
strutturali dell’informazione. Inoltre il versioning estensionale dei documenti<br />
risulta <strong>di</strong> più facile comprensione per l’utente.<br />
D3IM ere<strong>di</strong>ta da UEVM i vantaggi relativi al problema, noto agli esperti<br />
del settore, della gestione dell’esplosione combinatoria delle versioni, fornendo<br />
notevoli garanzie, in termini <strong>di</strong> scalabilità, al crescere della complessità del<br />
documento e del relativo storico.<br />
Attualmente è in atto <strong>un</strong>’implementazione <strong>di</strong> <strong>un</strong>a versione prototipale<br />
dell’architettura, limitata alle f<strong>un</strong>zionalità principali, basata sul framework<br />
progettato in questo lavoro <strong>di</strong> tesi. A tal riguardo è opport<strong>un</strong>o segnalare che<br />
già esistono implementazioni preliminari f<strong>un</strong>zionanti dei server LDNS ed LS.<br />
Si rimanda agli sviluppi futuri il completamento <strong>di</strong> tale implementazione<br />
e la successiva evoluzione destinata agli utilizzatori finali.<br />
In questa seconda fase occorrerà definire meccanismi maggiormente evoluti<br />
atti a migliorare l’architettura da <strong>un</strong> p<strong>un</strong>to <strong>di</strong> vista della sicurezza operativa<br />
che attualmente risulta essere sufficiente per l’implementazione prototipale.<br />
In questo contesto è necessario realizzare anche i sistemi finalizzati al<br />
debugging ed al monitoraggio dell’architettura.<br />
Ulteriori ambiti <strong>di</strong> indagine riguardano stu<strong>di</strong> finalizzati ad evidenziare le<br />
similitu<strong>di</strong>ni fra l’architettura CISA e quella DataGrid ([Dat06]) dato che con<strong>di</strong>vidono<br />
vari obiettivi e principi operativi. Tali similitu<strong>di</strong>ni sono particolarmente<br />
evidenti per quanto riguarda la gestione <strong>di</strong>stribuita delle informazioni<br />
e, nello specifico, i livelli più bassi <strong>di</strong> CISA.<br />
Risulta <strong>di</strong> notevole interesse lo sviluppo dei layer Application e Me<strong>di</strong>um<br />
Dependent in contesti applicativi concreti. Nella tesi <strong>di</strong> laurea dal tito-<br />
238
Conclusioni<br />
lo “Analisi progettuale per la realizzazione <strong>di</strong> <strong>un</strong> sistema fiduciario in rete”([Olm05]),<br />
viene analizzato, con questa prospettiva, il problema del profilo<br />
degli utenti in <strong>un</strong> particolare contesto relativo al turismo.<br />
Riprendendo ed estendendo il lavoro effettuato in [Inn04], altri ambiti <strong>di</strong><br />
interesse riguardano specifiche problematiche inerenti alle Pubbliche Amministrazioni<br />
come, per esempio, la gestione documentale e metadocumentale<br />
degli atti amministrativi.<br />
In generale si possono progettare software <strong>di</strong> livello Application <strong>di</strong> CISA<br />
che implementano le varie f<strong>un</strong>zionalità svolte dai sistemi presenti sul mercato<br />
per l’Enterprise Content Management e/o il Software Configuration<br />
Management.<br />
L’ultimo esempio menzionato riguarda la progettazione e l’implementazione<br />
<strong>di</strong> <strong>un</strong>a piattaforma per l’e-learning: i Learning Objects ([Bia03]) ed i<br />
documenti D3IM infatti con<strong>di</strong>vidono svariate caratteristiche quali i concetti<br />
<strong>di</strong> struttura, <strong>di</strong> aggregazione, <strong>di</strong> riuso dell’informazione, eccetera.<br />
I campi <strong>di</strong> applicazione sono innumerevoli; nel presente lavoro ne sono<br />
stati in<strong>di</strong>cati solo alc<strong>un</strong>i: altri, sulla base <strong>di</strong> interessi contingenti, possono<br />
essere oggetto <strong>di</strong> ulteriori indagini ed approfon<strong>di</strong>menti.<br />
239
Bibliografia<br />
[ABC + 04] Vidur Apparao, Steve Byrne, Mike Champion, Scott Isaacs, Ian Jacobs, Arnaud<br />
Le Hors, Gavin Nicol, Jonathan Robie, Robert Sutorand, Chris Wilson,<br />
Lauren Wood, and Philippe Le Hégaret. DOM: Document Object Model Level<br />
1,2,3. http://www.w3c.org/DOM, 2000-2004.<br />
[ABCM99] Ulf Askl<strong>un</strong>d, Lars Ben<strong>di</strong>x, Henrik B. Christensen, and Boris Magnusson. The<br />
Unified Extensional Versioning Model. Settembre 1999.<br />
[App05] Brad Appleton. SCM Definitions.<br />
http://www.cmcrossroads.com/bradapp/acme/scm-defs.html,<br />
Novembre 2005.<br />
[Ask02] Ulf Askl<strong>un</strong>d. Configuration Management for <strong>di</strong>stribuited development in an<br />
integrated envirnoment. 2002. Tesi <strong>di</strong> Dottorato <strong>di</strong> Ricerca. Department of<br />
Computer Science, L<strong>un</strong>d Institute of Technology, L<strong>un</strong>d University.<br />
[Bia03] Federica Bianchi. Che cosa sono i Learning Object – Articolo tratto dalla tesi<br />
<strong>di</strong> laurea, A.A. 2001/2002. Maggio 2003.<br />
[Bit05] Inc. BitMover. BitKeeper - The Scalable Distributed Software Configuration<br />
Management System. http://www.bitkeeper.com/, Novembre 2005.<br />
[BLFIM98] T. Berners-Lee, R. Fiel<strong>di</strong>ng, U.C. Irvine, and L. Masinter. RFC 2396.<br />
Uniform Resource Identifiers (URI): Generic Syntax. IETF, Agosto 1998.<br />
[BLMM94] T. Berners-Lee, L. Masinter, and M. McCahill. RFC 1738. Uniform Resource<br />
Locators (URL). IETF, Dicembre 1994.<br />
[Bul05] Diamond Bullet. Usability First: Groupware.<br />
http://www.usabilityfirst.com/groupware, 2005.<br />
[Cle95] Gary Cleveland. Overview of Document Management Technology. National<br />
Library of Canada, Giugno 1995.<br />
[CM03] Luca Cappelli and Massimiliano Morbi<strong>di</strong>. Tesi <strong>di</strong> laurea – <strong>Progetto</strong> <strong>di</strong> <strong>un</strong>a<br />
architettura <strong>di</strong>stribuita orientata alla collaborazione. A.A. 2002/2003.
BIBLIOGRAFIA BIBLIOGRAFIA<br />
[Coa06] The Workflow Management Coalition. The Workflow Management Coalition.<br />
http://www,wfmc.org, Marzo 2006.<br />
[Col05a] Inc CollabNet. CollabNet, Inc. http://www.collab.net, Novembre 2005.<br />
[Col05b] Inc. CollabNet. Subversion Home Page.<br />
http://subversion.tigris.org/, Novembre 2005.<br />
[Com05] Compaq. Vesta. http://www.vestasys.org/, Novembre 2005.<br />
[CSFP04] Ben Collins-Sussman, Brian W. Fitzpatrick, and C. Michael Pilato. Version<br />
Control with Subversion, For Subversion 1.1. O’Reilly, Giugno 2004. È stato<br />
rilasciato con licenza “Creative Commons” ed è <strong>di</strong>sponibile all’in<strong>di</strong>rizzo:<br />
http://svnbook.red-bean.com/en/1.1/svn-book.pdf.<br />
[Dan97] R. Daniel. RFC 2169. A Trivial Convention for using HTTP in URN<br />
Resolution. IETF, Giugno 1997.<br />
[Dat06] Wikipe<strong>di</strong>a DataGrid. DataGrid.<br />
http://en.wikipe<strong>di</strong>a.org/wiki/Data grid, Marzo 2006.<br />
[dedF06] Ministero dell’Economia e delle Finanze. Agenzia delle Entrate: home page.<br />
http://www.agenziaentrate.it, Marzo 2006.<br />
[DvGIF99] L. Daigle, D. van Gulik, R. Iannella, and P. Faltstrom. RFC 2611. URN<br />
Namespace Definition Mechanisms. IETF, Giugno 1999.<br />
[DWSC05] M. Duerst, W3C, M. Suignard, and Microsoft Corporation. RFC 3987.<br />
Internationalized Resource Identifiers (IRIs). IETF, Gennaio 2005.<br />
[ESG91] C.A. Ellis and G.L. Rein S.J. Gibbs. Groupware: some issues and experiences.<br />
ACM, Gennaio 1991.<br />
[FB03] Karl Fogel and Moshe Bar. Open Source Development with CVS,<br />
3rd E<strong>di</strong>tion. O’Reilly, Luglio 2003. È stato rilasciato con licenza<br />
“Creative Commons” ed è <strong>di</strong>sponibile all’in<strong>di</strong>rizzo: http://cvsbook.redbean.com/OSDevWithCVS<br />
3E.pdf.<br />
[Fei91] Peter H. Feiler. Configuration Management Models in Commercial Environments.<br />
Software Engineering Institute. Carnegie Mellon University.<br />
Pittsburgh, Pennsylvania 15213, Marzo 1991.<br />
[Fie00] Roy Thomas Fiel<strong>di</strong>ng. Representational State Transfer (REST).<br />
http://www.ics.uci.edu/ fiel<strong>di</strong>ng/pubs/<strong>di</strong>ssertation/rest arch style.htm, Luglio<br />
2000.<br />
[FIG + 99] R. Fiel<strong>di</strong>ng, UC Irvine, J. Gettys, Compaq/W3C, J. Mogul, Compaq, H. Frystyk,<br />
W3C/MIT, L. Masinter, Xerox, P. Leach, Microsoft, T. Berners-Lee,<br />
and W3C/MIT. RFC 2119. Hypertext Transfer Protocol – HTTP/1.1. Giugno<br />
1999.<br />
[Fou04] International DOI Fo<strong>un</strong>dation. The DOI Handbook. http://www.doi.org,<br />
2004.<br />
241
BIBLIOGRAFIA BIBLIOGRAFIA<br />
[Fou05a] Eclipse Fo<strong>un</strong>dation. Eclipse Home page. http://www.eclipse.org, Novembre<br />
2005.<br />
[Fou05b] The Apache Software Fo<strong>un</strong>dation. Apache Portable R<strong>un</strong>time Project.<br />
http://apr.apache.org/, Novembre 2005.<br />
[Fou05c] The Apache Software Fo<strong>un</strong>dation. The Apache Software Fo<strong>un</strong>dation.<br />
http://www.apache.org/, Novembre 2005.<br />
[Fra05] Niccolò Francini. Tesi <strong>di</strong> laurea – Progettazione e sviluppo <strong>di</strong> <strong>un</strong> sistema<br />
<strong>di</strong>stribuito <strong>di</strong> risoluzione <strong>di</strong> nomi logici. A.A. 2004/2005.<br />
[GHJV95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design<br />
Patterns: elements of reusable object-oriented software. Ad<strong>di</strong>son-Wesley,<br />
Massachusetts, USA, 1995.<br />
[Gnu93] Gnu. Gnu man pages “rcsintro”. Novembre 1993.<br />
[Gnu03] Gnu. RCS. http://www.gnu.org/software/rcs/rcs.html, Febbraio 2003.<br />
[Gnu05] Gnu. GNU Arch. http://www.gnu.org/software/gnu-arch/, Novembre 2005.<br />
[Goy06] Jan Goyvaerts. Regular-Expressions.info - Regex Tutorial, Examples and Reference<br />
- Regexp Patterns. http://www.regular-expressions.info/, Febbraio<br />
2006.<br />
[HM02] J. Hodges and R. Morgan. RFC 3377. Lightweight Directory Access Protocol<br />
(v3): Technical Specification. IETF, Settembre 2002.<br />
[IDE05] Wikipe<strong>di</strong>a IDE. IDE, Integrated development environment.<br />
http://en.wikipe<strong>di</strong>a.org/wiki/Integrated development environment, Novembre<br />
2005.<br />
[Inc05] Perforce Software Inc. Perforce. http://www.perforce.com/, Novembre 2005.<br />
[Inn04] Samuele Innocenti. Tesi <strong>di</strong> laurea – Modello dell’informazione per documenti<br />
<strong>di</strong>stribuiti e delocalizzati a supporto della cooperazione applicativa nelle<br />
Pubbliche Amministrazioni. A.A. 2003/2004.<br />
[Ita96] Parlamento Italiano. Legge 31 <strong>di</strong>cembre 1996, n. 675. Tutela delle persone e<br />
<strong>di</strong> altri soggetti rispetto al trattamento dei dati personali. Dicembre 1996.<br />
[Ita03] Governo Italiano. Decreto legislativo 30 giugno 2003, n. 196 - Co<strong>di</strong>ce in<br />
materia <strong>di</strong> protezione dei dati personali. Giugno 2003.<br />
[Kap97] Simon Kaplan. The CSCW: The Quadrant Model of Groupware.<br />
ACM, Agosto 1997.<br />
[Kat90] Randy H. Katz. Toward a Unified Framework for Versioning Modeling in<br />
Engineering Databases. ACM Computing Surveys, Dicembre 1990.<br />
[Kie94] Robert Kiesling. The RCS MINI-HOWTO (ver. 1.4).<br />
http://it.tldp.org/HOWTO/RCS.html, Agosto 1994. Traduzione a cura <strong>di</strong><br />
Fabrizio Stefani, luglio 1999.<br />
242
BIBLIOGRAFIA BIBLIOGRAFIA<br />
[KR03] James F. Kurose and Keith W. Ross. Internet e reti <strong>di</strong> calcolatori.<br />
McGraw-Hill, 2003.<br />
[Lin05] Redazione LinuxPro. Tutorial Subversion. LinuxPro, n.31,32,33, Settembre,<br />
Ottobre, Novembre 2005.<br />
[lK05] Chia liang Kao. Svk. http://svk.elixus.org/, Novembre 2005.<br />
[LPD98] C. Lynch, C. Preston, and R. Daniel. RFC 2288. Using Existing Bibliographic<br />
Identifiers as Uniform Resource Names. IETF, Febbraio 1998.<br />
[Ltd05a] Canonical Ltd. Bazaar-NG: next-generation <strong>di</strong>stributed version control.<br />
http://www.bazaar-ng.org/, Novembre 2005.<br />
[Ltd05b] PureCM.com Ltd. PureCM. http://www.purecm.com/, Novembre 2005.<br />
[MD00] Sergey Melnik and Stefan Decker. A Layered Approach to Information<br />
Modeling and Interoperability on the Web. Settembre 2000.<br />
[Mic05] Microsoft. Visual SourceSafe.<br />
http://msdn.microsoft.com/vstu<strong>di</strong>o/previous/ssafe/, Novembre 2005.<br />
[Mil05] Peter Miller. Aegis. http://aegis.sourceforge.net/, Novembre 2005.<br />
[MO94] M<strong>un</strong>ir Mandvwalla and Lorne Olfman. What Do Groups Need? A Proposed<br />
Set of Generic Groupware Requirements. ACM, Settembre 1994.<br />
[Moa97] R. Moats. RFC 2141. URN syntax. IETF, Maggio 1997.<br />
[Moc87a] P. Mockapetris. RFC 1034. Domain Names - Concepts and Facilities.<br />
IETF, Novembre 1987.<br />
[Moc87b] P. Mockapetris. RFC 1035. Domain Names - Implementation and<br />
specification. IETF, Novembre 1987.<br />
[Mon05] Team Monotone. Monotone. http://venge.net/monotone/, Novembre 2005.<br />
[Olm05] Riccardo Olmi. Tesi <strong>di</strong> laurea – Analisi progettuale per la realizzazione <strong>di</strong> <strong>un</strong><br />
sistema fiduciario in rete. A.A. 2004/2005.<br />
[Ope05] Team OpenBSD. OpenSSH.<br />
http://www.openssh.com/it/index.html, Novembre 2005.<br />
[Por06] Wikipe<strong>di</strong>a Portabilità. Portabilità.<br />
http://it.wikipe<strong>di</strong>a.org/wiki/Porting, Febbraio 2006.<br />
[Pra03] A. Prass. RFC3444. On the Difference between Information Models and Data<br />
Models. IETF, Gennaio 2003.<br />
[Rei05] Stefan Reich. Sperversion. http://www.superversion.org/, Novembre 2005.<br />
[Res05] Wikipe<strong>di</strong>a Rest. Representational State Transfer (REST).<br />
http://en.wikipe<strong>di</strong>a.org/wiki/REST, Luglio 2005.<br />
[RJB99] James Rumbaugh, Ivar Jacobson, and Grady Booch. The Unified Modeling<br />
Language Reference Manual. Ad<strong>di</strong>son-Wesley, 1999.<br />
243
BIBLIOGRAFIA BIBLIOGRAFIA<br />
[Rob06] James Robertson. Is it document management or content management?<br />
Step Two Design, Febbraio 2006.<br />
[Rou05] David Ro<strong>un</strong>dy. Darcs. http://abridgegame.org/darcs/, Novembre 2005.<br />
[RS05] IBM Rational Software. Rational ClearCase.<br />
http://www-306.ibm.com/software/awdtools/clearcase/, Novembre 2005.<br />
[SM94] K. Sollins and L. Masinter. RFC 1737. F<strong>un</strong>ctional Requirements for Uniform<br />
Resource Names. IETF, Dicembre 1994.<br />
[Sof05] Reliable Software. Code Co-op Distributed Version Control System.<br />
http://www.relisoft.com/, Novembre 2005.<br />
[Sol98] K. Sollins. RFC 2276. Architectural Principles of Uniform Resource Name<br />
Resolution. IETF, Gennaio 1998.<br />
[SVLF05] Jonathan S. Shapiro, John Vanderburgh, Jack Lloyd, and Todd Fries.<br />
OpenCM. http://www.opencm.org/, Novembre 2005.<br />
[TS06] Marco Trevisan and Roberto Scano. Web accessibile e accessibilità dei siti<br />
internet - Webaccessibile.org. http://www.webaccessibile.org/, Marzo 2006.<br />
[TW97] Andrew S. Tanenbaum and Albert S. Woodhull. Operating Systems. Design<br />
and Implementation. Second E<strong>di</strong>tion. Prentice Hall, Gennaio 1997.<br />
[WCJRg03] J. Whitehead, U.C. Santa Cruz, Ed. J. Reschke, and greenbytes. RFC 3648.<br />
Web Distributed Authoring and Versioning (WebDAV). Ordered Collections<br />
Protocol. Dicembre 2003.<br />
[Whe05] David Wheeler. Comments on Open Source Software / Free Software<br />
(OSS/FS) Software Configuration Management (SCM) Systems.<br />
http://www.dwheeler.com/essays/scm.html, Maggio 2005.<br />
244
Accurate, 98, 100<br />
Albero, 82<br />
Albero <strong>di</strong> zone, 203<br />
Allowable, 98, 99<br />
Ambiente <strong>di</strong> sviluppo integrato,<br />
ve<strong>di</strong> IDE<br />
anatomico, Modello, 16<br />
Application Layer, 108<br />
architetturale, Modello, 16<br />
Authoring, 3<br />
Avatar, 65, 67<br />
Awareness, 7<br />
B LAST, 156<br />
B ROOT, 154<br />
BitKeeper, 59<br />
Blocco, ve<strong>di</strong> Lock<br />
BRANCH, 163<br />
Branch, 25<br />
Change set, 28<br />
Changing, 91<br />
Checkout/Checkin, 26<br />
CISA, Collaborative Information System<br />
Architecture, 104<br />
CM, Configuration Management, 19<br />
CM, Content Management, 4<br />
CMS, Content Management Systems, 4<br />
COMMIT, 161<br />
Commit, 50<br />
Composizione, 26<br />
Configuration, 18<br />
In<strong>di</strong>ce analitico<br />
Configuration Management Systems, 20<br />
Configurazione, 18<br />
Conflitto, 50<br />
conservativa, Strategia, 17<br />
conservativo, Lock, 18<br />
Consistency, 100<br />
Consumer, 65<br />
Convergenza, ve<strong>di</strong> Merge<br />
COOP/Orm, 56<br />
copy-merge, Modello, 17<br />
CREATE, 162, 168<br />
CSCW, Computer-Supported Cooperative<br />
Work, 6<br />
CVS, 49<br />
D3IM, Distributed Delocalized Document<br />
Information Model, 78<br />
DAG, 40<br />
Data model, 77<br />
Delivery dell’informazione, 73<br />
Diramazione, 25<br />
DM, Document Management, 3<br />
DMS, Document Management Systems, 4<br />
DNS, Domain Name System, 194<br />
Documento, 77<br />
Documento strutturato, 80<br />
Draft, 98, 99<br />
ECM, Enterprise Content Management, 5<br />
estensionale, Modello <strong>di</strong> versioning, 32<br />
Foresta, 82<br />
Frozen, 91<br />
245
INDICE ANALITICO INDICE ANALITICO<br />
Gestione dello storico, 128<br />
GET, 159, 165<br />
Git, 60<br />
Good enough, 104<br />
Group, 66, 68<br />
Groupware, 6<br />
groupware, Progettazione <strong>di</strong>, 10<br />
groupware, Requisiti per sistemi, 13<br />
H GRAPH, 156<br />
H ROOT, 154<br />
HFN, Human Friendly Name, 86<br />
HFN, Requisiti <strong>di</strong>, 195<br />
IACS, Inter-Application Comm<strong>un</strong>ication<br />
System, 226<br />
IDE, Integrated Development<br />
Environments, 57<br />
Information hi<strong>di</strong>ng, 104<br />
Information Model, 77<br />
Informazione atomica, 81, 86<br />
Informazione primitiva, 81, 88<br />
informazione, Delivery, 73<br />
intensionale, Modello <strong>di</strong> versioning, 30<br />
Interazione:<br />
asincrona, 7<br />
molti a molti, 70<br />
molti a <strong>un</strong>o, 70<br />
sincrona, 7<br />
<strong>un</strong>o a molti, 70<br />
<strong>un</strong>o a <strong>un</strong>o, 70<br />
Interdataworking, 104<br />
Interfaccia bi<strong>di</strong>mensionale, ve<strong>di</strong> IACS<br />
Lavoro collaborativo, 6<br />
Lavoro:<br />
in gruppi localizzati, 9<br />
a <strong>di</strong>stanza, 8<br />
in appalto, 9<br />
in gruppi <strong>di</strong>stribuiti, 9<br />
Layer, 105<br />
Layer:<br />
Application, 108<br />
Me<strong>di</strong>um Dependent, 115<br />
Replica Management, 112<br />
Structure, 112<br />
Virtual Repository , 108<br />
LDNS, Logical Domain Name System, 202<br />
Link:<br />
<strong>di</strong> composizione, 90<br />
<strong>di</strong> propagazione, 131<br />
<strong>di</strong> riferimento, 90<br />
<strong>di</strong> versione, 132<br />
Livello, 105<br />
LNS, Logical Name Server, 203<br />
LNSP, Logical Name Space, 202<br />
LOCK, 166<br />
Lock:<br />
conservativo, 18<br />
ottimistico, 18<br />
pessimistico, 18<br />
LOCKED SOFT, 164<br />
LOCKED STRONG, 164<br />
look-ahead, Risoluzione con, 206<br />
look-ahead, Risoluzione senza, 205<br />
LRI, Logical Resource Identifier, 86, 197<br />
LS, Localization Service, 213<br />
Management, 65<br />
MARK, 163<br />
Me<strong>di</strong>um Dependent Layer, 115<br />
MERGE, 164<br />
Merge, 25<br />
Metadati, 18<br />
Modello:<br />
anatomico, 16<br />
architetturale, 16<br />
copy-merge, 17<br />
del documento <strong>di</strong> UEVM, 34<br />
split-combine, 17<br />
turn-taking, 17<br />
versioning estensionale, 32<br />
versioning intensionale, 30<br />
Navigazione, 151<br />
Navigazione nello storico, 128<br />
notifica, Meccanismo <strong>di</strong>, 107<br />
NULL, 164<br />
OBSERVED, 164<br />
246
INDICE ANALITICO INDICE ANALITICO<br />
ottimistica, Strategia, 17<br />
ottimistico, Lock, 18<br />
Parametro <strong>di</strong> versione, 152<br />
pessimistico, Lock, 18<br />
Polytree, 82<br />
PRI, Persistent Resource Identifier, 84, 199<br />
Processo, 118<br />
Producer, 65<br />
Propagazione, 133<br />
propagazione, Link <strong>di</strong>, 131<br />
Protocollo con delega, 232<br />
PUT, 167<br />
R PREV, 154<br />
RCS, 45<br />
RELAXED, 164<br />
relaxed, Politica, 96<br />
Replica Management Layer, 112<br />
Repository, 46<br />
Responsabile, 81<br />
REST, Representational State Transfer, 106<br />
Revisione, 24, 92<br />
Risoluzione inversa, 215<br />
Routing delle richieste, 231<br />
SCM, Software Configuration Management,<br />
ve<strong>di</strong> CM<br />
Separation of concern, 104<br />
Servizio, 118<br />
Sistemi basati su:<br />
stato, 33<br />
variazioni, 32<br />
soft, Politica, 96<br />
split-combine, Modello, 17<br />
stato, Sistemi basati su, 33<br />
Storico, 91<br />
Strategia:<br />
conservativa, 17<br />
ottimistica, 17<br />
strong, Politica, 95<br />
Structure Layer, 112<br />
Stuff, 66, 69<br />
Subversion, 53<br />
Svk, 61<br />
T ABSLAST, 154<br />
T RELATLAST, 154<br />
Tagging, 26<br />
Tipologia <strong>di</strong> documento, 18<br />
Transazioni estese nel tempo, 27<br />
turn-taking, Modello, 17<br />
UEVM, 33<br />
UNLOCK, 168<br />
Update, 91<br />
URI, Uniform Resource Identifiers, 83<br />
URL, Uniform Resource Locator, 83<br />
URN, Requisiti <strong>di</strong>, 195<br />
URN, Uniform Resource Name, 84<br />
Variante, 25<br />
variazioni, Sistemi basati su, 32<br />
Versione, 91<br />
versione, Link <strong>di</strong>, 132<br />
Virtual Repository Layer, 108<br />
WebDAV, 44<br />
Workflow, 3<br />
World, 65, 68<br />
Zona, 202<br />
247