12.06.2013 Views

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

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

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 />