Progetto di un modello dell'informazione versionata e ... - InterDataNet

UNIVERSITÀ DEGLI STUDI DI FIRENZE
Facoltà di Ingegneria
Dipartimento di Elettronica e Telecomunicazioni
Corso di Laurea in
Ingegneria delle Telecomunicazioni P.O.
Progetto di un modello
dell’informazione versionata e di
un’architettura di rete finalizzati
al lavoro collaborativo
Relatori
Prof. Franco Pirri
Prof. Dino Giuli
Tesi di Laurea di
Davide Chini
Correlatori
Anno Accademico 2004/2005
Ing. Samuele Innocenti
Ing. Maria Chiara Pettenati

Ringraziamenti
Ringrazio il Prof. Franco Pirri ed il Prof. Dino Giuli per avermi fornito
l’opportunità di svolgere il presente lavoro e per la disponibilità dimostrata
nei miei confronti.
I miei ringraziamenti vanno inoltre all’Ing. Samuele Innocenti per tutto
il tempo che mi ha dedicato, il supporto morale, la competenza nel settore
messa a disposizione e l’ottimo rapporto di collaborazione instaurato che ha
guidato positivamente il mio lavoro.
Ringrazio l’Ing. Maria Chiara Pettenati per i preziosi consigli e la disponibilità
che mi ha concesso.
Grazie a tutte le persone presenti nel “Laboratorio di Tecnologie della
Telematica” per gli ottimi rapporti stabiliti che mi hanno garantito una
condizione di assoluta serenità durante lo svolgimento della tesi e un grazie
particolare a Luca Capannesi per l’indispensabile supporto tecnico.
Un pensiero particolare va ai miei familiari: mi sono sempre stati vicini
con tanto affetto e comprensione. La gioia che provo, a conclusione del mio
percorso di studi, so che è dovuta anche a loro.
L’ultimo ringraziamento è per Michela che ha condiviso con me questo
periodo così impegnativo, pieno di momenti difficili e di rinunce ma anche di
grandi soddisfazioni.
Firenze, 13 Aprile 2006
Davide Chini

Everything should be made as simple as possible,
but not one bit simpler.
Attributed to Albert Einstein

Ai miei genitori

Indice
Introduzione xiii
I Analisi del versioning in ambienti collaborativi 1
1 Cooperazione e collaborazione nelle organizzazioni 2
1.1 La gestione dei documenti . . . . . . . . . . . . . . . . . . . . 3
1.2 Il lavoro collaborativo . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Progettazione di groupware . . . . . . . . . . . . . . . 10
1.2.2 I gruppi e la collaborazione . . . . . . . . . . . . . . . 11
1.2.3 Requisiti generali per sistemi groupware . . . . . . . . 13
1.2.4 Modelli di lavoro . . . . . . . . . . . . . . . . . . . . . 16
1.3 Il concetto di configurazione . . . . . . . . . . . . . . . . . . . 18
2 Versioning a supporto della collaborazione 23
2.1 Il controllo delle versioni . . . . . . . . . . . . . . . . . . . . . 24
2.2 Modelli di sincronizzazione . . . . . . . . . . . . . . . . . . . . 25
2.2.1 Checkout/Checkin . . . . . . . . . . . . . . . . . . . . 26
2.2.2 Composizione . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.3 Transazioni estese nel tempo . . . . . . . . . . . . . . . 27
2.2.4 Change set . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3 Modelli di versioning . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.1 Modello intensionale . . . . . . . . . . . . . . . . . . . 30
2.3.2 Modello estensionale . . . . . . . . . . . . . . . . . . . 32
2.3.3 Valutazione dei modelli . . . . . . . . . . . . . . . . . . 32

Indice
2.3.4 Una nuova alternativa: UEVM . . . . . . . . . . . . . 33
2.4 Unified Extensional Versioning Model . . . . . . . . . . . . . . 33
2.4.1 Il modello . . . . . . . . . . . . . . . . . . . . . . . . . 34
Il modello del documento . . . . . . . . . . . . . . . . . 34
Esempio di documento strutturato . . . . . . . . . . . 38
Versioning . . . . . . . . . . . . . . . . . . . . . . . . . 39
Versioning di un singolo documento . . . . . . . . . . . 41
Versioning di più documenti legati fra loro . . . . . . . 42
2.4.2 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . 43
UEVM dal punto di vista dell’utente . . . . . . . . . . 43
Gestione dell’esplosione combinatoria . . . . . . . . . . 43
2.5 WebDAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.6 Revision Control System (RCS) . . . . . . . . . . . . . . . . . 45
2.7 Concurrent Versions System (CVS) . . . . . . . . . . . . . . . 49
2.7.1 CVS, evoluzione di RCS . . . . . . . . . . . . . . . . . 49
2.7.2 Concetti di base . . . . . . . . . . . . . . . . . . . . . . 49
Revisioni, branch e configurazioni . . . . . . . . . . . . 51
2.8 Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.8.1 Concetti di base . . . . . . . . . . . . . . . . . . . . . . 55
Numerazione esplicita delle configurazioni . . . . . . . 55
2.9 L’ambiente integrato COOP/Orm . . . . . . . . . . . . . . . . 56
2.9.1 Ambienti di sviluppo integrati . . . . . . . . . . . . . . 56
2.9.2 Da Orm a COOP/Orm . . . . . . . . . . . . . . . . . . 57
2.10 Sistemi di versioning peer-to-peer . . . . . . . . . . . . . . . . 59
2.11 Valutazioni comparative . . . . . . . . . . . . . . . . . . . . . 61
II Ambiente virtuale e modello dell’informazione 63
3 Modello dell’ambiente virtuale 64
3.1 Rappresentazione dell’ambiente . . . . . . . . . . . . . . . . . 65
3.1.1 Le entità . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Avatar . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Group . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
World . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Stuff . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.2 Il modello delle interazioni . . . . . . . . . . . . . . . . . . . . 70
v

Indice
3.2.1 Prima fase dell’interazione . . . . . . . . . . . . . . . . 72
3.2.2 Seconda fase dell’interazione . . . . . . . . . . . . . . . 72
3.3 Il delivery dell’informazione . . . . . . . . . . . . . . . . . . . 73
4 Modello dell’informazione versionata D3IM 77
4.1 Principi di strutturazione . . . . . . . . . . . . . . . . . . . . . 79
4.1.1 Il concetto di responsabilità . . . . . . . . . . . . . . . 81
4.2 I nodi informativi del documento . . . . . . . . . . . . . . . . 81
4.2.1 Identificazione dei nodi e relativo accesso . . . . . . . . 82
4.2.2 Informazioni atomiche . . . . . . . . . . . . . . . . . . 86
4.2.3 Informazioni primitive . . . . . . . . . . . . . . . . . . 88
4.3 Relazioni fra i nodi informativi . . . . . . . . . . . . . . . . . 90
4.4 Storico dei documenti . . . . . . . . . . . . . . . . . . . . . . . 91
4.4.1 La propagazione delle modifiche . . . . . . . . . . . . . 93
4.4.2 Authoring concorrente . . . . . . . . . . . . . . . . . . 94
Controllo delle sessioni . . . . . . . . . . . . . . . . . . 95
4.5 Lo stato di un documento . . . . . . . . . . . . . . . . . . . . 98
4.5.1 Lo stato delle informazioni . . . . . . . . . . . . . . . . 98
Lo stato delle informazioni atomiche . . . . . . . . . . 98
Lo stato delle informazioni primitive . . . . . . . . . . 99
III Dai modelli teorici all’architettura concreta 102
5 Architettura CISA 103
5.1 Visione stratificata di CISA . . . . . . . . . . . . . . . . . . . 104
5.1.1 Application Layer . . . . . . . . . . . . . . . . . . . . . 108
5.1.2 Virtual Repository Layer . . . . . . . . . . . . . . . . . 108
Operazioni di base sulle entità . . . . . . . . . . . . . . 109
5.1.3 Structure Layer . . . . . . . . . . . . . . . . . . . . . . 112
5.1.4 Replica Management Layer . . . . . . . . . . . . . . . 112
5.1.5 Medium Dependent Layer . . . . . . . . . . . . . . . . 115
5.2 CISA, sistema distribuito . . . . . . . . . . . . . . . . . . . . . 115
5.2.1 Control Plane . . . . . . . . . . . . . . . . . . . . . . . 116
5.3 Definizione di livelli, servizi e processi . . . . . . . . . . . . . . 117
vi

Indice
6 Versioning in CISA 126
6.1 Da D3IM al versioning in CISA . . . . . . . . . . . . . . . . . 127
6.2 Lo storico in CISA . . . . . . . . . . . . . . . . . . . . . . . . 128
6.2.1 La struttura dello storico . . . . . . . . . . . . . . . . . 128
D3IM nel layer Structure . . . . . . . . . . . . . . . . . 129
6.2.2 Relazioni fra nodi di livello Structure . . . . . . . . . . 130
6.2.3 Gestione delle revisioni: la propagazione . . . . . . . . 133
Propagazione “push” e propagazione “pull” . . . . . . . 135
6.2.4 Branching e merging . . . . . . . . . . . . . . . . . . . 138
Richiami di branching e merging in Subversion . . . . . 139
Branching da D3IM a CISA . . . . . . . . . . . . . . . 141
Merging da D3IM a CISA . . . . . . . . . . . . . . . . 145
Gestione degli aspetti strutturali del documento . . . . 149
6.2.5 La navigazione nello storico . . . . . . . . . . . . . . . 151
6.2.6 I parametri di versione . . . . . . . . . . . . . . . . . . 153
7 Il servizio fornito dal layer Structure 157
7.1 Interfacce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
7.1.1 Interfaccia mostrata a Virtual Repository . . . . . . . . 159
7.1.2 Interfaccia fornita da Replica Management . . . . . . . 165
7.2 La struttura dati interna a Structure . . . . . . . . . . . . . . 169
7.2.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . 169
7.2.2 Descrizione dello XML Schema . . . . . . . . . . . . . 173
7.3 Introduzione agli algoritmi . . . . . . . . . . . . . . . . . . . . 180
7.3.1 Accesso ai documenti . . . . . . . . . . . . . . . . . . . 181
7.3.2 Uso del parametro di versione . . . . . . . . . . . . . . 181
Accesso alla versione . . . . . . . . . . . . . . . . . . . 182
7.3.3 Modifica di documenti . . . . . . . . . . . . . . . . . . 186
Il concetto di sessione . . . . . . . . . . . . . . . . . . . 191
Servizi di branching e di merging . . . . . . . . . . . . 191
8 Il servizio di risoluzione dei nomi 193
8.1 Requisiti dei nomi . . . . . . . . . . . . . . . . . . . . . . . . . 194
8.1.1 Requisiti per gli HFN . . . . . . . . . . . . . . . . . . . 195
8.1.2 Requisiti per gli URN . . . . . . . . . . . . . . . . . . 195
Requisiti non funzionali . . . . . . . . . . . . . . . . . 196
8.1.3 Requisiti sulla codifica . . . . . . . . . . . . . . . . . . 197
vii

Indice
8.2 LRI: gli identificatori logici delle risorse . . . . . . . . . . . . . 197
8.3 PRI: gli identificatori persistenti . . . . . . . . . . . . . . . . . 199
8.4 Logical DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
8.4.1 Supporto alla navigazione . . . . . . . . . . . . . . . . 210
8.4.2 Espansione del Logical Name Space . . . . . . . . . . . 210
Aggiornamento del database . . . . . . . . . . . . . . . 212
8.4.3 Proprietà . . . . . . . . . . . . . . . . . . . . . . . . . 213
8.5 Localization Service . . . . . . . . . . . . . . . . . . . . . . . . 213
8.6 Risoluzione inversa . . . . . . . . . . . . . . . . . . . . . . . . 215
8.7 Ottimizzare le prestazioni . . . . . . . . . . . . . . . . . . . . 221
9 Protocolli di comunicazione e architettura di rete in CISA 222
9.1 Interfacce e protocolli . . . . . . . . . . . . . . . . . . . . . . . 222
9.1.1 Interfaccia bidimensionale . . . . . . . . . . . . . . . . 225
9.2 L’architettura di rete . . . . . . . . . . . . . . . . . . . . . . . 229
9.2.1 Routing delle richieste . . . . . . . . . . . . . . . . . . 231
9.2.2 Protocollo con delega . . . . . . . . . . . . . . . . . . . 232
Conclusioni 235
Bibliografia 240
Indice analitico 245
viii

Elenco delle figure
1.1 Gli strati di supporto alla collaborazione. . . . . . . . . . . . . 12
1.2 Albero ottenibile dalla definizione ricorsiva di configurazione. . 20
2.1 Rappresentazione della storia delle versioni. . . . . . . . . . . 25
2.2 Paradigma di interazione. . . . . . . . . . . . . . . . . . . . . 27
2.3 Esempi di applicazione della grammatica. . . . . . . . . . . . . 37
2.4 Esempi di documento. . . . . . . . . . . . . . . . . . . . . . . 38
2.5 Altri esempi di documenti strutturati: un libro e del codice
Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.6 Alcuni cambiamenti all’interno della stessa sessione. . . . . . . 41
2.7 La modifica di un link genera la nascita di una nuova versione
del documento. . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.8 Gestione delle configurazioni in RCS. . . . . . . . . . . . . . . 47
2.9 Evoluzione delle versioni in Subversion. . . . . . . . . . . . . . 56
2.10 Topologie a stella ed albero. . . . . . . . . . . . . . . . . . . . 60
3.1 Ruoli degli attori dell’ambiente virtuale. . . . . . . . . . . . . 66
3.2 Il modello di interazione. . . . . . . . . . . . . . . . . . . . . . 71
3.3 La notifica delle modifiche. . . . . . . . . . . . . . . . . . . . . 75
4.1 Documento D3IM: DAG ed albero associato. . . . . . . . . . . 83
4.2 Nomi di risorse replicate. . . . . . . . . . . . . . . . . . . . . . 85
4.3 Stato “Update” delle informazioni. . . . . . . . . . . . . . . . . 92
4.4 Generazione delle revisioni. . . . . . . . . . . . . . . . . . . . . 93
4.5 Casi di authoring concorrente. . . . . . . . . . . . . . . . . . . 95
4.6 Stati di un’informazione atomica. . . . . . . . . . . . . . . . . 99

Elenco delle figure
4.7 Stati di un’informazione primitiva. . . . . . . . . . . . . . . . 100
5.1 Livelli dell’architettura CISA. . . . . . . . . . . . . . . . . . . 105
5.2 Paradigma di interazione request/response. . . . . . . . . . . . 107
5.3 La pila CISA più nel dettaglio. . . . . . . . . . . . . . . . . . 116
5.4 Livelli, servizi e processi. . . . . . . . . . . . . . . . . . . . . . 121
6.1 Nodi di livello Structure. . . . . . . . . . . . . . . . . . . . . . 130
6.2 Gestione dei link di propagazione. . . . . . . . . . . . . . . . . 131
6.3 Concessione dei diritti di modifica a tutti i responsabili nella
gerarchia di successori. . . . . . . . . . . . . . . . . . . . . . . 137
6.4 Organizzazione tipica di un progetto gestito con Subversion. . 140
6.5 Risultato della copia di un file in Subversion: branch in D3IM. 143
6.6 Risultato della copia di una directory in Subversion. . . . . . . 144
6.7 Branch in D3IM con un figlio condiviso. . . . . . . . . . . . . 145
6.8 Propagazione in presenza di un figlio condiviso. . . . . . . . . 145
6.9 Merge di due nodi. . . . . . . . . . . . . . . . . . . . . . . . . 147
6.10 Propagazione a seguito di un merge. . . . . . . . . . . . . . . 148
6.11 Gestione di due rami di sviluppo concorrente. . . . . . . . . . 149
6.12 Branch di un intero documento. . . . . . . . . . . . . . . . . . 151
6.13 Sintassi degli indirizzi di livello Structure. . . . . . . . . . . . 152
6.14 Esempio di elemento più recente relativamente al nodo di partenza.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.15 Esempi di “last” relativi al branch. . . . . . . . . . . . . . . . . 155
7.1 Casi d’uso relativi all’interfaccia mostrata da Structure a Virtual
Repository. . . . . . . . . . . . . . . . . . . . . . . . . . . 160
7.2 Casi d’uso relativi all’interfaccia mostrata a Structure da Repository
Management. . . . . . . . . . . . . . . . . . . . . . . 166
7.3 Albero del XML Schema: visione globale. . . . . . . . . . . . . 174
7.4 Albero del XML Schema: particolare dei link di versione. . . . 175
7.5 XML Schema che rappresenta gli indirizzi PRI. . . . . . . . . 175
7.6 Espressione regolare che definisce gli identificativi di versione. 177
7.7 Convenzione sui nomi dei nodi relativi allo storico. . . . . . . . 178
7.8 Accesso al nodo “last” in tempo costante. . . . . . . . . . . . . 183
7.9 Diagramma di sequenza relativo all’accesso ad un documento. 185
7.10 Diagramma di sequenza relativo alla prenotazione per la modifica
di un documento. . . . . . . . . . . . . . . . . . . . . . . 188
x

Elenco delle figure
7.11 Diagramma di sequenza relativo alla richiesta di salvataggio
di un documento. . . . . . . . . . . . . . . . . . . . . . . . . . 190
8.1 Sintassi dei Logical Name. . . . . . . . . . . . . . . . . . . . . 198
8.2 Espressione regolare che definisce i PRI in CISA. . . . . . . . 199
8.3 Sintassi dei PRI in CISA espressa tramite BNF. . . . . . . . . 200
8.4 Associazione tra LRI, PRI ed URL. . . . . . . . . . . . . . . . 201
8.5 Esempio di Logical Name Space. . . . . . . . . . . . . . . . . . 202
8.6 Esempio di suddivisione in zone del LNSP. . . . . . . . . . . . 204
8.7 Esempio di albero delle zone. . . . . . . . . . . . . . . . . . . 204
8.8 Risoluzione senza Look-Ahead. . . . . . . . . . . . . . . . . . 206
8.9 Risoluzione con Look-Ahead. . . . . . . . . . . . . . . . . . . . 206
8.10 Richieste ricorsive per la risoluzione. . . . . . . . . . . . . . . 209
8.11 Esempio di LS. . . . . . . . . . . . . . . . . . . . . . . . . . . 214
8.12 Schema per la risoluzione inversa. . . . . . . . . . . . . . . . . 215
8.13 Tabelle necessarie per la risoluzione inversa iterativa. . . . . . 218
9.1 Bidimensionalità dell’interfaccia fra processi. . . . . . . . . . . 223
9.2 Inter-Application Communication System. . . . . . . . . . . . 227
9.3 Esempio di scenario di utilizzo di CISA. . . . . . . . . . . . . 230
9.4 Esempio di interazione con protocollo con delega. . . . . . . . 233
xi

Elenco delle tabelle
1.1 Modello Johansen. . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Requisiti per sistemi groupware. . . . . . . . . . . . . . . . . . 13
1.3 Struttura e dati di un documento. . . . . . . . . . . . . . . . . 19
2.1 Approcci di versioning adottati dai CM sui vari tipi di entità. 34
2.2 Grammatica che definisce la struttura del documento. . . . . . 35
4.1 Mappa per la determinazione degli stati. . . . . . . . . . . . . 101
5.1 Decomposizione dei ruoli degli utenti. . . . . . . . . . . . . . . 109

Introduzione
Le tecnologie telematiche hanno radicalmente trasformato, e lo stanno
facendo tuttora, tutti i processi aziendali ed i vari paradigmi operativi dando
vita ad una nuova concezione di lavoro collaborativo. Questi cambiamenti
sono avvenuti grazie alle capacità di elaborazione dei calcolatori elettronici
ed a quelle di scambio di informazioni fornite dalle reti di telecomunicazione.
Tali caratteristiche sono state ampiamente sfruttate per realizzare sistemi
finalizzati al supporto della collaborazione.
Nello sviluppo di un progetto collaborativo è possibile ottenere notevoli
vantaggi mantenendo sotto il controllo delle versioni le varie fasi evolutive
del lavoro effettuato ovvero applicando tecniche, più o meno sofisticate, di
versioning.
Il versioning consiste nell’archiviare opportune informazioni al fine di
poter ripercorrere tutte le tappe che hanno contribuito al raggiungimento
dei risultati attuali. Questo consente, ad esempio, di ripristinare il progetto
sulla base di uno stato evolutivo precedente al fine di annullare operazioni che
hanno indirizzato lo sviluppo verso risultati non soddisfacenti.
I benefici sono più che evidenti nel caso in cui i risultati raggiunti siano
il frutto della collaborazione di un insieme eterogeneo di individui che
si differenziano in base alle loro caratteristiche e professionalità, ma anche
relativamente al luogo e all’istante temporale in cui operano. In tal caso il
versioning permette di tracciare le azioni dei vari utenti al fine di rendere
ogni individuo maggiormente responsabile e consapevole del lavoro svolto. In
questo modo si contribuisce ad incrementare il grado di conoscenza che ognuno
ha sul proprio lavoro, su quello degli altri ed in generale sullo stato globale
del progetto (awareness).

Introduzione
Non deve sorprendere che, lavorando quotidianamente con questi strumenti,
i primi sistemi di controllo delle versioni si siano sviluppati nell’ambito
dell’ingegneria del software per il supporto allo sviluppo di codice sorgente.
Il motivo è comprensibile in quanto gli esperti del settore hanno avuto sia la
necessità di dover lavorare con strumenti finalizzati alla collaborazione che le
capacità di realizzarli.
Naturalmente sono stati sviluppati anche sistemi finalizzati ad essere utilizzati
in ambienti del tutto estranei allo sviluppo del software, con l’intento
di supportare tutti i processi aziendali come quelli, ad esempio, commerciali,
amministrativi o produttivi. Normalmente questi ambienti di lavoro
forniscono molte altre funzionalità in aggiunta al versioning, come la gestione
avanzata degli utenti e dei loro diritti; l’archiviazione, l’indicizzazione e la
condivisione dei documenti; l’utilizzo di lavagne condivise e di altri strumenti
per la comunicazione in tempo reale ed asincrona.
Questi sistemi possono essere suddivisi in opportune categorie che dipendono
dalle funzionalità peculiari che offrono. Si parla ad esempio di Document
Management Systems (DMS) nel caso in cui la principale caratteristica sia
quella di archiviare ed indicizzare documenti intesi nel senso convenzionale
del termine e gestirne il relativo workflow. I Content Management Systems
(CMS) differiscono dai precedenti in quanto il concetto di documento
scompare a favore della definizione di un formato dell’informazione interno
al sistema stesso. Recentemente è stato introdotto il concetto di Enterprise
Content Management (ECM ) che rappresenta un insieme di tecnologie
finalizzate all’acquisizione, gestione, memorizzazione e distribuzione di contenuti
informativi e documenti relativi a tutti i processi organizzativi. In
questi termini i sistemi per l’ECM risultano quelli più generali e si inquadrano
principalmente nel contesto delle grandi organizzazioni, nelle quali le
problematiche menzionate risultano particolarmente evidenti.
Tutti i sistemi che rientrano nelle categorie precedenti trattano e gestiscono
le informazioni definite secondo specifiche diverse perché sebbene esista
uno standard per l’infrastruttura di comunicazione tra piattaforme eterogenee
(TCP/IP), altrettanto non si può dire per la rappresentazione dell’informazione.
In generale ogni contesto organizzativo definisce una propria
rappresentazione per la base di conoscenza e questo impedisce il completo
interscambio dei dati. Una possibile soluzione finalizzata a definire una
rappresentazione omogenea dell’informazione viene discussa nella dissertazione
di laurea [Inn04] dal titolo “Modello dell’informazione per documen-
xiv

Introduzione
ti distribuiti e delocalizzati a supporto della cooperazione applicativa nelle
Pubbliche Amministrazioni”, nella quale viene analizzato lo scenario che si
presenta nelle Pubbliche Amministrazioni (P.A.). Le P.A. sono particolari
enti distribuiti in modo omogeneo sul territorio nazionale che detengono e
devono gestire un’enorme quantità di informazioni eterogenee, dislocate e regolamentate
uniformemente, sia nei contenuti che nel ciclo di vita, da leggi
ed atti amministrativi. Questo contesto risulta appropriato per lo studio
di sistemi finalizzati al lavoro collaborativo in quanto i requisiti, particolarmente
restrittivi, che devono essere soddisfatti portano a presumere che i
risultati raggiunti potranno essere agevolmente applicati anche nel caso di
organizzazioni di tipo diverso.
Al fine di affrontare le varie problematiche in modo efficace, sono stati
messi in evidenza gli aspetti e le proprietà fondamentali delle informazioni
che sono state individuate nel contesto delle Pubbliche Amministrazioni
ed applicabili anche in altri ambiti. Tali proprietà risultano infatti di carattere
generale e proprie di qualsiasi tipologia di documento. Tutte queste
caratteristiche sono alla base di un modello dell’informazione denominato
“Distributed Delocalized Document Information Model” (D3IM). Tale modello
è distribuito ed indipendente dalla localizzazione fisica (delocalizzato);
inoltre tutte le scelte che hanno portato alla sua definizione sono state effettuate
principalmente con l’intento di soddisfare il requisito non funzionale di
scalabilità.
L’obiettivo del presente lavoro di tesi è quello di progettare un’infrastruttura
a supporto dell’Enterprise Content Management, nella quale il versioning
riveste uno dei ruoli di importanza primaria, che aggiornerà ed estenderà
il modello D3IM. Le operazioni che verranno effettuate consistono nello scindere
tutti gli aspetti riguardanti il vero e proprio modello dell’informazione
dagli aspetti architetturali ed implementativi. Ciò darà vita ad un’evoluzione
di D3IM che risulterà astratta e consistente, indipendentemente dai modelli
dei dati concreti che verranno sviluppati e dalle specifiche implementazioni
architetturali. Volendo sfruttare un’analogia è possibile dire che D3IM starà
alla programmazione orientata agli oggetti come i vari modelli dei dati a cui
darà vita staranno agli specifici linguaggi di programmazione (ad esempio
C++, Java, etc.). Oppure, nell’ambito delle telecomunicazioni, D3IM potrà
essere messo in relazione alla pila ISO/OSI mentre i vari modelli dei dati alle
varie implementazioni dello stack di rete (ad esempio TCP/IP).
Sulla base del modello attuale dell’informazione verrà progettata anche
xv

Introduzione
un’architettura distribuita, denominata Collaborative Information System
Architecture (CISA), che definirà un proprio modello dei dati conforme a
D3IM. Tale architettura sarà progettata seguendo un approccio stratificato
similmente a quanto realizzato nell’ambito delle telecomunicazioni per quanto
riguarda l’infrastruttura di rete.
Verranno definite le funzionalità degli strati e progettati i sistemi che
sono stati individuati per espletarle, dando particolare enfasi al livello che si
occupa della gestione delle versioni.
Il presente lavoro di tesi è suddiviso in tre parti:
Parte I (Capitoli 1 e 2).
Riguarda la definizione del problema del lavoro collaborativo e la descrizione
dello stato dell’arte relativamente ai sistemi di controllo delle versioni.
Parte II (Capitoli 3 e 4).
Illustra la definizione del modello astratto dell’informazione D3IM.
Parte III (Capitoli da 5 a 9).
Riguarda la progettazione dell’architettura CISA.
In particolare i singoli capitoli trattano i seguenti argomenti:
Capitolo 1.
Lavoro collaborativo in ambiente distribuito e descrizione dei requisiti desiderabili
per un sistema groupware.
Capitolo 2.
Controllo delle versioni, modelli di sincronizzazione per l’accesso a risorse
condivise e versionate; stato dell’arte di sistemi per il controllo delle versioni
finalizzati allo sviluppo collaborativo di progetti software.
Capitolo 3.
Definizione di ambiente virtuale, modello delle interazioni e delivery dell’informazione.
xvi

Introduzione
Capitolo 4.
Modello dell’informazione versionata D3IM, concetto di documento strutturato
e di responsabilità, classificazione, identificazione dell’informazione,
storico e stato dei documenti.
Capitolo 5.
Architettura stratificata CISA basata sul modello D3IM, descrizione dei livelli
e modello distribuito dell’architettura.
Capitolo 6.
Modello di versioning in CISA, formalizzazione dello storico delle informazioni
nel contesto dell’architettura.
Capitolo 7.
Progettazione dettagliata dello storico, interfacciamento verso il sottosistema
di gestione del versioning con relativo modello dei dati ed algoritmi operativi.
Capitolo 8.
Sistema di nomi a tre livelli e servizio di risoluzione dei nomi. Nomi logici utilizzati
dall’uomo e nomi persistenti utilizzati dal sistema per l’identificazione
univoca delle risorse, risoluzione da nomi logici in persistenti e risoluzione da
nomi persistenti in URL per l’accesso.
Capitolo 9.
Infrastruttura di comunicazione client/server fra i vari sistemi di CISA, interfaccia
“bidimensionale” ed architettura di rete.
xvii

Parte I
Analisi del versioning in
ambienti collaborativi

Capitolo
1
Cooperazione e collaborazione nelle
organizzazioni
In questo capitolo verranno presentati i problemi, le proprietà ed i requisiti
relativi alla gestione collaborativa dell’informazione all’interno delle
organizzazioni.
Verranno esposte ed analizzate le principali caratteristiche della gestione
dei documenti, fornendo un quadro esplicativo delle organizzazioni e in
generale di ciò che attiene al lavoro collaborativo.
L’obiettivo della cooperazione è di consentire ad un insieme di risorse,
siano esse processi o persone, di lavorare insieme per risolvere efficientemente
un problema comune.
Le caratteristiche fondamentali di un ambiente collaborativo sono costituite
sia dalla rappresentazione, gestione e condivisione dell’informazione che
dai paradigmi di interazione; esiste quindi la necessità di concordare convenzioni
e regole di linguaggio comuni in modo da permettere ai vari soggetti
una efficace intercomunicazione.
Uno dei punti centrali per soddisfare queste esigenze è la realizzazione
di una completa integrazione attraverso la condivisione delle risorse, delle
procedure adottate all’interno di un’organizzazione e dei dati detenuti da
ogni entità coinvolta.

Cooperazione e collaborazione nelle organizzazioni La gestione dei documenti
1.1 La gestione dei documenti
La condivisione dell’informazione è il presupposto al lavoro collaborativo.
Se non esiste passaggio di informazione gli individui rimangono alienati ed i
sistemi isolati. Tale informazione è convenzionalmente e storicamente rappresentata
all’interno di documenti (cartacei o elettronici), il cui volume cresce
proporzionalmente al tempo, al numero di persone e all’efficienza delle tecnologie.
Per rendere umanamente trattabili enormi quantità di documenti e la
loro evoluzione sono necessari strumenti capaci di memorizzarli, coordinarne
gli accessi, ricercare e mantenere la consistenza dei dati entro contenuti.
Con Document Management (DM ) si intende il controllo automatizzato
dei documenti elettronici (immagini, fogli di calcolo, testi) inerente al loro
completo ciclo di vita all’interno di un’organizzazione, dalla iniziale creazione
alla finale archiviazione [Cle95]. Il Document Management permette
alle organizzazioni di esercitare un grande controllo sulla produzione, sull’immagazzinamento
e sulla distribuzione dei documenti, consentendo di riusare
l’informazione, controllarne il workflow 1 e ridurre i tempi di produzione dei
manoscritti.
Complessivamente l’insieme di funzionalità che un sistema di DM può
realizzare copre vari aspetti quali l’identificazione, l’immagazzinamento, il
recupero, la tracciabilità, il controllo delle versioni, la gestione del workflow
e la presentazione.
Tradizionalmente i sistemi di DM sono classificati in gestionali di documenti
non editabili e gestionali di documenti editabili [Cle95]. Queste due
classi differiscono notevolmente per il fatto che i primi trattano artefatti
statici, mentre i secondi artefatti dinamici. I sistemi della prima categoria
concentrano l’attenzione sull’accesso, l’acquisizione, l’indicizzazione e il recupero,
mentre i secondi sulla creazione collaborativa, authoring 2 , workflow e
controllo delle revisioni.
Attualmente la distinzione in queste due classi è puramente storica. I
recenti sistemi tendono ad incorporare un largo insieme di funzionalità con
la finalità di superare le divisioni tra unità organizzative, piattaforme e spe-
1 Secondo la definizione della Workflow Management Coalition [Coa06], il workflow è:
“L’automazione di una parte o dell’intero processo aziendale dove documenti, informazioni
e compiti vengono passati da un partecipante ad un altro per ricevere qualche tipo di
azione, seguendo un determinato insieme di regole”.
2 Per authoring si intende l’insieme dei processi finalizzati alla creazione di
un’informazione.
3

Cooperazione e collaborazione nelle organizzazioni La gestione dei documenti
cifiche applicazioni, abbracciando l’uso e il controllo dei documenti in tutta
la loro vita.
È importante notare che DM non è una singola tecnologia, ma un insieme
di tecniche e tecnologie atte alla realizzazione di un sistema integrato.
Accordi bilaterali su standard comuni e alleanze tra organizzazioni facilitano
questo processo di integrazione spesso fondato su un approccio aperto.
Con Document Management Systems (DMS) si intendono sistemi software
che svolgono, tutte o in parte, le funzionalità previste nel contesto del
Document Management.
Normalmente in sistemi di questo tipo possono essere individuate le seguenti
caratteristiche [Rob06]:
• i documenti gestiti vanno intesi nel senso convenzionale del termine
ovvero si tratta di testi, fogli di calcolo, eccetera;
• ogni documento (unità informativa elementare dal punto di vista del
DM) è piuttosto ampio e completo in quanto contiene tutti i dati
necessari alla sua fruizione (è ben definito come entità individuale);
• le relazioni fra documenti distinti, se esistono, sono in numero limitato;
• i documenti vengono salvati e gestiti nel loro formato nativo;
• i DMS sono orientati principalmente al salvataggio e all’archiviazione
dell’informazione;
• i DMS prevedono sofisticati meccanismi di gestione del workflow dell’informazione.
I DMS sono sistemi ormai consolidati e presenti nel mercato da molti
anni. Più recentemente è stato introdotto il concetto di Content Management
(CM ) che si differenzia dal precedente in quanto tratta quei processi e
tecnologie finalizzati a supportare l’evoluzione temporale di generiche informazioni
in formato digitale durante il loro intero ciclo di vita. In questo caso
il concetto di documento convenzionale viene perso a favore di un formato
dell’informazione definito interamente o parzialmente nel contesto del CM
stesso.
I Content Management Systems (CMS) sono i sistemi software finalizzati
al CM e, normalmente, hanno le seguenti caratteristiche:
4

Cooperazione e collaborazione nelle organizzazioni La gestione dei documenti
• gestiscono unità informative molto piccole ed interconnesse (come, ad
esempio, le pagine web);
• l’interconnessione fra le varie unità è elevata;
• sono specializzati nel supporto alla redazione e pubblicazione delle
informazioni;
• si basano su un formato dei dati proprietario.
È evidente che i DMS ed i CMS hanno molte caratteristiche in comune
pur non risolvendo esattamente le stesse problematiche inerenti alla gestione
delle informazioni.
Attualmente la disciplina che tratta tutte le problematiche affrontate e
gestite sia nel contesto dei DM che dei CM è chiamata Enterprise Content
Management (ECM ).
In generale è possibile individuare varie fasi attraversate dall’informazione
(in qualunque forma essa sia) durante il suo ciclo di vita. Tali fasi sono le
seguenti:
• creazione, operazione effettuata da uno o più autori con il fine di creare
l’informazione;
• aggiornamento, operazione effettuata da uno o più autori con il fine di
modificare un’informazione già esistente;
• pubblicazione, operazione che permette di attestare la validità di un’informazione
con il fine di renderla disponibile a tutti gli interessati per
la fruizione;
• traduzione, operazione che consiste nel trasformare un’informazione in
un formato diverso;
• archiviazione, operazione che consiste nel classificare e memorizzare
opportunamente l’informazione con il fine di conservarla nel tempo;
• ritiro, operazione effettuata per contrassegnare informazioni obsolete.
Risulta evidente come tutti questi sistemi sono finalizzati al lavoro collaborativo,
pertanto si individuano varie categorie di utenti che intervengono
nel ciclo di vita dell’informazione secondo modalità diverse. Le categorie più
importanti sono le seguenti:
5

Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo
• autore, responsabile della creazione dell’informazione;
• redattore, responsabile dell’aspetto formale dell’informazione (come ad
esempio l’applicazione di uno stile grafico standardizzato) con il fine di
garantirne l’uniformità e la diffusione;
• editore, responsabile del rilascio e dell’utilizzo dell’informazione;
• amministratore, responsabile della gestione delle versioni dell’informazione
e in generale degli archivi.
1.2 Il lavoro collaborativo
Nella maggior parte delle situazioni in cui esiste collaborazione gli utenti
sono quasi sempre distribuiti nel tempo e nello spazio: molti sistemi multiutente
sono da considerarsi distribuiti. Questa ipotesi mette in luce il fatto
che sia i dati che il controllo sono decentralizzati. Le azioni effettuate sulle
proprietà globali del sistema ed il mantenimento della consistenza dello stato
globale vengono effettuate grazie ad agenti che trattano e manipolano risorse
locali [ESG91].
Per comprendere i tratti caratteristici del lavoro collaborativo è necessario
analizzare la realtà sociale con una prospettiva globale su contesti e condizioni
in cui gli individui operano: attività quotidiane, relazioni interpersonali,
conoscenza e risorse (incluse le tecnologie).
La società acquista la maggior parte delle sue caratteristiche dal modo
e dai mezzi con cui le persone si relazionano. Ed esempio la diffusione
dei computer e delle reti telematiche, avvenuta prima in ambienti lavorativi
e successivamente in quelli domestici, ha mutato e sta mutando profondamente
la società. Lo studio di questi sistemi, come pure delle conseguenze
psicologiche, sociali e organizzative, appartiene ad un settore di ricerca multidisciplinare
denominato Computer-Supported Cooperative Work (CSCW ).
Le tecnologie e gli strumenti che facilitano la collaborazione ad un gruppo
di individui sono indicate con la parola groupware. CSCW può anche essere
considerato come metodologia di lavoro, fondata sul principio che le reti
di computer sono capaci di agevolare, aumentare e ridefinire le interazioni
all’interno di un gruppo e tra gruppi.
Un aspetto molto importante da mettere in evidenza del lavoro collaborativo
è che i soggetti interessati devono avere una visione globale del progetto
6

Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo
(o parziale, ma che comunque comprenda il lavoro svolto da altri). Questo
perché, nella maggior parte dei casi, non è possibile riuscire a dividere il progetto
fra i vari soggetti in compartimenti stagni: restano sempre dei punti di
contatto o di sovrapposizione delle mansioni. Molte realtà sono organizzate
gerarchicamente ed è ovvio che i soggetti che si trovano ai livelli più alti della
gerarchia devono conoscere il lavoro svolto da quelli che si trovano più in
basso. Il grado di conoscenza che ogni individuo ha sul lavoro di altri ed in
generale sullo stato globale del progetto è definito awareness.
Tipicamente le tecnologie groupware sono classificate lungo due dimensioni
principali: lo spazio ed il tempo. Il modello Johansen [Kap97], conosciuto
anche col nome di modello dei 4 quadranti, individua 4 categorie e le riporta
in una matrice 2×2 come mostrato in tabella 1.1. Tale modello fa riferimento
a due tipologie di interazione, asincrona e sincrona, di seguito definite:
• interazione asincrona: si intende una situazione di relazione fra due
o più soggetti in cui la comunicazione avviene in tempi diversi; l’interazione
è ovviamente limitata. In questa modalità vengono utilizzate
varie tipologie di strumenti: e-mail, forum, audio e/o video messaggi,
frasi scritte su lavagne condivise;
• interazione sincrona: si intende una situazione di relazione fra due
o più soggetti in cui la comunicazione avviene in tempo reale; l’interazione,
eventualmente mediata da uno strumento informatico, è contemporanea.
Alcuni strumenti utilizzati per la modalità sincrona, oltre
all’interazione faccia a faccia o telefonica, sono le chat e le audio/video
conferenze.
Spazio
Stesso luogo
Luoghi diversi
Tempo Stesso intervallo
temporale
Interazione
faccia a faccia
Interazione sincrona
distribuita
Tabella 1.1: Modello Johansen.
Intervalli temporali
disgiunti
Interazione
asincrona
Interazione asincrona
distribuita
Gli utenti che si trovano a collaborare all’interno dello stesso ambiente
7

Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo
(collaborazione locale) e nello stesso intervallo di tempo hanno la possibilità
di interagire faccia a faccia. In questo caso il grado di awareness è ragionevolmente
alto in quanto sono normali riunioni periodiche, prefissate o
improvvisate, incontri informali (ad esempio nella pausa caffè o durante il
pranzo), eccetera. Non è necessario che gli strumenti informatici di supporto
favoriscano lo scambio di informazioni. Nel caso in cui l’intervallo di tempo
non coincida gli utenti possono ricorrere all’interazione asincrona ad esempio
inserendo degli appunti destinati ai colleghi nell’area di lavoro (come una
nota a margine di un documento, o un frase su una lavagna). Può risultare
utile l’utilizzo della posta elettronica e/o di un forum.
Nel caso in cui i luoghi siano diversi diventano necessari strumenti per le
comunicazioni remote. Questi devono prevedere la possibilità di interagire
in modo sincrono o asincrono. È opportuno analizzare le casistiche di collaborazione
distribuita che possono presentarsi: lavoro a distanza, lavoro in
appalto, gruppi localizzati e gruppi distribuiti [Ask02].
Lavoro a distanza. Si verifica quando un dipendente effettua delle brevi
operazioni al di fuori del normale ambiente di lavoro, spesso come complemento
al lavoro giornaliero. Un esempio può essere una breve operazione
svolta a casa necessaria per il giorno dopo. Se tale operazione richiede un
lungo periodo di tempo si crea una situazione simile a quella dei gruppi
distribuiti.
Date le circostanze è auspicabile che l’utente sia in grado di mettersi nelle
condizioni di operare in breve tempo in quanto ha poche ore a disposizione.
Gli approcci usati, se il materiale sul quale operare è in formato elettronico,
sono:
• lavoro “off-line”: l’utente opera su una copia dei documenti. Questo
presuppone che l’utente abbia a disposizione tutto il pacchetto di
applicativi necessario per trattare le copie dei file che ha creato;
• lavoro “on-line”: l’utente ha a disposizione la possibilità di effettuare
un login remoto sulla sua postazione di lavoro ordinaria.
Dal punto di vista del sistema groupware la prima possibilità implica
che il lavoro svolto resti temporaneamente fuori dal sistema e che l’utente
non abbia modo di interagire con il sistema stesso, pregiudicando l’awareness
8

Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo
complessivo. Il secondo approccio risulta migliore (equivale alla collaborazione
locale), ma presuppone che l’utente abbia a disposizione una connessione
alla rete sufficientemente veloce.
Lavoro in appalto. Si verifica quando viene commissionata una parte di
lavoro ad una entità esterna. È basato su una collaborazione stretta fra committente
e commissionario. Il committente è il responsabile del prodotto finale
ed eventuali errori/cambiamenti devono essere convertiti in una richiesta
di modifica verso il commissionario.
Dal punto di vista del sistema groupware il committente deve essere in
grado di integrare le nuove versioni nel prodotto, operazione che può risultare
complessa in quanto committente e commissionario potrebbero non avere a
disposizione gli stessi strumenti informatici.
Lavoro in gruppi localizzati. Quando il lavoro è svolto all’interno di
una compagnia che ha varie sedi ed in ogni sede operano uno o più gruppi
distinti (ognuno dei quali svolge una parte del lavoro complessivo), si parla
di gruppi localizzati. Le interazioni che si hanno all’interno di un gruppo o
tra gruppi che operano nella stessa sede rientrano nella collaborazione locale.
La collaborazione fra gruppi che operano in luoghi diversi è complessa ed è
facilitata se il lavoro viene correttamente pianificato e suddiviso in varie fasi.
Dal punto di vista del sistema groupware è importante mettere a disposizione
tecnologie che permettano ai gruppi di interagire nel miglior modo
possibile compatibilmente con le esigenze del momento in modo tale che sia
possibile garantire un buon livello di awareness.
Lavoro in gruppi distribuiti. Quando si creano gruppi i cui membri
appartengono a sedi diverse della stessa compagnia o a compagnie diverse e
sono quindi geograficamente dispersi, si parla di gruppi distribuiti. Questa
situazione normalmente non viene creata in modo intenzionale, ma si verifica
nel momento in cui alcuni dipendenti vengono destinati a lavorare su più
progetti.
Dal punto di vista del sistema groupware è importante che i membri del
gruppo abbiano la possibilità di comunicare in modo da poter ricevere informazioni
che riguardano il lavoro svolto dagli altri. È importante che siano
presenti meccanismi che permettano una agevole ripartizione dei compiti e
che il sistema permetta l’accesso concorrente, sia per la lettura che per la
9

Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo
modifica, alle risorse disponibili. A riguardo è opportuno che il sistema operi
senza permettere il blocco esclusivo delle risorse: è difficile gestire situazioni
in cui alcuni utenti siano costretti ad attendere il rilascio di risorse in quel
momento necessarie per loro, ma non utilizzabili poiché bloccate da altri.
Molte sono le caratteristiche dei groupware [Bul05] che spingono le organizzazioni
alla loro adozione; qui di seguito vengono riportate le più importanti
ed evidenti:
• facilitazione del dialogo che viene reso più veloce, più chiaro e più
convincente;
• presenza di comunicazione dove altrimenti non sarebbe possibile;
• possibilità di utilizzo della telecomunicazione;
• riduzione dei costi degli spostamenti;
• promozione di esperienze comuni con prospettive multiple;
• favoreggiamento della formazione di gruppi con interessi comuni là dove
non sarebbe possibile con metodi tradizionali;
• riduzione di tempi e costi nelle coordinazione del lavoro;
• facilitazione nella risoluzione dei problemi;
• utilizzo di nuove modalità per comunicare (ad esempio interazioni strutturate
ed anonime).
1.2.1 Progettazione di groupware
Per progettare un sistema groupware è conveniente analizzare e comprendere
i problemi con la prospettiva dell’utente, delle sue mansioni e dei suoi
obiettivi. Per applicazioni groupware di larga scala l’analisi dell’utenza conduce
immediatamente all’analisi dei meccanismi comunicativi. Il problema
è significativamente più difficoltoso rispetto al caso di sistemi basati su un
singolo utente per i seguenti principali motivi:
• è più difficile organizzare e programmare i gruppi piuttosto che un
singolo individuo;
10

Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo
• non si può scegliere in anticipo il paradigma di interazione;
• i gruppi cambiano continuamente il loro stile di interazione e la durata
temporale della loro partecipazione;
• i nuovi gruppi evolvono velocemente durante il processo di formazione.
In molti casi è meglio iniziare lo studio partendo da un campo ristretto,
cercando di comprendere le particolari esigenze di un tipico gruppo (o piccola
organizzazione) che userà il sistema. Dovrà essere realizzata una documentazione
attraverso interviste, sopralluoghi, analisi degli strumenti usati, dei
processi e procedure di lavoro, per determinare la struttura organizzativa e i
ruoli degli utenti.
1.2.2 I gruppi e la collaborazione
L’analisi interdisciplinare condotta sul lavoro di gruppo conduce ad un
modello stratificato, come dimostrato da vari studi scientifici [MO94]. In
figura 1.1 è evidenziata graficamente la definizione della collaborazione come
attività fondata sul background sociale, supportato da infrastrutture
economiche.
Le tre dimensioni, collaborativa, sociale ed economica, sono poste rispettivamente
su tre livelli, in cui la collaborazione occupa la posizione più alta,
direttamente sopra il substrato sociale, il quale a sua volta giace su uno strato
economico.
La collaborazione è caratterizzata da un’ evoluzione ciclica nel tempo.
Inizia con incontri ufficiosi e attività individuali per poi allargarsi e formalizzarsi
in incontri di gruppo sempre più interattivi (eventualmente ripetuti)
e si conclude con la produzione dei risultati (prodotto finito, intellettuale o
materiale). La condivisione dell’informazione avviene in forma orale e scritta,
supportata da vari mezzi comunicativi tramite i quali avviene lo scambio di
informazione. La collaborazione può avvenire con procedimenti sequenziali,
paralleli o di reciprocità [CM03].
La dimensione sociale corrisponde all’aspetto comportamentale del lavoro
collaborativo che inizia a livello individuale per poi crescere gradualmente
fino a coinvolgere intere organizzazioni. Le interazioni avvengono su scala
diversa, monotona crescente rispetto al numero di individui coinvolti. Le
organizzazioni hanno una struttura piramidale e sono la massima espressione
di un gruppo (massima entità che li contiene).
11

Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo
Incontro di
corridoio
Lavoro
individuale
Individuo Nel gruppo Il gruppo
come un
tutt'uno
Risorse
umane
Attività di
prassi
Riunione Interazione
in corso
Tempo
Collaborazione Nelle Organizzazioni
Riunione
successiva
Tra gruppi Nella stessa
organizzazione
Substrato Sociale
Procedimenti Ambiente fisico Risorse
temporali
Substrato Economico
Figura 1.1: Gli strati di supporto alla collaborazione.
Condivisione
dei documenti
Fra
organizzazioni
diverse
Information
Communication
Technologies
La dimensione economica corrisponde alla parte organizzativa del contesto
ed è costituita dalle risorse disponibili (forza lavoro, infrastrutture, tecnologie
e informazioni) e dalle restrizioni esistenti all’interno dell’organizzazione
(mansioni, compiti, professionalità, risorse temporali).
La principale implicazione del lavoro di gruppo è che il gruppo esegue dei
compiti stabiliti dal contesto, dal tempo, dalle caratteristiche comportamentali,
dall’uso dei metodi di interazione e dalle abitudini lavorative (prassi).
Il gruppo ha una propria evoluzione, conseguentemente molti fattori relativi
alle sue necessità sono imprevedibili.
12

Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo
1.2.3 Requisiti generali per sistemi groupware
In tabella 1.2 sono presentati sette requisiti generali di cui un sistema
groupware può essere dotato; tale elenco può essere anche visto come criterio
di classificazione di specifici requisiti, che devono essere dedotti dalle esigenze
dell’utenza [MO94].
R1
R2
R3
R4
R5
R6
R7
Consentire molteplici processi
Consentire molteplici metodologie di lavoro
Consentire lo sviluppo del gruppo
Permettere metodi di interazione interscambiabili
Sostenere molteplici caratteristiche comportamentali
Regolare ed adattare il contesto del gruppo
Favorire permeabilità alle barriere del gruppo
Tabella 1.2: Requisiti per sistemi groupware.
R1 - Consentire molteplici processi. I gruppi vengono creati con la
finalità di svolgere dei compiti. Il sistema groupware deve permettere molteplici
processi dato che i gruppi possono ridefinire i propri obiettivi in risposta
a mutamenti socio-economici. Eventuali sotto requisiti indirizzano funzionalità
di produzione. Una strategia implementativa consiste nella realizzazione
modulare di ogni processo in modo da tenere separati i vari compiti.
R2 - Consentire molteplici metodologie di lavoro. Un particolare
lavoro può essere scomposto in lavori minori o far parte di un processo più
ampio. Ciascuno di essi sarà completato usando opportune ed appropriate
tecniche che il sistema groupware deve essere in grado di fornire.
Alcuni membri del gruppo potrebbero preferire un lavoro più solitario o
isolato, altri invece ricercare l’influenza del gruppo, preferendo la vigilanza
della collettività. Inoltre i mezzi di comunicazione, le tecniche e gli strumenti
offrono un numeroso insieme di varianti. L’evoluzione di queste infrastrutture
non può essere predetto, quindi è necessario che il sistema sia aperto alle
innovazioni. Anche in questo caso un approccio modulare può essere efficace
nella realizzazione e nell’aggiornamento del sistema.
13

Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo
R3 - Consentire lo sviluppo del gruppo. I gruppi sono influenzati dalla
dinamica dell’ambiente e delle interazioni. Ad esempio a livello sociale
la composizione del gruppo cambia all’entrata e all’uscita di un membro. I
confini cambiano al costituirsi o al disgregarsi di relazioni all’interno dell’organizzazione,
inoltre la cultura organizzativa cambia in risposta a cambiamenti
ambientali. Un modello per lo sviluppo di gruppi è basato sul concetto
di equilibrio interrotto il quale afferma che “il lavoro di gruppo progredisce
con lunghi periodi di inerzia, interrotti da rivoluzionari e limitati periodi di
mutamenti quantici” [MO94].
Esistono almeno due aree concrete nelle quali i groupware sono di aiuto
nello sviluppo e nella creazione dei gruppi: influenzano il comportamento
dei processi che governano la crescita del gruppo e ne gestiscono gli aspetti
strutturali.
Influenzare il comportamento implica l’uso di tecniche per incrementare
il consenso, definire ruoli, ridistribuire il potere e incrementare l’interazione.
Questi obiettivi possono essere raggiunti attraverso una sincronizzazione
condivisa delle vedute, oppure consentendo anonimato, imponendo scadenze
temporali o stabilendo livelli di accesso all’informazione.
D’altronde è importante anche la gestione strutturale: il gruppo deve essere
amministrato e deve conservare memoria delle passate attività in modo
da poter programmare le future evoluzioni e pianificare la crescita. La consapevolezza
(awareness) del lavoro svolto all’interno del gruppo consente una
migliore integrazione tra membri e favorisce maggiori risultati individuali.
R4 - Permettere metodi di interazione interscambiabili. La comunicazione
all’interno delle organizzazioni avviene attraverso varie modalità
(faccia a faccia, riunioni, scrittura etc.). Il sistema groupware deve essere in
grado di coprire la maggior parte dei quattro quadranti del modello Johansen
(tabella 1.1 a pagina 7) e di consentire in modo integrato il passaggio delle
interazioni da un quadrante all’altro al mutare delle condizioni ambientali.
R5 - Sostenere molteplici caratteristiche comportamentali. I gruppi
assumono vari comportamenti nel prendere parte all’interazione e nel completare
e svolgere i propri compiti. Ciò è dovuto al grado di coesione, agli
impegni da sostenere, allo stress, ai ruoli assegnati all’interno dell’organizzazione.
Queste caratteristiche governano le modalità con cui il gruppo per-
14

Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo
cepisce e usa il sistema groupware, quindi il sistema deve farsi carico anche
della dimensione sociale del lavoro collaborativo.
È difficile, potrebbe essere impossibile, valutare l’importanza dei vari comportamenti;
si possono comunque identificare tre approcci complementari che
ne facilitano la classificazione:
• comportamenti chiave: identificano solamente i principali comportamenti
in un particolare dominio. Redigere la tassonomia dei compiti
può essere il punto di partenza;
• elementi catalizzanti: identificano le variabili del sistema che regolano i
comportamenti. Ad esempio il tempo disponibile ha un grosso impatto
sulla concentrazione e la coesione tra individui. Intervenendo su queste
variabili si controlla il comportamento del gruppo;
• prospettive dell’utente: identificano gli aspetti che potrebbero consentire
all’utente l’automazione del lavoro, la modifica flessibile e la
personalizzazione degli strumenti, che altrimenti lo potrebbero rendere
frustrato.
R6 - Favorire permeabilità alle barriere del gruppo. I limiti fisici
spazio-temporali possono creare divisioni che a loro volta determinano differenze
penalizzanti tra individui. I confini del gruppo devono essere permeabili
nel senso che devono consentire meccanismi di ingresso ed uscita delle informazioni,
abbattendo i limiti fisici. Questa necessità è determinata da fattori
economici e sociali come ad esempio la presenza di una autorità esterna e la
dipendenza da altri gruppi.
Dovranno essere enunciate appropriate specifiche per delineare il modo
in cui saranno stabiliti e gestiti i confini del gruppo. È necessario risolvere
quanto prima il problema dell’interoperabilità, poiché, prima o poi, il gruppo
si dovrà scontrare col mondo esterno.
R7 - Regolare ed adattare il contesto del gruppo. È conveniente
vedere il contesto come un’opportunità piuttosto che come un ostacolo alla
adattabilità del gruppo. Ogni gruppo ha una dettagliata conoscenza di sé
e probabilmente ha idee chiare su ciò di cui ha bisogno. Questa conoscenza
può essere usata per personalizzare il groupware.
15

Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo
La personalizzazione è soggettiva, ma le scelte individuali si riflettono su
tutti i membri. Alcuni settaggi, come la selezione del metodo di interazione,
dovrebbero essere al di fuori della portata del generico utente, mentre altri,
come ad esempio le modalità di presentazione dell’informazione, dovrebbero
essere consentiti a tutti. Interventi determinanti sul groupware possono essere
affidati ad un amministratore il quale si prende carico delle esigenze di base
del proprio gruppo.
1.2.4 Modelli di lavoro
Quando più persone operano contemporaneamente sullo stesso sistema
devono sincronizzare il loro lavoro. Normalmente si ha una suddivisione dei
compiti fra i vari soggetti, questa operazione può essere ricorsiva per organizzazioni
strutturate in modo gerarchico (per esempio: l’organizzazione divide
il lavoro fra le varie sedi, ogni sede divide la parte di propria competenza fra
i gruppi ivi locati infine ogni gruppo suddivide le mansioni fra i vari membri
di appartenenza). Durante il processo di sviluppo del sistema è necessario ricombinare
le varie parti almeno una volta, per creare il prodotto finito; molto
probabilmente però, questa operazione sarà effettuata più volte (nel complesso
o per assemblare sottosistemi più grandi delle singole parti) per ottenere
le pietre miliari ed i prodotti semi-lavorati previsti dai convenzionali processi
di sviluppo. Esistono due approcci diversi per effettuare la suddivisione:
• architetturale: si effettua una divisione fisica del sistema da sviluppare
in sottosistemi o moduli separati e si assegna un responsabile ad ognuno
di essi. Soltanto il responsabile ha la possibilità di operare sulla risorsa;
• anatomico: si dividono le mansioni sulla base dei risultati (o funzionalità)
che si intendono ottenere, lasciando la possibilità a tutti i soggetti
di operare su ogni parte del sistema.
Durante le prime fasi di sviluppo l’approccio architetturale è quello maggiormente
usato. Si dimostra però eccessivamente statico nelle fasi finali, fasi
nelle quali si uniscono sottosistemi distinti in un prodotto unico, quello finale.
Per risolvere eventuali problemi che sorgono in questa fase è probabile
che sia necessario intervenire su più sottosistemi, rendendo l’approccio anatomico
più conveniente. Il rovescio della medaglia è che sono richiesti sforzi
supplementari per garantire la consistenza del progetto. È necessario che le
16

Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo
unità di lavoro siano correttamente ordinate ed analizzate affinché possano
essere effettuate in concorrenza.
Un’altra terminologia utilizzata per i modelli di lavoro prevede la definizione
di tre tipi di coordinamento:
• turn-taking: un singolo individuo alla volta è abilitato ad apportare
cambiamenti al progetto, gli altri, di fatto, non possono operare;
• split-combine: il progetto è partizionato ed ogni individuo è abilitato ad
operare sulla parte di sua competenza (equivalente ad architetturale),
tale approccio potrebbe risultare eccessivamente statico;
• copy-merge: ogni soggetto ha a disposizione una copia di tutto il progetto
sulla quale operare e, di tanto in tanto, le modifiche vengono fuse
insieme (equivalente ad anatomico). Per la gestione delle fusione delle
modifiche occorrono meccanismi complessi, che, in base al contesto,
potrebbero non riuscire nei loro intenti lasciando il sistema in uno stato
inconsistente (nel tal caso risulta necessario intervenire manualmente).
Nel caso in cui la compagnia sia organizzata in modo gerarchico è usuale
ricorrere a combinazione di modelli. Ad esempio è comune uno scenario in cui
agli alti livelli si ricorre al tipo split-combine, in quanto si hanno vari gruppi
responsabili di sottosistemi distinti, mentre all’interno dei singoli gruppi si
usa il tipo copy-merge.
In generale la scelta della strategia deve tenere presente due direttive,
in sostanza contraddittorie. Da una parte esiste la necessità di integrare il
più velocemente possibile le modifiche e le correzioni, dall’altra è preferibile
fornire agli utenti un ambiente di lavoro il più stabile possibile, affinché ogni
utente non venga esageratamente disturbato dalle attività degli altri. Le
strategie del primo tipo sono dette ottimistiche e le seconde conservative.
Le strategie di aggiornamento riguardano le modalità con cui le nuove
informazioni sono messe a disposizione del gruppo di lavoro e quando devono
essere recepite ed usate dagli altri. Una strategia di aggiornamento ottimistica
consiste nel pubblicare immediatamente tutte le modifiche, per consentirne
un uso immediato. Questo significa che il problema dell’integrazione dovrà
essere risolto in tempi brevi. Nella strategia di aggiornamento conservativo
le modifiche non hanno effetti immediati; in altre parole vuol dire ritardare
la pubblicazione.
17

Cooperazione e collaborazione nelle organizzazioni Il concetto di configurazione
La scelta della strategia si riflette nell’approccio con cui viene gestito il
lavoro concorrente. Per principio una strategia conservativa non consente
modifiche concorrenti allo stesso documento, mentre una strategia ottimistica
ammette una pianificata integrazione dei dati, con tempi più o meno
rigidi. Per impedire modifiche concorrenti il sistema blocca la risorsa in esame
permettendo al solo utente che l’ha bloccata di effettuare modifiche. In
questo caso si parla di blocco (o lock) conservativo o pessimistico. Nei sistemi
in cui viene attuata la strategia ottimistica, per analogia, si parla di blocco
(o lock) ottimistico. In questo caso il sistema non attua un blocco vero e
proprio della risorsa, ma tiene traccia degli autori che la stanno modificando
in concorrenza in modo da permettere un’integrazione controllata delle modifiche.
In questo caso gli utenti devono interpretare il “blocco” come stato
in cui la risorsa è in fase di aggiornamento da parte di altri; la percezione che
essi hanno del blocco e cosa questo comporti all’atto pratico, varia molto al
variare del contesto.
1.3 Il concetto di configurazione
Nel tempo non variano solamente i contenuti di un documento, ma anche
la relativa struttura. Se la medesima struttura è comune a molti documenti,
definisce una tipologia (per i certificati, per documenti di identità, per i referti,
per i verbali, etc.). La modifica di una tipologia comporta la modifica di
ciascuno dei documenti associati.
Per esempio, in riferimento al linguaggio comune, la “patente” di “Mario
Rossi” è il documento rappresentato dall’insieme di informazioni riportate in
tabella 1.3.
Esistono informazioni necessarie per descrivere il documento in quanto
tale e altre che sono i dati che questo contiene. Le informazioni appartenenti
alla prima categoria sono dette metadati associati al documento e, in riferimento
all’esempio riportato in tabella 1.3, sono le informazioni presenti nella
colonna di sinistra.
I metadati consentono la gestione dei documenti e, a loro volta, sono rappresentati
tramite uno o più documenti oggetto di authoring. Una configurazione
(configuration) è l’insieme dei metadati che definiscono la struttura,
il workflow, il comportamento e lo stato interno del documento. In alcuni
contesti questo concetto viene esteso fino a comprendere il documento stesso
e, di conseguenza, reso più generico. Un’ulteriore generalizzazione è quella di
18

Cooperazione e collaborazione nelle organizzazioni Il concetto di configurazione
Tipo di dato
Nome
Cognome
Data e
Luogo di Nascita
Valore
Mario
Rossi
20/10/1971
Firenze (FI)
Etc. Etc.
Tabella 1.3: Struttura e dati di un documento.
considerare prodotti e sistemi oltre a documenti e definire configurazione una
“istantanea” del sistema (documento o prodotto) al tempo corrente t0. Con
“istantanea” si intendono tutte le informazioni necessarie per poter ricreare
il sistema (documento o prodotto) esattamente come si presenta al tempo
t0, nello stesso o in un altro luogo, in un momento t1 ≥ t0. Infine è utile
menzionare la seguente definizione ricorsiva: una configurazione è un insieme
di entità atomiche e di altre configurazioni. È possibile associare varie interpretazioni
a questa definizione, alcune delle quali permettono di mettere in
relazione i contenuti (entità atomiche) con gli aspetti strutturali. Supponendo
che l’insieme sia ordinato e che ogni entità atomica abbia come figli tutte
le entità atomiche contenute nella configurazione che precede, applicando la
definizione ricorsiva si ottiene un albero. In figura 1.2 è presente un esempio
nel quale la configurazione iniziale è costituita da una entità atomica seguita
da una configurazione. Espandendo la configurazione C1 (Passo 1), la radice
acquisisce due figli. Al primo di essi è associata una nuova configurazione
(C2) la quale, a sua volta, contiene due entità atomiche e una terza configurazione
(C3). Ripetendo l’algoritmo ricorsivo (Passi 2 e 3) si ottiene l’albero
riportato nell’ultimo riquadro a destra della figura.
Non esiste una definizione univoca di configurazione e pertanto, parlando
di gestione di configurazioni, è possibile intendere cose diverse. In letteratura,
a riguardo, è possibile trovare molte definizioni (vedi [App05]) e una
fra quelle coerenti con la definizione più generale data di configurazione è la
seguente: con CM (Configuration Management) si intendono tutti quei pro-
19

Cooperazione e collaborazione nelle organizzazioni Il concetto di configurazione
Configurazione
iniziale
Entità
atomiche
Passo 1 Passo 2 Passo 3
C1
Configurazioni
Figura 1.2: Albero ottenibile dalla definizione ricorsiva di configurazione.
cessi atti a gestire lo sviluppo e le modifiche di sistemi, prodotti o documenti
durante il loro intero ciclo di vita. I sistemi finalizzati al CM (chiamati anche
Configuration Management Systems, CMS) permettono quindi di controllare
l’evoluzione temporale delle configurazioni per garantire la loro integrità nel
tempo e la tracciabilità delle modifiche.
In riferimento alla descrizione dei Content Management Systems riportata
nel paragrafo 1.1 è possibile osservare che esiste una similitudine nella
definizione di questi ultimi e dei Configuration Management Systems. La differenza
sostanziale consiste nel fatto che i primi sono maggiormente orientati
alla gestione del workflow dell’informazione mettendo a disposizione molte
funzionalità avanzate per questo scopo, i secondi sono maggiormente orientati
al tracciamento dell’evoluzione temporale della configurazione (dell’informazione)
mettendo a disposizione strumenti sofisticati e specifici per il
controllo e la gestione delle versioni.
Data la sua diffusione è utile ricordare che con Software Configuration
Management (SCM ) si intendono tutti quei processi atti a gestire lo sviluppo
e le modifiche di codice sorgente durante il suo intero ciclo di vita. È utile
sottolineare che, anche in questo caso, tale definizione non è la sola esistente.
Per quanto riguarda i requisiti che devono essere soddisfatti è possibile
individuare due macrocategorie, una che comprende gli aspetti relativi alla
gestione, l’altra allo sviluppo delle configurazioni.
C2
C3
20

Cooperazione e collaborazione nelle organizzazioni Il concetto di configurazione
Prospettiva della gestione. Assumendo il punto di vista della gestione
delle configurazioni si possono identificare quattro aree di interesse: identificazione,
controllo, accounting e verifica.
• Identificazione. Comprende le attività che determinano una configurazione,
la relativa selezione, le caratteristiche funzionali, l’assegnazione
degli identificativi e le relazioni con altri documenti.
• Controllo. Comprende le attività di controllo dell’aggiornamento delle
configurazioni. Il controllo include anche la validazione, la coordinazione
degli utenti, l’approvazione e il rilascio.
• Accounting. Consiste nel memorizzare e riferire le configurazioni, lo
storico e le modifiche approvate. Lo storico deve tracciare tutta la storia
di un documento (prodotto o sistema), comprensiva delle eventuali
deviazioni subite nel tempo.
• Verifica. Consiste nel determinare quando una configurazione è ben
formata e valida rispetto ad un modello di riferimento.
Prospettiva dello sviluppo. Assumendo il punto di vista dello sviluppo
distribuito si possono identificare sette aree di interesse: controllo delle
versioni, selezione della configurazione, controllo della concorrenza, tracciabilità
dello sviluppo, rilascio dei documenti (prodotti o sistemi, di seguito è
sottinteso), gestione dell’ambiente di lavoro e gestione delle modifiche.
• Controllo delle versioni. Deve essere possibile memorizzare differenti
versioni e varianti di un documento e conseguentemente essere capaci
di ottenerle e confrontarle tra loro.
• Selezione della configurazione. Devono essere create e/o selezionate
le configurazioni appropriate alle versioni. È una attività che
definisce e assegna i tipi di documento.
• Controllo della concorrenza. L’accesso simultaneo al documento
da parte di più utenti deve essere o prevenuto o coordinato.
• Tracciabilità dello sviluppo. È necessario rappresentare le informazioni
relative agli autori del documento ed a coloro che hanno introdotto
note e/o apportato modifiche alla configurazione.
21

Cooperazione e collaborazione nelle organizzazioni Il concetto di configurazione
• Rilascio dei documenti. Deve essere tenuta memoria dei documenti
che lasciano il sistema o che comunque vengono comunicati all’esterno.
• Gestione dell’ambiente di lavoro. Deve essere possibile svolgere le
attività lavorative sia in modo individuale che collettivo.
• Gestione delle modifiche. Le modifiche devono essere applicate secondo
criteri prestabiliti o eventualmente selezionabili tra quelli disponibili.
22

Capitolo
2
Versioning a supporto della
collaborazione
La gestione delle versioni riguarda un sottoinsieme delle attività previste
nell’ambito del Document Management. Nello sviluppo del software, il
versioning diviene un argomento centrale, indipendentemente dalla strategia
adottata. Per questo motivo molti modelli, sistemi e applicazioni sono stati
pensati e realizzati per coordinare la produzione del codice sorgente, dei
binari e il rilascio dei pacchetti.
La gestione automatizzata delle versioni aiuta nello sviluppo e nella manutenzione
dei dati, incrementando la qualità dei processi. Se il processo è
efficace, allora permette benefici nel lavoro collaborativo, assicurando fiducia
nel conseguire le finalità.
Nelle organizzazioni la rilevanza del problema si ripropone con le stesse
caratteristiche, ma con maggiore gravità. Non solo c’è bisogno di mantenere
un’accurata storia dei documenti, per adempiere agli obblighi amministrativi,
ma anche per poter rintracciare ed ottenere, con il minimo errore, i dati più
recenti o relativi ad un preciso periodo storico.
È facile comprendere che l’authoring concorrente, e volendo generalizzare
il Document Management, risultano essere strettamente correlati alla gestione
delle versioni. In origine si assumeva implicitamente che le persone, così
come le risorse, fossero localizzate nello stesso sito geografico. Con il successo

Versioning a supporto della collaborazione Il controllo delle versioni
di Internet, l’authoring è divenuto un’attività distribuita. Oggi esiste il bisogno
di sviluppare nuovi strumenti, capaci di agevolare i processi da luoghi
geograficamente dispersi.
In questo capitolo vengono introdotti i concetti legati alla gestione delle
versioni, viene discusso dettagliatamente il modello UEVM e vengono descritte,
in ordine cronologico di introduzione, alcune delle applicazioni più
note per la gestione delle versioni nell’ambito dello sviluppo del software:
– RCS (paragrafo 2.6);
– CVS (paragrafo 2.7);
– Subversion (paragrafo 2.8).
Dall’evoluzione di tali applicazioni si capisce che il mercato si sta dirigendo
verso soluzioni che facilitano sempre più il lavoro collaborativo, questo
perché lo sviluppo di software è un’attività complessa che normalmente viene
effettuata da un numero più o meno elevato di persone. Attualmente infatti
stanno nascendo ambienti di sviluppo integrati (IDE) che non si limitano
ad agevolare il lavoro del singolo programmatore o ad integrare plugin per
interfacciarsi a sistemi di versioning come quelli menzionati, ma che mettono
a disposizione dei tool specifici per la collaborazione (come l’interazione
asincrona/sincrona e la gestione integrata delle versioni):
– COOP/Orm (paragrafo 2.9).
Infine vengono introdotti alcuni sistemi che non basano il proprio principio
di funzionamento sul paradigma client/server, ma su quello peer-to-peer:
– BitKeeper, Git, Svk. (paragrafo 2.10).
2.1 Il controllo delle versioni
La possibilità di memorizzare, creare e registrare la storia di un documento
è la caratteristica fondamentale di un sistema per la gestione delle
versioni. Tra una modifica e la successiva, l’entità assume un certo stato, il
quale viene identificato con una versione. La versione di un’entità rimane
immutabile nel tempo, dato che non può essere ulteriormente modificata.
Se l’authoring avviene in sequenza, l’organizzazione delle versioni è sequenziale,
in questo caso si parla di revisioni. Invece se l’authoring avviene
24

Versioning a supporto della collaborazione Modelli di sincronizzazione
in parallelo, si parla di diramazioni o branch. Ogni diramazione può convergere
verso una nuova versione, la quale ha due o più predecessori (merge).
Nel caso in cui una diramazione non converga mai, si dice che ha originato
una variante (figura 2.1).
Revisione
1 2
Variante
Diramazione
3
Diramazione
5
A
Convergenza
4 7 8
6
Revisione Revisione
Convergenza
B C
Revisione
Figura 2.1: Rappresentazione della storia delle versioni.
Solitamente le revisioni sono create dallo stesso autore, mentre le diramazioni
avvengono quando l’editing è concorrente. Le diramazioni sono necessarie
almeno per consentire una temporanea elaborazione locale. Una diramazione
consiste in una serie di revisioni che a loro volta possono originare
diramazioni.
2.2 Modelli di sincronizzazione
Le attività concorrenti degli utenti coinvolgono la modifica delle configurazioni.
Dovrà quindi esistere un meccanismo di sincronizzazione delle
risorse capace di garantirne la consistenza e di dare una visione il più possibile
unificata e coerente, valida per tutti gli utenti. I possibili modelli di
sincronizzazione, descritti in [Fei91], sono: checkout/checkin, composizione,
lunghe transazioni e change set.
25

Versioning a supporto della collaborazione Modelli di sincronizzazione
2.2.1 Checkout/Checkin
I documenti sono memorizzati sotto forma di file in un repository. I file
non sono leggibili o modificabili direttamente, se non prima che il checkout
venga applicato. Effettuare il checkout significa che i file vengono copiati nell’area
di lavoro dell’utente (directory locale) e che gli originali nel repository
vengono posti in stato di lock. Il lock previene il checkout di altri utenti.
Quando il file subisce il checkin le modifiche apportate in locale vengono
integrate nel repository generando una nuova versione, inoltre viene rilasciato
il lock sul documento di origine.
Il tagging è l’operazione che serve per etichettare, con un nome simbolico,
le versioni dei file appartenenti ad una data configurazione. Questo permette,
successivamente, l’operazione di recupero delle versioni dei file associate a tale
configurazione. Sarà possibile trovare ulteriori dettagli su questo meccanismo
in seguito, dove verrà descritto il sistema RCS (paragrafo 2.6).
Uno dei vantaggi di questo modello è che risulta estremamente semplice
sia da implementare in sistemi di vario tipo che da capire da parte
dell’utilizzatore.
Il principale rovescio della medaglia è che il meccanismo di locking penalizza
il lavoro a più mani implementando il paradigma turn-taking (paragrafo
1.2.4, pagina 17).
2.2.2 Composizione
La composizione è una estensione del modello checkout/checkin rispetto
al quale aggiunge il supporto esplicito alla gestione delle configurazioni, che,
in questo caso, sono entità note al sistema di gestione delle versioni. Per
quanto riguarda la gestione del repository, delle fasi di checkout e di checkin,
del concetto di directory di lavoro locale e del concetto di sincronizzazione
tramite locking, il modello è del tutto simile a quello precedente.
La necessità di introdurre un modello più evoluto del checkout/checkin
è dettata dal fatto che il tagging può non essere sufficiente per recuperare
una configurazione. Questo perché le configurazioni hanno natura dinamica
in quanto la loro struttura può variare nel tempo. Inoltre l’utente potrebbe
essere interessato ad accedere ad un sottoinsieme del sistema, operazione
possibile solo se il modello è in grado di stabilire se una data entità appartiene
o meno al sottoinsieme di interesse, il che equivale a richiedere che esso
sia in grado di comprendere la struttura del sistema. In questo caso, fissato
26

Versioning a supporto della collaborazione Modelli di sincronizzazione
l’insieme dei file presi in carico dal sistema di versioning (tutti i file che sono
stati interessati da una o più operazioni di checkin), occorre definire un meccanismo
che permetta, per prima cosa, di selezionare quali file appartengono
alla configurazione di interesse e, successivamente, in quale versione. Considerando
che un sistema può essere definito come un insieme di sottosistemi,
i quali a loro volta possono essere scomposti fino al raggiungimento di entità
non ulteriormente divisibili, è semplice descrivere tale meccanismo in termini
ricorsivi.
La definizione di una configurazione, pertanto, avviene in due passi:
1. tramite un opportuno modello del sistema vengono selezionati i documenti
che devono essere inclusi nella configurazione;
2. vengono stabilite le regole per determinare la versione di ogni documento
incluso.
2.2.3 Transazioni estese nel tempo
Questo modello si presta ad essere adottato quando lo sviluppo dell’intero
sistema coinvolge molti utenti e procede per integrazione di modifiche che
possono essere anche di grande entità. Ogni utente dispone di un’area di
lavoro personale per creare le proprie modifiche e solo ad operazioni concluse
provvede ad aggiornare l’area di lavoro comune.
Area di lavoro condivisa
1 3 2 4
5 6
Area di lavoro personale A Area di lavoro personale B
Figura 2.2: Paradigma di interazione.
27

Versioning a supporto della collaborazione Modelli di sincronizzazione
I singoli file possono essere gestiti con il modello checkout/checkin e il
ciclo canonico di lavoro prevede la copia, la modifica e l’aggiornamento dei
dati. Cicli di questo tipo, nel contesto dei database, sono noti con il nome di
lunga transazione e questo fatto ha dato origine al nome del modello.
In figura 2.2 è riportato uno scenario, abbastanza generico, che può presentarsi
durante l’uso di CM che basano il loro principio di funzionamento
su questo modello (ad esempio CVS e Subversion descritti, rispettivamente,
nel paragrafo 2.7 e nel paragrafo 2.8). Gli utenti A e B aggiornano il proprio
ambiente di lavoro locale (fasi 1 e 2). A apporta nel proprio ambiente
di lavoro modifiche che, a loro volta, possono essere gestite tramite un CM
locale e B fa altrettanto. Quindi A decide di aggiornare l’ambiente di lavoro
condiviso: siccome l’ultima versione presente nell’area condivisa coincide con
quella che l’utente A ha utilizzato per apportare le modifiche, l’integrazione
è immediata (passo 3). L’utente B decide di integrare le proprie modifiche
(passo 4). Il sistema rileva che la copia presente nell’area comune e quella
utilizzata da B come base di partenza per le proprie modifiche differiscono,
conseguentemente il sistema impedisce a B di portare a termine l’operazione.
L’utente B è obbligato ad aggiornare la propria copia locale per integrare le
modifiche più recenti apportate al sistema, in questo caso quelle apportate
da A (passo 5). In questa fase B deve, nel caso si fossero presentati, risolvere
i conflitti, ovvero aggiornare le eventuali parti del sistema modificate sia da
lui che da altri sviluppatori. Solo a questo punto B potrà integrare le proprie
modifiche nella copia condivisa (passo 6).
Il modello è da considerarsi ottimistico in quanto non prevede mai il
blocco del lavoro concorrente. È sempre possibile creare nuovi ambienti di
sviluppo personali (paralleli a quelli esistenti) sui quali non è possibile evitare,
preventivamente, la nascita di conflitti. Fortunatamente i dati derivanti da
vari anni di esperienza nel settore dei CM evidenziano che i casi in cui la
risoluzione dei conflitti è difficoltosa risultano molto rari.
Il modello può essere generalizzato per prevedere che l’area di lavoro locale
possa essere utilizzata contemporaneamente da più sviluppatori e, in tal caso,
occorre gestirne l’accesso concorrente con un CM specifico.
2.2.4 Change set
Questo modello permette di gestire i cambiamenti logici del documento.
Ad esempio, nello sviluppo di software, un cambiamento logico potrebbe es-
28

Versioning a supporto della collaborazione Modelli di sincronizzazione
sere la correzione di un bug oppure l’aggiunta di una nuova funzionalità nel
programma. Queste operazioni richiedono la modifica di alcuni file ed eventualmente
varie modifiche, in sezioni diverse, dello stesso file. È importante
mantenere l’informazione che tutte le modifiche sono correlate e finalizzate al
raggiungimento del medesimo cambiamento logico. Il mantenimento di tali
corrispondenze è alla base del modello (la filosofia è la stessa dell’approccio
anatomico descritto nel paragrafo 1.2.4 a pagina 16).
In questo modello le versioni sono organizzate partendo da un insieme di
configurazioni predeterminate, utilizzate come base di partenza, rispetto alle
quali vengono aggiunti un certo numero di cambiamenti logici non correlati.
Ogni aggiunta genera una nuova configurazione. Il meccanismo che gestisce
l’aggiunta dei cambiamenti logici fa sì che due cambiamenti logici mutuamente
esclusivi non vengano applicati contemporaneamente oppure che, qualora
alcuni cambiamenti ne richiedano altri, questi ultimi debbano essere applicati
per primi.
Questo modello viene tipicamente utilizzato nella fase di manutenzione
dei sistemi operativi che sono organizzati in “release” con un largo numero di
“patch”.
Il modello incoraggia una strategia conservativa di integrazione delle modifiche
e, in ogni caso, non ottimistica nel senso che forza l’integrazione solo
quando è realmente necessaria.
Sotto certi punti di vista il modello change set è simile al modello basato
sulle transazioni estese nel tempo. La differenza sostanziale è che nel modello
basato sulle transazioni estese nel tempo la sequenza con cui vengono integrate
le modifiche è la stessa sequenza con cui vengono effettuate le transazioni.
Nel modello change set questo vincolo è meno rigido in quanto è possibile
integrare le modifiche in qualunque ordine (a patto di rispettare gli eventuali
vincoli).
Il modello change set è vantaggioso nella gestione di sistemi con un grande
numero di varianti (come i già citati sistemi operativi) in quanto garantisce
una maggiore flessibilità permettendo di creare tutte le permutazioni possibili
di configurazioni (vincoli permettendo). Lo svantaggio è che può essere
difficile distinguere quali sono le configurazioni realmente utili dalle altre.
29

Versioning a supporto della collaborazione Modelli di versioning
2.3 Modelli di versioning
Un modello per il configuration management (paragrafo 1.3 a pagina 19)
definisce gli oggetti che devono essere trattati, il loro identificativo, la loro
organizzazione, le operazioni per creare nuove versioni e riceverle.
Molti modelli assumono che esista una netta separazione fra come essi
gestiscono le informazioni atomiche (o elementari, che non possono essere
ulteriormente scisse) e l’eventuale concetto di composizione che può esistere
fra le stesse. In questi modelli le informazioni atomiche vengono versionate
individualmente e, andando a considerare tutte le informazioni contemporaneamente,
il numero delle possibili combinazioni delle versioni e/o varianti
è solitamente molto elevato e, normalmente, non tutte le combinazioni sono
significative.
Uno dei problemi fondamentali che si incontra quando si ha a che fare
con le configurazioni è che, anche in presenza di un limitato numero di
componenti, ognuna con le proprie versioni e varianti, il numero di combinazioni
possibili (e quindi il numero di configurazioni possibili) può essere
molto grande. Da un punto di vista matematico cresce esponenzialmente
con il numero delle componenti e delle versioni e, nei reali contesti applicativi,
risulta impossibile gestire le configurazioni manualmente. Questo obbliga
ogni modello a dover affrontare tale problema.
Esistono due categorie di modelli di versioning: “versioning intensionale”
e “versioning estensionale”.
2.3.1 Modello intensionale
Molti modelli e CM attuali si basano su un sistema che viene chiamato
“versioning intensionale” delle relazioni strutturali per tenere sotto controllo
il problema dell’esplosione esponenziale della complessità. Questo approccio
si basa sulla formulazione di regole di selezione che vengono usate per
scegliere la particolare variante o versione di una determinata informazione
atomica. Spesso queste regole vengono calcolate su richiesta, quando sorge
la necessità di accedere all’informazione atomica per la visualizzazione o la
modifica. Sebbene questo approccio permetta di ridurre la complessità del
problema di selezione delle varie versioni, ha alcuni inconvenienti:
• la rappresentazione della struttura è indiretta, impressa nella definizione
delle regole stesse. Per scoprire quali informazioni atomiche, e in
30

Versioning a supporto della collaborazione Modelli di versioning
quali versioni, costituiscono una certa entità, non c’è altra strada se non
quella di applicare tutte le regole necessarie ed analizzare il risultato
ottenuto;
• è molto complesso confrontare entità diverse in base alle informazioni
atomiche che le costituiscono ed alle versioni in cui compaiono. Questo
perché occorre applicare tutte le regole necessarie per entrambe le entità
e confrontare i risultati ottenuti;
• la consistenza è difficile da garantire perché alcuni errori nelle regole
potrebbero rimanere latenti per molto tempo e manifestarsi solo con la
creazione di una nuova versione di qualche informazione atomica che
genera una struttura non valida. Come conseguenza non c’è la garanzia
che un dato insieme di regole permetta di ottenere lo stesso insieme di
informazioni atomiche, nelle stesse versioni se applicate in istanti di
tempo diversi. Questo inconveniente è reale e noto, tanto è vero che
nello sviluppo del software è uso comune salvare i sorgenti relativi a
versioni di particolare importanza (come le major release) al di fuori
del sistema di versioning per essere certi che in qualunque istante futuro
possa essere possibile ottenere i sorgenti corretti relativi alla versione
di interesse con probabilità di errore nulla;
• il “tagging” prevede l’uso di etichette da applicare individualmente ad
ogni file per la memorizzazione della relativa versione. Sfortunatamente
questo è un meccanismo primitivo in quanto non c’è nessuna garanzia
che queste etichette non vengano modificate per errore (o in modo
fraudolento). Questo non permette di mettere direttamente in relazione
versioni diverse l’una con l’altra oppure di calcolare le differenze fra di
esse;
• le regole possono includere facilitazioni per l’accesso a particolari versioni
di un’informazione atomica come la “Ultima” (che cambia ogni
volta). Regole come questa generano ogni volta risultati diversi. Questo
meccanismo può essere visto come un modo per limitare gli effetti
legati al problema della crescita esponenziale della complessità, ma rende
più difficoltosa la tracciabilità in quanto è impossibile garantire che
lo stesso risultato venga ottenuto applicando le stesse regole in istanti
di tempo diversi.
31

Versioning a supporto della collaborazione Modelli di versioning
2.3.2 Modello estensionale
Nel “versioning estensionale” tutte le versioni della stessa entità sono singolarmente
identificabili ed appartengono ad un insieme numerabile. L’utente
ottiene la versione Vj, effettua le modifiche e condivide con gli altri la nuova
versione Vj+1. Tra Vj e Vj+1 esiste una relazione di “derivazione”.
Una data versione può essere recuperata in tempi successivi, in modo
identico a come è stata creata. Le versioni della stessa entità possono essere
confrontate e relazionate attraverso l’ordinamento parziale della relazione di
“derivazione”. Le versioni e le relazioni sono tipicamente rappresentate con
un grafo simile al quello di figura 2.1 (a pagina 25).
2.3.3 Valutazione dei modelli
Si chiamano sistemi basati sulle variazioni quelli che si focalizzano sulle
differenze fra due versioni diverse di una data informazione invece che sulle
versioni stesse. Un vantaggio di questo meccanismo è che le differenze possono
essere combinate anche in molti modi che non corrispondono alle versioni
dei sistemi basati sullo stato (nei quali l’attenzione viene concentrata proprio
sulle singole versioni e non sulle differenze fra le stesse) in quanto è possibile
scegliere anche modi non previsti durante la fase di creazione delle singole
differenze. Le combinazioni ammissibili non sono tutte quelle possibili (alcune
differenze possono essere legate ad altre), ma la differenza rispetto ai
sistemi basati sullo stato è comunque notevole (vedi il modello Change set,
paragrafo 2.2.4). Questo perché tutte le versioni distinte discriminate dai
sistemi basati sullo stato, possono essere ottenute attraverso un banale meccanismo
di fusione fra la versione iniziale e la sequenza ordinata di differenze
prese in esame in questi sitemi che è solo una delle possibili permutazioni.
Una specifica versione di una informazione atomica viene generata attraverso
il meccanismo di fusione, appena citato, ogni volta che serve. Nei sistemi
basati sulle variazioni questa operazione viene effettuata attraverso regole
ben precise ovvero viene usato versioning intensionale anche per le entità
atomiche.
Nei sistemi basati sulle variazioni il numero di possibili versioni di ogni
entità atomica è elevato e, conseguentemente, il numero delle combinazioni
possibili fra le varie versioni delle varie entità che possono dar vita a configurazioni
è enorme. Il problema della complessità è ancora più evidente in questi
32

Versioning a supporto della collaborazione Unified Extensional Versioning Model
sistemi. Nei sistemi esistenti viene affrontato tramite versioning intensionale
e in generale valgono tutte le considerazioni riportate precedentemente.
Si chiamano sistemi basati sullo stato quelli che usano versioning estensionale
quando hanno a che fare con entità atomiche, pertanto, per queste
ultime, tutte le possibili versioni vengono rappresentate esplicitamente. Tali
versioni possono, per esempio, essere rappresentate in un grafo e una data
versione può essere individuata univocamente in ogni momento una volta fissato
il cammino nel grafo. Le versioni delle entità possono essere confrontate
e messe in relazione le une con le altre grazie ad una relazione parziale di
“derivazione”. I problemi relativi all’uso del versioning intensionale, in questo
caso, non si verificano per le entità atomiche in quanto per esse viene
utilizzato il versioning estensionale.
Una critica fondamentale ai sistemi basati sullo stato è che questi offrono
meccanismi molto diversi per trattare le entità atomiche e le relazioni strutturali.
Sfortunatamente questo porta ad una proliferazione di concetti senza
risolvere i problemi del versioning intensionale in quanto lo si ritrova per la
gestione degli aspetti strutturali.
2.3.4 Una nuova alternativa: UEVM
I sistemi tradizionali, sia basati sullo stato che sulle variazioni, si comportano
in modo simile (versioning intensionale) per la gestione degli aspetti
strutturali.
Nel paragrafo successivo verrà descritto il modello Unified Extensional
Versioning Model (UEVM ). Questo modello rappresenta un nuovo approccio
che permette di utilizzare versioning esplicito anche per le relazioni strutturali.
Viene mostrato come viene minimizzato il problema dell’esplosione della
complessità e come risolve i problemi relativi al versioning intensionale per
le relazioni strutturali. Infine ha il vantaggio di offrire un approccio unificato
sia per il versioning delle entità atomiche che per le relazioni strutturali.
2.4 Unified Extensional Versioning Model
Unified Extensional Versioning Model (UEVM) è un nuovo approccio che
tratta allo stesso modo i documenti e le configurazioni. Nell’ambito della
ricerca sono state realizzate alcune implementazioni parziali e/o prototipi
basati su tale modello:
33

Versioning a supporto della collaborazione Unified Extensional Versioning Model
Versioning
Intensionale
Versioning
Estensionale
Entità atomiche
(file)
Sistemi basati
sulle variazioni
Sistemi basati sullo
stato o su UEVM
Configurazioni
Sistemi basati sulle
variazioni o sullo stato
Sistemi basati
su UEVM
Tabella 2.1: Approcci di versioning adottati dai CM sui vari tipi di entità.
• COOP/Orm: ambiente di programmazione multiutente;
• CoEd: editor collaborativo;
• Ragnarok: tool per lo sviluppo di architetture software.
UEVM definisce un proprio modello per il documento sul quale stabilisce
i criteri per il versioning. Nella paragrafo successivo verrà descritto il modello
adottato [ABCM99].
2.4.1 Il modello
Il modello del documento
Il documento è un’entità strutturata la cui struttura può essere definita,
in modo molto conveniente, con la grammatica riportata in tabella 2.2. Sostanzialmente
il documento è una struttura gerarchica, ad albero. Eventuali
legami fra documenti distinti vengono modellati tramite il concetto di link.
Il termine documento è da intendersi nel senso più generale possibile: può
essere un file, un dataset contenente qualunque tipo di informazione, un testo
in italiano, in inglese, eccetera.
Di seguito viene introdotto il significato che ha ogni nodo del modello
UEVM, in relazione alla struttura del documento:
D: rappresentazione astratta del documento.
grammatica (assioma).
È il simbolo iniziale della
A: albero. È un simbolo astratto, non terminale, che quindi non compare
nella stringa dei terminali che rappresenta il documento. Il nome del
34

Versioning a supporto della collaborazione Unified Extensional Versioning Model
D ::= A
A ::= C|L|N
C ::= A*[“dati”]
L ::= “nome”-“ver.”
N ::= “dati”
D: documento. Nodo astratto non terminale.
A: albero. Nodo astratto non terminale.
C: composizione. Nodo concreto, produzione.
L: link. Nodo concreto, produzione.
N: informazione atomica. Nodo concreto, produzione.
Tabella 2.2: Grammatica che definisce la struttura del documento.
simbolo non è stato scelto casualmente in quanto, a partire da ogni
nodo di tipo A, la grammatica produce un albero che, oltre ad essere
proprio della sequenza delle produzioni, modella anche la struttura del
documento.
N: nodi concreti, terminali, nei quali avviene l’archiviazione delle informazioni
proprie del documento. Possono contenere codice sorgente,
pagine web, immagini, filmati, file eseguibili oppure qualunque altra
informazione che non abbia a che fare con il modello del documento.
Nodi differenti possono contenere informazioni di tipo diverso: il modello
supporta nativamente documenti costituiti da informazioni di tipo
eterogeneo.
L: link, rappresentano relazioni arbitrarie fra documenti o parti di essi.
Il “nome” è l’informazione che serve per identificare univocamente il
documento e “ver.” è la particolare versione dello stesso alla quale il
link si riferisce. Si pensi, per esempio, ad un riferimento bibliografico.
Il “nome” potrebbe essere l’insieme delle informazioni:
– nome e cognome dell’autore;
– titolo dell’opera;
– casa editrice.
La versione potrebbe essere rappresentata dall’edizione. Un link con
queste caratteristiche permette di identificare univocamente la risorsa
di interesse lasciando le due entità (documento nel quale compare la voce
in bibliografia e libro a cui fa riferimento) del tutto indipendenti. Il
libro può essere aggiornato (nuove edizioni) senza pregiudicare la comprensione
del documento che lo riferisce. Questo perché il lettore può
35

Versioning a supporto della collaborazione Unified Extensional Versioning Model
comunque accedere alla versione esatta del libro che l’autore del documento
ha utilizzato per la stesura dello stesso. L’autore del documento
può, a sua volta, aggiornarlo e, se lo ritiene opportuno, modificare la
bibliografia in modo da riferire l’ultima versione del libro, come una
qualunque altra.
C: relazioni di composizione fra l’intero documento e le parti di esso. Il
concetto di composizione è quello che dà vita alle relazioni genitorefiglio
nell’albero del documento. Si pensi alle relazioni che si hanno
fra un libro e l’insieme dei capitoli che lo costituiscono, fra un capitolo
e l’insieme di paragrafi che lo costituiscono, eccetera. Queste
relazioni trasformano un insieme “piatto” 1 di informazioni in un’entità
strutturata. In un libro, se cambia una frase, cambia il paragrafo
che la contiene e cambia anche il capitolo contenente il paragrafo. In
ultima analisi cambia tutto il libro. Questo tipo di relazione è ben diverso
dal collegamento modellato attraverso i nodi di tipo L descritto
in precedenza.
Documenti di tipo tradizionale, ovvero che non supportano internamente
informazioni strutturate e collegamenti verso altri documenti, possono essere
inquadrati nel modello: sono schematizzabili tramite un unico nodo di tipo
N.
Un esempio di applicazione della grammatica, che permette di vedere
come questa generi un documento strutturato ad albero, è riportato in
figura 2.3:
• l’assioma della grammatica è D, il documento;
• la prima produzione genera A: questo risultato sottolinea il fatto che il
documento è strutturato come un albero;
• la seconda produzione, a partire da A, genera C (avrebbe potuto generare
anche un nodo di tipo N oppure L): l’entità astratta albero ha C
come radice;
• la produzione seguente, applicata a C, permette, opzionalmente 2 , di
1 La struttura gerarchica libro→capitoli→paragrafi→. . . , è astratta e prettamente di
convenienza, il libro, di fatto, è una successione di parole.
2 L’opzionalità è indicata tramite parentesi quadre.
36

Versioning a supporto della collaborazione Unified Extensional Versioning Model
D
D A
D
A
D
[data]
A
C
A A
[data] N
A
A
N L
D
A
[data]
A A
D
D
A
[data]
N L
A
C
[data]
[data]
A
N
Figura 2.3: Esempi di applicazione della grammatica.
associargli dei dati ed un numero di figli che va da zero a infinito 3 . I
figli, a loro volta, sono strutturati ad albero e, nell’esempio, sono due;
• le produzioni associate a tali alberi generano un nodo C ed un nodo N;
• andando avanti si ottiene la struttura mostrata in basso a sinistra nella
figura (che è solo una fra quelle che sarebbe stato possibile ottenere).
A tale struttura corrispondono solo simboli terminali e pertanto non è
possibile applicare ulteriori produzioni.
La figura riportata in basso a destra evidenzia ulteriormente come il documento
generato dalla grammatica abbia una struttura ad albero.
Si osservi che sono le relazioni genitore-figlio che nascono dalle produzioni
applicate a nodi concreti a modellare la struttura del documento.
3 Come per le espressioni regolari: il simbolo asterisco indica una qualunque quantità
fra zero ed infinito, estremi inclusi.
N
37

Versioning a supporto della collaborazione Unified Extensional Versioning Model
C
C
N C
N N N N
N
C
N N
L
N
C
C L
Figura 2.4: Esempi di documento.
Esempio di documento strutturato
N
L
C
N N
La figura 2.4 mostra un esempio di documento strutturato. Nella sezione
sinistra della figura è presente un singolo documento strutturato ad albero.
In quella di destra tre documenti strutturati ad albero sono collegati l’uno con
l’altro. Le linee indicano le relazioni di composizione interne al documento,
mentre le frecce rappresentano riferimenti (link) fra documenti diversi.
Riprendendo l’esempio del libro, precedentemente menzionato, è possibile
mostrare questi concetti più concretamente.
La sezione di sinistra della figura 2.5 mostra come un libro sia costituito da
tre capitoli dove il primo e il terzo contengono, a loro volta, due paragrafi. Le
relazioni fra il libro, i capitoli e i paragrafi sono, rispettivamente, “costituito
da” e “contiene” e la struttura totale rappresenta un’unica entità.
Un altro esempio di documento strutturato che include anche nodi di
tipo L può essere rappresentato da un’applicazione Java costituita da classi
e package. La sezione di destra della figura 2.5 mostra come l’applicazione
sia costituita da una classe che ne importa altre due: A e B. Le relazioni
38

Versioning a supporto della collaborazione Unified Extensional Versioning Model
Libro
Cap.1 Cap.2 Cap.3
Par.1 Par.2 Par.1 Par.2
Membro 1
Import
Classe A
Membro 2
Applicazione
Classe 1
Membro 1 Membro 2
Super C.
Membro 3
Membro 1
Import
Classe B
Membro 2
Figura 2.5: Altri esempi di documenti strutturati: un libro e del codice Java.
fra i membri della classe e la classe stessa sono dello stesso tipo di quelle
del libro: “costituito da” e/o “contiene”. Viceversa le relazioni “Import” e
“Super Class” sono concettualmente diverse e sono modellate tramite link.
Che siano diverse si capisce semplicemente provando ad asserire: la classe
B “è costituita da” la classe A il che è, ovviamente, errato. In ogni modo le
classi A e B potrebbero venire incluse in altre applicazioni.
Versioning
In generale sia la struttura che il contenuto di un documento possono
variare nel tempo. In UEVM tutti i tipi di nodo vengono esplicitamente
versionati. La creazione di una nuova versione di un nodo avviene in
corrispondenza di uno dei seguenti eventi:
• per i nodi N o C quando cambiano i dati locali (interni al nodo stesso);
• per i nodi C anche quando viene aggiunto, rimosso o modificato un
qualunque figlio;
39

Versioning a supporto della collaborazione Unified Extensional Versioning Model
• per i nodi L quando cambia o il “nome” o la versione (“ver.”).
Le modifiche al documento avvengono durante una sessione ovvero una lunga
transazione. La durata di una sessione dipende dall’utente il quale, esplicitamente
o implicitamente, la avvia e la termina. Durante una sessione può
essere creata al più una nuova versione di ogni nodo, compatibilmente con le
regole riportate precedentemente. Più modifiche ai dati di un nodo all’interno
della solita sessione equivalgono ad una sola modifica che le comprende tutte.
Equivalentemente più operazioni di aggiunta, rimozione o modifica di uno o
più figli di un nodo di tipo C (all’interno della medesima sessione) danno vita
ad una sola nuova versione. La lunghezza della sessione, ovvero il numero
di cambiamenti che confluiscono nella nuova versione, è un parametro che
può essere usato per controllare la granularità del versioning. Quando una
sessione termina la versione che viene creata di un nodo non può più essere
modificata.
Le versioni sono legate tramite la relazione “derivato-da” e possono essere
rappresentate da un arbitrario DAG 4 . Il meccanismo che gestisce il versioning
può gestire lo sviluppo concorrente ed effettuare la fusione delle modifiche
sul documento, sia per quel che riguarda le informazioni atomiche che quelle
strutturali.
Rispetto al singolo documento una sessione può portare alla nascita di
una nuova versione di tutto il documento. Alla fine della sessione si hanno
zero o una nuova versione di ogni nodo. Come messo in evidenza dall’elenco
sopra riportato, i nodi di tipo C vengono considerati modificati anche quando
viene aggiunto, rimosso o modificato un qualunque figlio: questo genera un
effetto conosciuto come “propagazione dei cambiamenti” [Kat90]. Ogni modifica
darà vita ad una nuova versione di tutti gli antenati (genitore, nonno,
bisnonno, etc.) e si propagherà verso la radice. Il fatto che solo una nuova
versione di un genitore può nascere all’interno della stessa sessione, può
essere visto come un meccanismo utile a concentrare le versioni.
Questo meccanismo automatico di propagazione è consistente con la percezione
che si ha delle modifiche architetturali in un’informazione strutturata.
Come è già stato anticipato la modifica di un capitolo in un libro fa in modo
che tutto il libro sia diverso. In altre parole la versione di un documento
determina univocamente quali nodi interni questo contiene e in quali versioni.
4 Directed Acyclic Graph: grafo aciclico orientato.
40

Versioning a supporto della collaborazione Unified Extensional Versioning Model
Rispetto alle relazioni fra documenti il parametro di versione (“ver.”),
memorizzato all’interno di un nodo L, identifica la versione del documento
referenziato. Se si intende riferire una versione diversa rispetto a quella memorizzata
nel nodo L occorre creare una nuova versione di L che la contenga
(in ultima analisi, per propagazione, viene generata una nuova versione di
tutto il documento che contiene L). Il modello impone che l’aggiornamento
di un link, in modo che referenzi una versione diversa del documento al
quale si riferisce, generi una nuova versione del documento che lo contiene.
Quando e come questo avvenga non viene specificato dal modello: la politica
verrà scelta in base alle singole esigenze del contesto applicativo nel quale
si intende utilizzare UEVM. In generale comunque è importante ricordare
che il meccanismo di gestione della sessione può essere usato per gestire la
granularità del versioning.
Versioning di un singolo documento
La figura 2.6 mostra come evolve la struttura di un documento sottoposto
a modifiche.
C
C
1 2 3
N C
1 2 1 2
N N N N
a) Struttura iniziale del
documento
C
C
C
N C
N
N N N
3.1
b) Il nodo 3.1 è stato
modificato
C
2
C
N
C
N
N N N
c) Anche il nodo 2 è stato
modificato
Figura 2.6: Alcuni cambiamenti all’interno della stessa sessione.
In figura 2.6.b i dati locali del nodo 3.1 sono stati modificati e quindi si
ha la nascita di una nuova versione di tale nodo. Per propagazione viene
creata una nuova versione anche del padre (nodo 3) e quindi della radice (si
ha una nuova versione del documento). In figura 2.6.c l’utente ha modificato
anche il nodo 2. Questo evento non innesca la propagazione perché è già
41

Versioning a supporto della collaborazione Unified Extensional Versioning Model
stata creata una nuova versione della radice (che in questo caso coincide con
il genitore del nodo modificato) all’interno della stessa sessione. Tale versione,
quando verrà resa persistente con la chiusura della sessione, includerà
entrambe le modifiche. Questo fenomeno permette all’utente di controllare
quando generare nuove versioni oltre a quali modifiche debbano contenere.
È possibile associare al documento in figura 2.6 il significato di libro con
tre capitoli, come mostrato in figura 2.5. La modifica di uno dei paragrafi
genera una nuova versione del libro così come varie modifiche apportate tutte
all’interno della stessa sessione. Questo comportamento equivale a quello che
si avrebbe se il modello ignorasse gli aspetti strutturali e tutti i paragrafi
del libro fossero memorizzati all’interno di un unico file. Il versioning degli
aspetti strutturali che si basa sulla propagazione delle modifiche si comporta
come se fosse in uso una gestione della struttura molto più primitiva (quindi
semplice ed immediata da comprendere).
Versioning di più documenti legati fra loro
D1 D1 D1
C
C
L
N
C L
N
D3 D3 C
D3
C
N
N N
D2 D2 C
D2
C
L
N N
N
L
N
C L
L
N N
N
N
N
N
L
C
N
C
C
N N
Figura 2.7: La modifica di un link genera la nascita di una nuova versione
del documento.
L
N
L
N
C
N
42

Versioning a supporto della collaborazione Unified Extensional Versioning Model
In questo esempio viene considerato il caso di tre documenti legati fra
loro, come mostrato in figura 2.7. Eventuali modifiche a D2 e D3 generano
nuove versioni di essi, ma non si ripercuotono, per propagazione, a D1. Nella
sezione centrale della figura viene mostrata la situazione dopo una sessione
di modifica sul documento D2 e una sul documento D3. La sezione di destra
mostra lo stato dopo un’altra sessione su D2 e una su D1 che è risultata
necessaria per poter riferire le ultime versioni degli altri due documenti. Occorre
notare che è l’utente a decidere di effettuare tale aggiornamento su D1:
avrebbe potuto decidere di non intervenire o di intervenire collegando una
qualunque altra versione di tali documenti diversa dall’ultima. La struttura
in questo caso è un piccolo grafo, ma, applicando gli stessi meccanismi, è possibile
utilizzare i link per creare DAG più complessi. La figura 2.7 potrebbe
riferirsi ad un software in fase di sviluppo nel quale i sorgenti dipendono l’uno
dall’altro come raffigurato in figura 2.5.
2.4.2 Conclusioni
In questo paragrafo vengono discusse alcune conseguenze legate all’uso
del modello UEVM ed effettuati alcuni confronti con il modello intensionale.
UEVM dal punto di vista dell’utente
Dal punto di vista dell’utente UEVM unifica i concetti relativi alla gestione
delle versioni delle entità atomiche con quelle delle configurazioni. L’utente
ha la possibilità di identificare, ispezionare, comparare e ragionare sulle
proprietà delle configurazioni sia in termini di contenuti che strutturali.
Il versioning intensionale, in confronto, è molto più complesso da comprendere.
Infatti, per poter estrarre le configurazioni, l’utente è obbligato a
capire il meccanismo delle regole e ad imparare un determinato linguaggio
necessario alla loro descrizione.
Gestione dell’esplosione combinatoria
L’esplosione combinatoria del numero possibile delle configurazioni è un
problema fondamentale che ogni modello si trova a dover risolvere. In riferimento
all’esempio, molto semplice, mostrato in figura 2.7 nel documento D3
si hanno 2 3 = 8 possibili configurazioni ottenibili permutando le varie versioni
dei nodi presenti. In realtà solo 3 di queste sono state create ed hanno
43

Versioning a supporto della collaborazione WebDAV
senso per l’utente. Dal punto di vista dei link esterni esistono 3 versioni del
documento D2 e 2 versioni di D3 per un totale di 6 possibili combinazioni,
ma, anche in questo caso, non tutte sono necessarie. Il modello UEVM riesce
a minimizzare il problema creando esplicitamente solo le permutazioni
necessarie.
2.5 WebDAV
World Wide Web Distributed Authoring and Versioning (WebDAV) fornisce
le specifiche per un sistema di authoring collaborativo asincrono basato
sull’utilizzo di Internet [WCJRg03]. WebDAV estende il protocollo Http,
garantendo l’interoperabilità attraverso un’interfaccia comune per l’accesso
ai dati. L’obiettivo di WebDAV è di consentire l’elaborazione delle risorse
attraverso il Web, come se fosse un file system.
Importanti software house come ad esempio Microsoft, Netscape, Xerox,
IBM e Novell hanno contribuito allo sviluppo di WebDAV. Attualmente
esistono diverse soluzioni commerciali ed open source che lo implementano,
ad esempio Sharepoint Portal Server (Microsoft), Netware 6 (Novell), Zope,
Moddav. La tipologia dei client è molto varia, possono essere integrati in
comuni browser web o essere client dedicati, con o senza interfaccia grafica.
Gli sviluppatori di WebDAV (Internet Engineering Task Force) hanno
stabilito le seguenti sei estensioni al protocollo Http.
Version Management. Permette il salvataggio delle revisioni effettuate
sui documenti e la collaborazione di più utenti nella stesura di questi.
Advance Collections. Le collection forniscono un meccanismo per l’organizzazione
gerarchica delle risorse. Una collection è una lista di URI. Il ruolo
è simile a quello delle directory di un file system. Una risorsa può avere più
URI e quindi appartenere a più collezioni. A loro volta le collezioni possono
essere ordinate anche indipendentemente dalla proprietà.
Access Control. Controlla gli accessi ai documenti attraverso il principio
dell’autenticazione. Le applicazioni WebDAV devono supportare Http Digest
Authentication, appartenente alle specifiche del protocollo Http 1.1.
44

Versioning a supporto della collaborazione Revision Control System (RCS)
Overwrite Prevention. Le operazioni di scrittura, quando consentite,
prevedono un meccanismo di lock dei documenti. Esistono due tipologie
di blocco: exclusive write lock e shared write lock. Il primo consente la scrittura
solo a colui che l’ha bloccata, mentre il secondo permette l’authoring
multiutente. È anche presente un meccanismo di notifica del rilascio delle
risorse verso gli utenti interessati.
Properties. Ogni documento ha un insieme di informazioni correlate (metadati),
come ad esempio autore, data di creazione, soggetto, eccetera. Tali
informazioni sono rappresentate con coppie “”. Il nome è una
URI e il valore è codificato in XML. Le proprietà possono essere live o
dead. Nel primo caso è il server a gestire la coerenza sintattica e semantica,
mentre nel secondo è il client e il server si limita a registrare il valore delle
proprietà parola per parola. In generale l’approccio di WebDAV è orientato
alla memorizzazione e ricerca delle informazioni, piuttosto che alla loro
semantica.
Namespace Management. WebDAV offre la possibilità di copiare, spostare
e ricevere la lista dei documenti nelle collection. La copia consente
anche di cambiare i permessi associati alla risorsa. Il recupero delle informazioni
può avvenire sia rispettando l’ordinamento gerarchico delle collection
sia applicando filtri di ricerca sulle proprietà.
2.6 Revision Control System (RCS)
RCS permette di gestire il versioning di file automatizzando le operazioni
di salvataggio, recupero, registrazione (logging), identificazione e fusione
delle varie revisioni. RCS è utile per documenti testuali che devono essere
revisionati spesso come codice sorgente, documentazione, eccetera. Basa il
proprio principio di funzionamento sul modello checkout/checkin (sotto paragrafo
2.2.1), è un sistema basato sullo stato ed utilizza il modello estensionale
per il versioning dei singoli file (che, in questo caso, corrispondono alle entità
atomiche, paragrafo 2.3).
RCS fu introdotto da Walter Tichy (Purdue University) all’inizio degli
anni ottanta come evoluzione di SCCS (Source Code Control System) migliorandone
l’interfaccia utente e il sistema di salvataggio delle versioni in
45

Versioning a supporto della collaborazione Revision Control System (RCS)
modo da rendere più efficiente l’accesso ai dati. RCS salva la versione più
recente in modo integrale mentre per quelle precedenti memorizza soltanto
le differenze (delta). RCS è parte del progetto GNU [Gnu03] e utilizza il
pacchetto GNU Diffutils per la gestione delle differenze.
Le funzionalità che mette a disposizione (descritte in [Gnu93]) non sono
molte e risulta utile elencarle:
1. permette di salvare e recuperare varie revisioni di documenti testuali.
Le revisioni possono essere recuperate sulla base di: numero di
revisione, nome simbolico, data, autore e stato del documento;
2. mantiene la completa storia dei cambiamenti. Ad ogni modifica salva
l’autore e la data, inoltre impone all’autore di riportare una descrizione
della modifica utile per tracciare lo sviluppo del documento senza
ricorrere a confronti espliciti fra le revisioni;
3. evita i conflitti di accesso. Impedisce a due o più sviluppatori di intervenire
contemporaneamente sullo stesso documento evitando così che
alcune modifiche ne corrompano altre (strategia conservativa);
4. modella attraverso un albero le relazioni fra le revisioni. Questo permette
di creare vari branch a partire da una di esse;
5. permette di fondere revisioni (appartenenti a branch diversi) segnalando
all’utente eventuali conflitti (che, quindi, possono essere risolti);
6. permette di assegnare alla varie revisioni opportuni nomi simbolici
(come: “stable”, “experimental”, etc.) con lo scopo di descrivere le
configurazioni in modo semplice e diretto;
7. minimizza lo spazio su disco memorizzando solo le differenze fra le varie
revisioni e ricorrendo ad opportuni algoritmi di compressione. È utile
osservare che memorizzare le differenze per minimizzare lo spazio su
disco non fa di RCS un sistema basato sulle variazioni;
Altrettanto utile risulta la descrizione del paradigma di interazione fra
l’utente ed RCS [Kie94]. Per prima cosa occorre mettere in evidenza che
l’utente opera su copie locali dei file e non direttamente sul repository (copia
principale dei dati contenente tutte le informazioni relative allo storico; l’accesso
al repository è subordinato al sistema di gestione delle versioni). La
46

Versioning a supporto della collaborazione Revision Control System (RCS)
fase di checkout serve per creare la copia locale mentre la fase di checkin (o
commit) permette di aggiornare il repository (generando una nuova revisione).
La gestione degli accessi concorrenti avviene tramite il locking (blocco)
dei file.
Supponendo di voler iniziare a gestire le revisioni di un file, la prima cosa
che occorre effettuare è il checkin del file, operazione che permette ad RCS di
copiare il documento nel repository e partire con la numerazione delle revisioni.
Quando l’utente intende recuperare il file effettua il checkout. Il checkout,
se non esplicitamente specificato, fornisce il documento all’utente per la sola
lettura. In questo caso, se l’utente modificasse la propria copia locale e cercasse
di effettuare il checkin, otterrebbe un messaggio di errore. Per poter
effettuare modifiche è necessario acquisire il file attraverso un checkout con
lock che garantisce all’utente il diritto esclusivo di modifica del file. RCS non
permette, ovviamente, a due utenti distinti di acquisire contemporaneamente
il blocco sullo stesso file: il secondo utente viene avvertito con un messaggio
che mostra il nome dell’utente che ha il lock in modo da poterlo contattare,
se necessario.
Fase 1
Fase 2
Fase 4
File1 File2 File3
r1.1 r1.1 r1.1
r1.2 r1.2
r1.3
Fase 5
Fase 3
Configurazione con
etichetta: stabile1.0
Configurazione con
etichetta: beta1
Figura 2.8: Gestione delle configurazioni in RCS.
47

Versioning a supporto della collaborazione Revision Control System (RCS)
La gestione degli aspetti strutturali è a carico dell’utente (il modello adottato
è intensionale) il quale, se intende mantenere le revisioni di un progetto
costituito da più file, deve raggruppare le varie versioni appartenenti ad una
data configurazione etichettandole durante la fase di checkin (“tagging”, sotto
paragrafo 2.2.1). Un esempio è utile per chiarire il concetto (figura 2.8). Si
ipotizzi di dover operare con un progetto di sviluppo di un software costituito
da tre file e che, al raggiungimento della prima versione beta, lo sviluppatore
decida di utilizzare RCS per tracciare le modifiche durante la fase di bug-fix 5 .
Di seguito viene riportato l’andamento temporale degli eventi:
• Fase 1: viene effettuato il checkin dei tre file etichettando la configurazione
come “beta1”;
• Fase 2: viene scoperto e corretto un bug su File1, il sistema, al checkin,
associa il numero di versione 1.2 al file corretto;
• Fase 3: viene scoperto e corretto un bug su File2, il sistema, al checkin,
associa il numero di versione 1.2 al secondo file corretto;
• Fase 4: viene scoperto e corretto un secondo bug su File1 : nasce in
questo modo la versione 1.3 del primo file;
• Fase 5: viene ritenuto che il programma sia pronto per il rilascio e
l’ultima versione di ogni file viene etichettata come appartenente alla
configurazione “stabile1.0”.
Con il meccanismo delle etichette l’utente ha sempre la possibilità di accedere
alle configurazioni marcate senza ambiguità (in questo esempio “stabile1.0” e
“beta1”) anche se il sistema si limita a versionare i file singolarmente.
RCS permette di effettuare il checkout sulla base della data di modifica
dei file. Questa operazione permette di scegliere una data ed estrarre tutti i
file modificati entro e non oltre tale data. In questo modo è possibile navigare
manualmente nello storico delle configurazioni anche se queste non sono state
precedentemente etichettate.
Entrambi i meccanismi descritti, sia quello basato su tagging che quello
basato su data, permettono di navigare nello storico delle configurazioni a
patto che la struttura delle stesse non vari nel tempo. Questo aspetto è stato
5 Fase di sviluppo nella quale non vengono aggiunte nuove funzionalità al programma,
ma vengono ricercati e corretti eventuali problemi nell’implementazione delle funzionalità
correnti.
48

Versioning a supporto della collaborazione Concurrent Versions System (CVS)
messo in evidenza descrivendo il modello basato su composizione, descritto
nel sotto paragrafo 2.2.2.
2.7 Concurrent Versions System (CVS)
CVS è stato rilasciato da Dick Grune nel 1986, come collezione di script,
con la finalità di superare i limiti ben noti di RCS, sistema dal quale deriva.
Inizialmente CVS usava RCS per gestire le versioni dei singoli file
(vedi [FB03]) e tutt’oggi continua ad usare il formato di salvataggio dei dati
di RCS. Tre anni dopo Brian Berliner riscrisse CVS con il linguaggio di
programmazione C e successivamente Jeff Polk e Jim Kingdon aggiunsero
ulteriori caratteristiche importanti.
2.7.1 CVS, evoluzione di RCS
CVS è a tutti gli effetti il successore di RCS da cui si differenzia per le
seguenti caratteristiche:
• ha la capacità di gestire le directory. Questo permette di operare su
progetti complessi, così come su singoli file;
• permette la modifica di file senza che questi debbano essere bloccati, a
tutto vantaggio del lavoro di gruppo. Nel caso si verifichino situazioni
di conflitto le rileva e ne permette la gestione (strategia ottimistica);
• è capace di operare in ambienti distribuiti permettendo agli sviluppatori
di accedere al codice sorgente del progetto attraverso interconnessioni
di rete.
2.7.2 Concetti di base
CVS richiede che ci sia una certa coordinazione fra gli sviluppatori 6 in
quanto non permette (o meglio scoraggia visto che tale strategia è comunque
applicabile) il blocco dei file, basando il proprio principio di funzionamento
sul paradigma copy-merge (sotto paragrafo 1.2.4, pagina 17) e sul modello
relativo alle transazioni estese nel tempo (sotto paragrafo 2.2.3).
6 Per questo mette a disposizione, oltre all’infrastruttura necessaria alla gestione
delle versioni, alcune funzionalità tipiche dei sistemi groupware atte ad agevolare la
cooperazione.
49

Versioning a supporto della collaborazione Concurrent Versions System (CVS)
Le fasi chiave che normalmente vengono percorse nell’uso di CVS sono le
seguenti:
1. lo sviluppatore crea una propria copia di lavoro locale (contenente tutti
i file relativi al progetto). Questa operazione è chiamata checkout;
2. lo sviluppatore opera liberamente sulla propria copia di lavoro. Contemporaneamente
altri sviluppatori possono fare lo stesso e, operando
su copie di lavoro separate e quindi indipendenti, senza interferire l’uno
con l’altro;
3. lo sviluppatore, una volta completate le modifiche, effettua il commit
(o checkin). Tale operazione prevede l’aggiornamento del repository,
accompagnato da un messaggio utile per comprendere l’entità delle
modifiche apportate;
4. gli sviluppatori possono chiedere al server CVS se sono state apportate
variazioni rispetto alla propria copia locale. In caso affermativo il sistema
permette loro di ri-sincronizzare la propria copia con il repository
in modo automatico.
Si verifica un conflitto quando due sviluppatori apportano modifiche nello
stesso punto di un certo file ed entrambi intendono effettuare il commit:
il primo di essi effettuerà l’aggiornamento del repository normalmente (il
sistema non può sapere che un altro ha effettuato modifiche nello stesso punto
finché questo non glielo comunicherà) mentre il secondo verrà avvertito dal
sistema che si è verificato il conflitto. In tal caso il sistema mostra l’entità
del problema (mostrando le righe di codice interessate) mettendo il secondo
sviluppatore nelle condizioni di poterlo risolvere. Solo a questo punto CVS
permetterà al secondo sviluppatore di portare a termine il commit.
Esiste un’altra situazione che può verificarsi come conseguenza dell’utilizzo
del paradigma copy-merge. Tale scenario viene introdotto come una
rivisitazione dell’esempio descritto nel sotto paragrafo 2.2.3. A e B sono due
sviluppatori, la sequenza temporale degli eventi è la seguente:
1. A effettua il checkout;
2. B effettua il checkout;
3. A apporta delle modifiche ed effettua il commit;
50

Versioning a supporto della collaborazione Concurrent Versions System (CVS)
4. A apporta ulteriori modifiche ed effettua un secondo commit;
5. B inizia a lavorare (è importante osservare che la sua copia non è
aggiornata);
6. B vuole effettuare il commit.
Lo sviluppatore B può trovarsi di fronte a tre situazioni possibili:
• ha operato su dei file che non sono stati modificati anche da A. In tal
caso il commit avviene con successo;
• uno o più file modificati (da B) sono stati modificati anche da A, ma
senza conflitti. In tal caso il sistema non permette il commit indicando
a B che, per poter procedere, deve prima effettuare un update. Questa
operazione consiste nell’integrare le modifiche di A nella propria copia
di lavoro e, in questo caso, il sistema è in grado di portare a termine
l’operazione in autonomia. A questo punto il sistema permette a B di
effettuare il commit;
• è presente almeno un conflitto con le modifiche di A. In tal caso il
sistema non permette il commit indicando a B che, per poter procedere,
deve effettuare un update che però, in questo caso, richiede l’intervento
manuale per la risoluzione dei conflitti. Solo dopo tale risoluzione il
sistema permette a B di effettuare il commit.
Revisioni, branch e configurazioni
Come in RCS ogni file del progetto ha un proprio numero di revisione,
indipendente dagli altri file. Se due file hanno numero di revisione diverso
significa semplicemente che uno è stato modificato (con relativa operazione
di commit) più volte dell’altro.
Il problema della gestione delle configurazioni viene affrontato come in
RCS (paragrafo 2.6 e figura 2.8). Da un lato è possibile selezionare i file associati
ad una certa configurazione conoscendo l’istante temporale nel quale
è stata creata, dall’altro assegnando esplicitamente delle etichette alle configurazioni
di maggior rilievo (come le release pubbliche). Lo sviluppatore
può quindi richiedere a CVS i file appartenenti ad una configurazione in due
modi possibili:
• richiedendo la configurazione creata nel giorno “dd/mm/yy”;
51

Versioning a supporto della collaborazione Concurrent Versions System (CVS)
• richiedendo la configurazione con nome “nome”.
Entrambi gli approcci hanno vantaggi e svantaggi. Il primo permette di
accedere a tutte le configurazioni create (se due o più configurazioni sono
state create lo stesso giorno il sistema mette a disposizione la possibilità di
inserire anche l’ora) con lo svantaggio di non aver altri riferimenti eccetto la
data. Il secondo permette l’accesso diretto alle configurazioni più importanti
tramite etichette, che essendo testuali possono essere auto-esplicative, con lo
svantaggio che queste devono essere applicate a priori dagli sviluppatori.
In CVS con branch si intende una linea di sviluppo parallela rispetto al
ramo principale. Con CVS è possibile creare un numero arbitrario di branch,
anche se, normalmente, è un’operazione poco consigliabile (la gestione di
molti rami di sviluppo paralleli è complessa). È possibile creare derivazioni
a partire da branch esistenti (in tal caso il ramo dal quale il branch deriva si
considera il principale).
Un’operazione legata al branching è merge: consiste nell’integrare le modifiche
apportate su un ramo in un altro. Questa operazione può essere del
tutto automatica in caso di assenza di conflitti o assistita, nel caso in cui questi
si verifichino, per la loro risoluzione. In riferimento all’esempio mostrato
in figura 2.1 (a pagina 25) la nascita di un nuovo branch coincide con la creazione
di una nuova diramazione, mentre l’operazione di merge corrisponde al
concetto di convergenza.
Creare branch può essere utile per vari motivi, un caso tipico è quello
relativo alla risoluzione di bug. Uno scenario usuale è quello in cui tali bug
vengono segnalati dagli utenti. È ragionevole pensare che questi abbiano a
disposizione l’ultima release pubblica che, nell’ipotesi in cui lo sviluppo del
software continui ininterrotto, sarà antecedente all’ultima release presente nel
repository. In tal caso alcuni sviluppatori creeranno un branch a partire dalla
configurazione relativa alla release in questione in modo da poter operare, al
fine di risolvere il problema, in autonomia dagli altri che stanno portando
avanti lo sviluppo sul ramo principale. Non appena il bug è stato risolto è
utile effettuare un merge delle modifiche sul ramo principale per eliminare il
problema anche dal ramo di sviluppo.
52

Versioning a supporto della collaborazione Subversion
2.8 Subversion
Subversion è un sistema di controllo delle versioni open source ed è in
grado di gestire allo stesso modo file e directory [Lin05, CSFP04, Col05b].
Permette l’accesso al repository tramite rete e, in generale, ha tutte le caratteristiche
interessanti di CVS. Questo perché il software per la collaborazione
“SourceCast”, prodotto e distribuito da “CollabNet, Inc.”, inizialmente integrava
CVS per la gestione delle versioni anche se non era ritenuto all’altezza
della situazione per bug noti e alcune caratteristiche mancanti. Pertanto,
nel 2000, fu deciso di introdurre un nuovo sistema di gestione delle versioni
ispirato a CVS (standard di fatto nel settore del software open source). Fu
riscritto da zero e ha una serie di caratteristiche di rilievo, descritte di seguito
(vedi [Col05a]).
Versioning delle directory. CVS traccia soltanto la storia dei file individualmente,
viceversa Subversion implementa una sorta di file system virtuale
versionato nel quale viene applicato il versioning all’intero albero radicato su
una directory.
Storico esplicito delle configurazioni. CVS si limita al versioning del
contenuto dei file e non è possibile tener traccia di operazioni come l’aggiunta,
lo spostamento o la cancellazione di alcuni di essi. Inoltre in CVS non è
possibile rimuovere un file, crearne uno nuovo con lo stesso nome e far sì
che questo abbia uno storico proprio: quello che succede è che il nuovo file
eredita lo storico di quello vecchio. Con Subversion è possibile effettuare
queste operazioni in modo del tutto trasparente con la garanzia che saranno
versionate esattamente come le modifiche interne ai file.
Commit atomici. L’aggiornamento del repository in Subversion avviene
in modo atomico. Un’operazione di commit può andare a buon fine (e in tal
caso il repository viene aggiornato sulla base di tutte le modifiche effettuate)
oppure no. In questo secondo caso il repository non viene modificato. In CVS
questo non succede e può accadere che finiscano nel repository solo una parte
delle modifiche apportate con gli inconvenienti che questo può generare.
53

Versioning a supporto della collaborazione Subversion
Versioning dei metadati. È possibile associare ad ogni file e ad ogni
directory un set arbitrario di metadati (nella forma chiave-valore). Tali
metadati sono versionati da Subversion esattamente come i contenuti.
Vari metodi per l’accesso al repository. Subversion permette l’accesso
al repository in vari modi diversi, uno dei più importanti è attraverso il protocollo
WebDAV (paragrafo 2.5) con una estensione per il server web Apache
(vedi [Fou05c]). Questo porta vantaggi in termini di stabilità e interoperabilità
per non parlare del fatto che molte caratteristiche come l’autenticazione
lato server, la gestione delle autorizzazioni, la compressione dei dati in fase
di trasmissione e tante altre sono supportate nativamente dalla struttura.
Subversion mette a disposizione anche un server e un protocollo proprietario
più “leggeri” utilizzabili, se necessario, attraverso un tunnel SSH 7 . Infine è in
grado di gestire il repository direttamente su file system, approccio utile per
versionare progetti in locale.
Gestione dei dati unificata. Subversion gestisce le differenze in formato
binario e quindi opera efficientemente su file in formato testuale o non
testuale.
Gestione efficiente di Tag e Branch. Il tempo necessario per creare nuovi
branch e tag non è proporzionale alla dimensione del progetto. Subversion
effettua tali operazioni in un tempo costante.
Manutenzione, sviluppo e integrazione. Subversion è stato progettato
in modo estremamente modulare, è costituito da una collezione di librerie C
condivise e da un insieme ben documentato di API (Application Program
Interface). La manutenzione e l’aggiunta di nuove funzionalità sono operazioni
effettuabili semplicemente ed inoltre è possibile integrare agevolmente
Subversion all’interno di altre applicazioni.
Portabilità. Subversion è stato scritto utilizzando APR (Apache Portable
Runtime project, vedi [Fou05b]). Questo significa che Subversion può operare
su ogni sistema operativo nel quale è in grado di operare il server Http
Apache: Linux, tutti i sistemi della famiglia BSD, Mac OS X, Windows,
Netware ed altri.
7 Per reperire dettagli su SSH, la shell sicura, un buon punto di partenza è [Ope05].
54

Versioning a supporto della collaborazione Subversion
2.8.1 Concetti di base
Il paradigma utilizzato per la gestione dell’accesso concorrente è il medesimo
di CVS: copy-merge (descritto nel paragrafo 2.7). Il paradigma che
prevede il lock delle risorse (descritto nel sotto paragrafo 1.2.4 a pagina 17)
è sconveniente per vari motivi:
• possono sorgere problemi di amministrazione. Si pensi al caso in cui un
utente blocchi un file e si dimentichi di averlo fatto. Un altro utente,
interessato alla modifica di quel file, può perdere varie ore di lavoro per
risolvere la questione;
• si crea una serializzazione del lavoro non necessaria. Se due utenti intendono
modificare parti diverse dello stesso file (senza conflitti per ipotesi)
non possono farlo e l’uno deve attendere il termine della modifica
dell’altro;
• genera una falsa sensazione di sicurezza. Siano A e B due file dipendenti
l’uno dall’altro e S1 e S2 due sviluppatori. Si supponga che S1
abbia acquisito il blocco su A e S2 su B. In questo caso S1 e S2
potrebbero sentirsi autorizzati a modificare i file come meglio credono,
avendone acquisito il lock, ma le modifiche apportate potrebbero essere
incompatibili dato che i due file dipendono l’uno dall’altro.
Per quanto riguarda l’interazione con il sistema ed i concetti branch e merge
è possibile, seppur con qualche differenza, fare riferimento al paragrafo 2.7
nel quale tali argomenti vengono trattati per CVS in quanto le differenze, tra
i due sistemi, non sono significative ai fini di questo lavoro.
Numerazione esplicita delle configurazioni
La numerazione delle versioni viene gestita a livello globale e non relativamente
a singoli file. Questo vuol dire che le varie configurazioni, che nascono
durante l’evoluzione del progetto, hanno un proprio numero di versione.
Il meccanismo di assegnazione dei numeri di versione viene mostrato con
un esempio in figura 2.9. È stato ipotizzato che il progetto venga versionato
fin dall’inizio, come conseguenza la prima configurazione, contenente soltanto
una directory vuota, ha numero di versione 0. In seguito viene aggiunta una
nuova directory contenente due file ed eseguito il commit. Il sistema assegna
numero di versione 1 alla nuova configurazione. Lo sviluppo continua e, di
55

Versioning a supporto della collaborazione L’ambiente integrato COOP/Orm
0 1 2 3
Figura 2.9: Evoluzione delle versioni in Subversion.
commit in commit, vengono create nuove versioni associate a configurazioni
con file nuovi e/o modificati.
2.9 L’ambiente integrato COOP/Orm
2.9.1 Ambienti di sviluppo integrati
Un ambiente di sviluppo è un sistema dotato di tutti gli strumenti ritenuti
utili per lo sviluppo di un progetto. Nella prima fase dello sviluppo del
progetto vengono scelti, ed inseriti nell’ambiente di sviluppo, tutti gli strumenti
che si prevedono di usare. La cosa importante è che tali strumenti non
complichino il lavoro, ma al contrario, lo semplifichino. Per questo occorre
che siano ben integrati gli uni con gli altri, cioè è necessario che:
• tutti gli strumenti abbiano la medesima interfaccia grafica;
• tutte le viste 8 si aggiornino automaticamente fra i vari strumenti all’interno
dell’ambiente.
8 Possibile rappresentazione per l’utente di una certa entità (come il codice sorgente
oppure lo stato di avanzamento della procedura di compilazione).
56

Versioning a supporto della collaborazione L’ambiente integrato COOP/Orm
Comunemente ci si riferisce agli ambienti di sviluppo integrati con l’acronimo
IDE (dall’inglese Integrated Development Environments, vedi [IDE05]).
Affinché tali caratteristiche siano soddisfatte occorre che i vari strumenti
siano in grado di comunicare fra sé. Tale comunicazione può avvenire
sostanzialmente in tre modi:
• realizzando un sistema totalmente integrato ed omogeneo, con una interfaccia
utente unica ed in grado di svolgere tutte le funzioni necessarie.
Un esempio di questo tipo è l’ambiente di sviluppo integrato Eclipse;
la potenza di questo software consiste nel disporre di un avanzato meccanismo
di plugin che permette a chiunque di aggiungere ed integrare
funzionalità al pacchetto base che nasce come piattaforma di sviluppo
per il linguaggio Java. Esistono plugin che aggiungono il supporto alla
maggior parte dei linguaggi di programmazione ed il tutto è disponibile
gratuitamente per la maggior parte di sistemi operativi (a riguardo
vedi [Fou05a]);
• ricorrendo ad una integrazione più “approssimativa” in cui ogni strumento
è indipendente dagli altri, ma con l’esistenza di meccanismi che
permettano l’interscambio di informazioni senza complicazioni per l’utente.
Un esempio da citare è il paradigma di lavoro tipico degli ambiente
Unix-like che prevede l’esistenza di tanti tool distinti per svolgere
i vari compiti, ma tutti in grado di cooperare senza grosse difficoltà in
quanto basati sugli stessi standard ben definiti;
• lasciando le cose al “caso” ed intervenendo manualmente, se necessario,
con operazioni di importa/esporta fra i vari applicativi. Questa operazione
potrebbe addirittura non essere possibile e in ogni caso è un
enorme collo di bottiglia nel processo di sviluppo.
2.9.2 Da Orm a COOP/Orm
COOP/Orm (descritto in [Ask02]) nasce con la finalità di aggiungere funzionalità
tipiche degli ambienti groupware ad Orm che è ambiente di sviluppo
integrato con le seguenti caratteristiche:
• è interattivo;
• è ottimizzato per linguaggi orientati agli oggetti;
57

Versioning a supporto della collaborazione L’ambiente integrato COOP/Orm
• è basato su compilazione, caricamento ed esecuzione incrementale;
• usa finestre gerarchiche per la gestione del codice sorgente;
• supporta il versioning e la gestione esplicita delle configurazioni del
progetto (anche se orientati allo sviluppo da parte di un singolo).
Giudicare la gestione delle versioni come un aspetto di primaria importanza
nello sviluppo di software è stato considerato, nella fase di progettazione
di COOP/Orm, un assioma. Per questo motivo è stato scelto di rendere
la gestione delle versioni ben radicata nel sistema e ben visibile all’utente.
Questa filosofia è in contrasto con quella seguita in altri sistemi nei quali
il versioning viene considerato come una funzionalità interna al sistema e
quanto più possibile da mascherare all’utente.
La missione di COOP/Orm è quella di aggiungere ad Orm:
• la possibilità di mettere gli utenti in grado di cooperare (fornendo il
massimo awareness di gruppo possibile, paragrafo 1.2 a pagina 1.2);
• un sistema di gestione delle versioni evoluto, granulare, flessibile e
adatto al lavoro di gruppo. L’approccio è estensionale (sotto paragrafo
1.2.4) in quanto basato sul modello UEVM (paragrafo 2.4).
Secondo i progettisti di COOP/Orm il loro sistema ha vantaggi e svantaggi
rispetto ad architetture con integrazione minore.
Vantaggi:
• la gestione dell’evoluzione dei documenti (grafo delle versioni) è stata
integrata nell’editor del sistema favorendo una visione globale più chiara
dell’avanzamento del progetto;
• la gestione delle versioni è stata ideata per ottimizzare le operazioni di
confronto fra le stesse;
• la finestra dell’editor si aggiorna automaticamente se altri utenti modificano
una parte del documento in essa presente migliorando l’awareness
dei componenti del gruppo.
58

Versioning a supporto della collaborazione Sistemi di versioning peer-to-peer
Svantaggi:
• gli utenti sono obbligati ad usare gli editor messi a disposizione dal
sistema;
• può essere complesso aggiungere nuovi tool all’ambiente di lavoro.
2.10 Sistemi di versioning peer-to-peer
BitKeeper. È un sistema per la gestione del codice sorgente che permette
agli sviluppatori di lavorare concorrentemente allo stesso progetto. Diversamente
da altri sistemi nati con finalità simili è scalabile (si basa sostanzialmente
su una architettura peer-to-peer e non client/server), agevola il lavoro
completamente distribuito, permette agli utenti di lavorare anche se disconnessi
dalla rete, si basa sul paradigma change set (sotto paragrafo 2.2.4) ed
è eccellente nella gestione delle operazioni di merge ([Bit05]).
Un repository in BitKeeper è un insieme di file versionati ed ogni repository
è una entità auto-consistente, nel senso che contiene tutto quello che serve
per lavorare. Ogni sviluppatore ha un proprio repository che viene creato
da zero oppure tramite copia: in questo caso si parla di clone. Il repository
clone che nasce a seguito di una operazione di copia è legato al repository di
origine tramite una relazione padre-figlio. Le modifiche vengono propagate
fra repository attraverso la condivisione su file system, oppure tramite Rsh,
Ssh, Smtp, Http oppure Bkd: il “BitKeeper network daemon”.
Il paradigma di interazione fra l’utente e il proprio repository è simile a
quello di altri sistemi di versioning: occorre effettuare checkout/checkin dei
file, eccetera. Resta inteso che questa fase risulta semplificata dal fatto che
l’accesso al repository è riservato ad un singolo utente. Per rendere le modifiche
di dominio pubblico e per integrare le modifiche di altri nel proprio
repository esistono delle primitive specifiche: push e pull. Queste operazioni
vengono effettuate sulla base di cambiamenti logici (change set). Le eventuali
semplificazioni riscontrate in fase di checkin vengono meno durante la condivisione
dei change set con gli altri sviluppatori e pertanto il sistema mette a
disposizione vari meccanismi per rilevare e risolvere conflitti.
A livello di astrazione degli host che ospitano BitKeeper, data la natura
del protocollo peer-to-peer, non c’è distinzione fra quelli che gestiscono
repository padre e quelli che gestiscono repository figlio. Tale differenza contraddistingue
certamente il comportamento del nodo e può essere vista come
59

Versioning a supporto della collaborazione Sistemi di versioning peer-to-peer
conseguenza del fatto che lo stato interno è diverso. Tanto è vero che in
BitKeeper le relazioni padre-figlio possono essere create (tramite l’operazione
di copia) ed alterate (tramite specifiche primitive) a piacimento. Nel caso
client/server la situazione è ben diversa in quanto gli host ospitano processi
diversi (client e server appunto) e quindi risultano ben distinguibili l’uno
dall’altro e certamente non interscambiabili.
Figli
Padre
Repository del
responsabile
della partizione
Figli
Figura 2.10: Topologie a stella ed albero.
Padre
Questo meccanismo permette di creare topologie di qualunque tipo anche
se una delle più utilizzate è quella a stella (a sinistra in figura 2.10) nella
quale si ha un unico repository padre (radice) con vari repository figli. Questa
topologia ricorda i sistemi centralizzati, ma, rispetto a questi ultimi, è
più generale e flessibile: qualora risultasse necessario è possibile apportare
modifiche di vario tipo in modo da adattarla alle nuove esigenze, senza difficoltà.
Questo approccio permette di far scalare la struttura al crescere della
complessità del progetto trasformandola, ad esempio, in un albero (a destra
in figura): il progetto ha un repository padre che viene diviso in sotto parti.
Ognuna di esse viene assegnata ad un responsabile, il cui repository diviene,
a sua volta, radice del sotto-albero di competenza. La procedura di sviluppo
delle sotto parti può continuare con la topologia a stella: gli sviluppatori,
che ovviamente operano nel loro repository, fanno capo al responsabile della
sotto parte di loro competenza.
60

Versioning a supporto della collaborazione Valutazioni comparative
Git. È il sistema di gestione delle versioni utilizzato correntemente per la
manutenzione del kernel Linux ed è stato introdotto specificatamente per
questo scopo [Whe05]. Il sistema di gestione utilizzato in precedenza era
BitKeeper ed è stato sostituito in quanto, la nuova licenza di rilascio applicata
recentemente, non si adatta alle esigenze della comunità di sviluppatori.
Svk. È un sistema distribuito che si appoggia a Subversion per la gestione
delle versioni [lK05]. Diversamente da quest’ultimo prevede che ogni sviluppatore
disponga di una copia personale (locale) del repository, chiamata
depot. L’interazione avviene fra la copia di lavoro locale e il depot, fra il depot
e un repository remoto. Questo passaggio intermedio permette di ricondurre
il paradigma di interazione a quello di BitKeeper guadagnando, rispetto
a Subversion, la capacità di operare con topologie più complesse rispetto a
quella a stella, tipica del paradigma client/server.
2.11 Valutazioni comparative
I software descritti in questo capitolo non sono, ovviamente, gli unici
presenti nel panorama attuale dei sistemi di versioning. Sono stati scelti in
quanto hanno permesso di introdurre e descrivere i vari approcci esistenti per
la gestione delle versioni e di ripercorrere la storia che ha portato alla loro
definizione.
RCS ha affrontato la risoluzione del problema del versioning considerandolo
un passo fondamentale. In seguito CVS ha agevolato il lavoro di gruppo
fornendo una semplice infrastruttura client/server per l’accesso da postazioni
remote e sostituendo l’approccio lock/unlock con il copy/merge. Subversion
cerca di superare alcuni limiti di CVS, ma senza stravolgerne la struttura.
In certi contesti il paradigma client/server risulta inadeguato e i sistemi di
nuova generazione di gestione delle versioni (BitKeeper, Git, Svk, etc.) si
muovono verso il paradigma peer-to-peer con il quale l’architettura a stella,
tipica del client/server, è solo una delle possibilità.
I sistemi appena menzionati basano il loro principio di funzionamento
sul versioning dei file senza comprenderne il significato. Questo, da un lato,
permette l’utilizzo su qualunque tipo di dato, dall’altro permette di asserire
che, in contesti specifici, se i tool fossero in grado di comprendere i dati
che stanno manipolando, potrebbe avere comportamenti più evoluti. Tale
61

Versioning a supporto della collaborazione Valutazioni comparative
ottimizzazione è realmente possibile dotando il sistema delle facoltà necessarie
a comprendere la struttura dei dati che sta trattando ad un livello di
astrazione diverso del file o directory su file system. Questo è ben messo in
evidenza dal modello UEVM. Inoltre, le problematiche tipiche del lavoro di
gruppo messe in relazione con i vantaggi percepiti dall’utente medio nell’uso
di sistemi integrati, stanno portando verso ambienti di lavoro complessi nei
quali il controllo delle versioni è solo una delle funzionalità e molto spesso è
ottimizzata per lo specifico campo applicativo (COOP/Orm).
La seguente lista (non esaustiva) cita alcuni dei prodotti non menzionati
in precedenza presenti nello scenario attuale dei sistemi di controllo delle
versioni:
• Aegis, [Mil05];
• Bazaar-NG, [Ltd05a];
• ClearCase, [RS05];
• Co-Op, [Sof05];
• Darcs, [Rou05];
• GNU Arch, [Gnu05];
• Monotone, [Mon05];
• OpenCM, [SVLF05];
• Perforce, [Inc05];
• PureCM, [Ltd05b];
• Superversion, [Rei05];
• Vesta, [Com05];
• Visual SourceSafe, [Mic05].
62

Parte II
Ambiente virtuale e modello
dell’informazione

Capitolo
3
Modello dell’ambiente virtuale
Nel mondo reale una qualsiasi istituzione è tradizionalmente organizzata
in modo gerarchico. Non è questo il luogo per illustrare ed analizzare
gli aspetti sociali, storici, economici e politici che hanno portato la società
moderna ad un simile ordinamento. Ciò che è rilevante è il dato di fatto:
la società è costituita da insiemi di organizzazioni o associazioni di persone,
strutturate piramidalmente, in cui agiscono individui con ruoli più o meno
predeterminati (morali o professionali).
Ogni individuo può essere inquadrato in vari contesti (ad esempio lavorativo,
familiare, politico, sportivo, etc.) nei quali svolge le proprie mansioni
o attitudini mettendosi in relazione con gli altri. A sua volta ogni contesto
è inquadrato in un ambiente più globale, che generalmente ne è autoritativo.
Non è poi una rarità che organizzazioni paritarie o indipendenti ne controllino
altre o si controllino a vicenda, stabilendo delle relazioni trasversali.
Nella progettazione di un ambiente collaborativo risulta naturale informatizzare
il sistema per simulare, nel modo più coerente possibile, queste
relazioni. Un ambiente virtuale consentirà di semplificare lo svolgimento delle
attività degli utenti, facilitare l’uso di strumenti e risorse a valore aggiunto.
Infine tanto maggiore risulta la corrispondenza fra ambiente virtuale e reale
quanto minore sarà la difficoltà degli utenti a comprendere ed utilizzare il
sistema.

Modello dell’ambiente virtuale Rappresentazione dell’ambiente
Proprio partendo dalla prospettiva dell’utente si cercherà di trasporre
in termini di ICT (Information Communication Technology) la percezione
del mondo circostante, con il vantaggio che la maggior parte delle attività
potranno essere automatizzate.
Nel presente capitolo da un lato si cercherà di identificare un insieme di
entità ed operazioni che simulano l’ambiente reale e dall’altro si introdurranno
delle nuove operazioni a valore aggiunto.
3.1 Rappresentazione dell’ambiente
Il modello di figura 3.1 riassume graficamente la proiezione del mondo
reale nel mondo virtuale, nel quale sono rappresentati gli attori e le risorse
del sistema, che interagiscono tra loro e con l’ambiente reale. Internamente
si individuano coloro che producono informazione, coloro che ne fruiscono e
coloro che ne gestiscono e stabiliscono le politiche di accesso.
• Producer: rappresenta i client o gli utenti che producono l’informazione.
• Consumer: rappresenta i client o gli utenti che interagiscono con l’ambiente
al fine di trovare ed ottenere le informazioni di interesse.
• Management: coordina consumatori, produttori di informazione e risorse
presenti.
Sebbene ciascun ruolo, Producer, Consumer e Management, possa essere
assegnato allo stesso individuo o sistema esterno, essi risultano singolarmente
indipendenti. Inoltre in base a come un utente o sistema si autentica
nell’ambiente alcune operazioni e comportamenti saranno permessi ed altri
negati.
3.1.1 Le entità
L’ambiente è costituito da mondi (World) organizzati gerarchicamente.
Ogni World può identificare un luogo o un Ente virtuale al quale corrisponde
un luogo o Ente reale (ad esempio un ufficio, un reparto, una stanza, etc.).
Ciascun World è indirettamente abitato dagli utenti. La proiezione dell’utente
nel World è indicata col nome Avatar: un’entità capace di esporre
un sottoinsieme delle proprietà e caratteristiche dell’utente. All’ingresso di
un utente nel luogo reale corrisponde l’ingresso dell’Avatar nel World.
65

Modello dell’ambiente virtuale Rappresentazione dell’ambiente
Virtual
Environment
Real Environment
Resource / Entities
Figura 3.1: Ruoli degli attori dell’ambiente virtuale.
Gli Avatar sono organizzati in gruppi (Group), comunità virtuali di individui,
accomunati da un certo insieme di caratteristiche o finalità lavorative.
All’interno di un World gli Avatar interagiscono attraverso la condivisione
delle risorse (Stuff) qui localizzate. Gli Stuff sono documenti elettronici,
capaci di incapsulare dati e di esporre una serie di servizi. In generale possono
essere sia entità statiche che dinamiche, dotate di un comportamento legato
non solo ai servizi, inerenti all’informazione che rappresentano, ma anche al
proprio ciclo di vita.
66

Modello dell’ambiente virtuale Rappresentazione dell’ambiente
Avatar
L’Avatar è l’entità logica che rappresenta l’utente nell’ambiente virtuale.
Ad ogni utente possono essere associati più Avatar ciascuno dei quali esprime
un profilo in un contesto. In sostanza un Avatar è un agente di presentazione
dell’utente, capace di effettuare o subire operazioni nel World per conto del
suo titolare. Il compito dell’Avatar è di seguire le attività collaborative, anche
nel caso in cui l’utente sia fisicamente assente dal sistema (off-line).
Tutte le varie prospettive e sfaccettature, costituite dall’insieme degli Avatar,
determinano l’utente nella sua globalità. Ogni Avatar esprime condizioni
sufficienti all’autenticazione in un particolare World o all’appartenenza ad un
Group. L’unione di tutti i profili, in linea di principio, permetterebbe di ricostruire
l’utente nella sua totalità. In questo modo si tiene in considerazione
sia la legislazione sulla privacy 1 sia l’eventuale volontà dell’utente a rendere
noti solo dei frammenti della sua identità.
La scelta di rappresentare l’utente con più Avatar consente di simulare ciò
che accade nel mondo reale, dove un individuo viene visto in modo diverso
da diversi gruppi di persone e dal sistema. Infatti ciò accade comunemente
quando lo stesso individuo fornisce parziali informazioni sulla propria identità
ed interagisce in modo diverso con gli altri in relazione al contesto. Ad
esempio il profilo esposto da una persona in ambito lavorativo solitamente
non è equivalente a quello in ambito familiare o comunque privato. L’utilizzo
di più identità non è una novità negli applicativi di rete, come chat e forum,
dove il nome reale viene quasi sempre sostituito con un nickname o un alias.
È opportuno osservare che la gestione contemporanea di più Avatar e
quindi di più operazioni sarà possibile solamente se l’utente potrà agire
contemporaneamente con Avatar diversi.
Un requisito la cui rilevanza varia in base al contesto, ma che in ogni
caso è importante soddisfare, è certificare l’associazione fra una persona e
relativo Avatar, dato che sarà proprio l’Avatar ad avviare, direttamente o
indirettamente, i procedimenti e quindi agire nell’ambiente virtuale per conto
del titolare.
1 Occorre garantire il rispetto dei principi di protezione dei dati personali. In Europa
la regolamentazione è prevista dalla Convenzione del Consiglio d’Europa n. 108/1981.
In particolare ogni stato membro dell’Unione adotta una propria legislazione, ad esempio
per l’Italia: legge n. 675 del 31/12/1996, per la Finlandia: legge n. 523 del
22/4/1999, per la Grecia: legge n. 2472 10/04/1997, per l’Inghilterra: “The Data
Protection Act” del 16/07/1998, per il Portogallo: legge n. 67 del 26/10/1998.
(http://www.privacy.it/linkpriv1.html)
67

Modello dell’ambiente virtuale Rappresentazione dell’ambiente
Group
I Group sono associazioni di utenti accomunati da identici obiettivi o
simili profili. Rappresentano una comunità collaborativa o uno status sociale
e permettono di agire sulle risorse condivise in modo unitario.
Un Avatar, a cui è concessa l’iscrizione ad un gruppo, acquisisce i diritti
e i doveri del gruppo. Attraverso la transitività dei permessi, gli Avatar
ereditano le caratteristiche comuni al gruppo.
I Group sono organizzati gerarchicamente ed ordinati secondo una relazione
di contenimento. È possibile rappresentare graficamente la struttura
con un albero, in cui i permessi associati ai vari nodi (Group) crescono al
crescere della profondità di penetrazione.
I permessi dei sottogruppi (gruppi figlio) sono almeno gli stessi di quelli
del gruppo che li contiene (gruppo padre). Un Avatar iscritto ad un gruppo
ha almeno tutti i permessi di quel gruppo. Ovviamente un Avatar iscritto
ad un gruppo figlio risulta iscritto anche al gruppo padre.
All’espulsione o alla cancellazione di un Avatar da un gruppo corrisponde
una diminuzione dei privilegi (permessi).
Visivamente l’iscrizione e la cancellazione di un Avatar da un gruppo
corrispondono a navigazioni indirette dell’albero: si può pensare a queste
due operazioni come, rispettivamente, ad azioni di discesa o di salita nella
gerarchia.
Ogni Group contiene almeno un Avatar e teoricamente ve ne possono
essere iscritti un numero indefinito. Potrebbero comunque essere previste
eventuali restrizioni, come ad esempio sul numero massimo dei suoi affiliati
o politiche spazio-temporali sull’ingresso e l’uscita, ad esempio basate sulla
residenza dichiarata o l’età dell’utente.
World
L’entità World è la rappresentazione virtuale di un luogo reale. Un World
può contenere altri World (sotto-mondi), in modo simile al caso dei Group, e
risorse (Stuff). Ciò permette di creare una gerarchia di contesti collaborativi
in cui gli Avatar si incontrano e partecipano in attività sincrone o asincrone,
inter-personali o private. Il World di più alto livello, che contiene tutti i
World, prende il nome di Universe.
Gli Avatar possono utilizzare questa struttura sia per rappresentare organizzazioni
reali, sia luoghi convenzionali di ritrovo, intesi come spazi di
68

Modello dell’ambiente virtuale Rappresentazione dell’ambiente
giunzione tra World, propriamente abitati. Utenti, appartenenti a World distinti,
potrebbero avere comuni finalità progettuali per le quali è indicata la
creazione di un nuovo spazio logico di incontro. L’organizzazione degli spazi
avviene per convenienza dell’utente o di gruppi di utenti.
Solo utenti con opportuni profili sono ammessi ad entrare nei World.
Inoltre ai World è possibile associare condizioni intrinseche e strutturali, come
ad esempio orari di accesso e numero massimo di utenti contemporaneamente
presenti.
Stuff
Con Stuff sono indicati i processi nell’ambiente collaborativo. In generale
sono Stuff gli oggetti dell’ambiente reale come ad esempio dispositivi, sensori,
libri, documenti o porzioni di essi.
Uno Stuff espone un’insieme di operazioni ed ha un comportamento che
è definito da eventi esterni ed interni e dallo stato assunto.
La raccolta, l’elaborazione e la presentazione delle informazioni sono i
principali compiti di alto livello che uno Stuff deve assolvere. Gli Stuff non
solo sono oggetto di un insieme di azioni, ma sono anche soggetto di azioni
verso l’Avatar. Internamente all’ambiente virtuale hanno l’onere di avviare
in modo autonomo l’interazione con gli Avatar, senza che da parte dell’utente
vi sia stata una predeterminata soggettiva intenzione.
Le caratteristiche dei documenti dipendono anche dal loro contenuto:
pensiamo ad esempio ad un libro di narrativa che risulta non modificabile,
ma leggibile un numero indefinito di volte, oppure ad un documento di
identità che dopo essere creato, può essere modificato solo attraverso una
procedura di rinnovo, oppure ancora ad un insieme di appunti, sul quale non
c’è limite in scritture e letture.
Le informazioni nel documento trattate dall’Avatar sono filtrate dal documento
stesso: un’interfaccia espone le funzionalità che l’entità interna provvede
ad eseguire. In un’ottica Object Oriented lo Stuff è assimilabile ad un
oggetto.
Lo Stuff è per definizione un’entità creata dalla collaborazione di Avatar,
soggetta ad operazioni da parte di coloro che ne detengono i diritti ed è il
risultato dell’aggregazione di informazioni correlate, ma indipendenti.
69

Modello dell’ambiente virtuale Il modello delle interazioni
3.2 Il modello delle interazioni
All’interno dell’ambiente virtuale l’interazione tra Avatar viene filtrata
dagli Stuff. Tali risorse costituiscono i catalizzatori delle attività collaborative,
in quanto oggetto e soggetto di elaborazione. Mentre World e Group
assolvono i compiti di organizzare lo spazio, le risorse e gli utenti, gli Stuff
rappresentano il mezzo attraverso cui veicolare e controllare l’informazione.
Comunque i ragionamenti che seguono sono facilmente estendibili anche alle
entità World, Group ed Avatar.
In figura 3.2 è indicato il modello delle interazioni tra Avatar. Si distinguono
quattro tipologie di interazione:
• uno a uno: l’informazione è generata da un Avatar che lavora autonomamente
ed è indirizzata o destinata ad un altro Avatar;
• uno a molti: l’informazione è generata da un Avatar che lavora autonomamente
ed è indirizzata o destinata ad un Group, a cui può
eventualmente appartenere;
• molti a uno: l’informazione è generata da un Group in cui gli Avatar
lavorano in collaborazione ed è destinata ad un certo Avatar;
• molti a molti: l’informazione è generata da un Group in cui i vari
Avatar lavorano in collaborazione ed è destinata ad un altro Group,
che eventualmente può contenere il primo o esserne un sottoinsieme.
L’attività di un Avatar è costituita da una sequenza di operazioni finalizzate
a coinvolgere un solo utente o un intero gruppo. Il compito di identificare
i destinatari, e quindi avviare la diffusione delle informazioni, non è totalmente
affidato al produttore. Anche lo Stuff può avere un ruolo attivo. È
bene ricordare che Avatar e Stuff sono entità dello stesso livello.
Leggendo singolarmente i quattro casi di figura 3.2, da destra verso sinistra,
si identificano due fasi: nella prima fase la risorsa subisce l’iniziativa
dell’Avatar (o del Group) e nella seconda è prevista la consegna dei risultati
elaborati ai destinatari.
È facile osservare che esiste un disaccoppiamento degli Avatar per mezzo
degli Stuff. La fase di produzione è quella più delicata in quanto coinvolge,
a basso livello, operazioni di scrittura, in generale concorrenti, perciò è
auspicabile che tra i Producer Avatar e gli Stuff si realizzi un forte accoppiamento
e sincronismo. Ciò non è necessario nella fase di consumo in quanto
70

Modello dell’ambiente virtuale Il modello delle interazioni
Virtual Environment
Consumer
Avatar
Target
Group
Consumer
Avatar
Target
Group
unicast
multicast
unicast
multicast
World
World
World
World
Stuff
Stuff
Stuff
Stuff
operation
operation
operation
operation
Figura 3.2: Il modello di interazione.
Producer
Avatar
Producer
Avatar
Producer
Group
Producer
Group
71

Modello dell’ambiente virtuale Il modello delle interazioni
coinvolge le sole operazioni di lettura (non distruttive). Il vantaggio consiste
da una parte nell’aver separato le fasi critiche da quelle non critiche e dall’altra
nel consentire un’interazione asincrona tra produttore e consumatore
nelle attività collaborative. L’awareness è comunque ottenibile introducendo
un sistema di notifica dell’informazione, il quale può essere utilizzato per recuperare,
in certa misura, il sincronismo (a meno dei tempi di latenza, che
comunque esistono in un sistema distribuito). La notifica può essere comunicata
prontamente all’Avatar oppure avvenire al primo accesso alla risorsa.
L’importante è che la consegna sia sempre e comunque garantita.
Un’ulteriore osservazione riguarda l’impossibilità di stabilire a priori il
periodo e la scala dei tempi con cui il produttore accede alla risorsa. L’architettura
deve consentire sia attività periodiche che aperiodiche, sia dal lato
consumatore che produttore.
3.2.1 Prima fase dell’interazione
In primo luogo le entità devono essere indirizzabili: se non avessero un
nome non sarebbero identificabili e ricercabili. Una volta che il Producer
Avatar ha indirizzato la risorsa può accedervi, sempre che ne abbia diritto,
con una politica tra quelle consentite. L’authoring, soprattutto se concorrente,
deve essere regolato e controllato con opportuni meccanismi, tali che
le operazioni invocate non si sovrappongano indisciplinatamente, portando
l’informazione in uno stato inconsistente.
Per questa fase si individua la necessità di ricorrere ai seguenti sistemi di:
• rappresentazione e gestione dell’informazione, al fine di minimizzare le
attività manuali (workflow e comportamento);
• nomi, al fine di indirizzare concettualmente le entità;
• regolazione e controllo dell’accesso concorrente (lock, versioning, atomicità
delle operazioni).
3.2.2 Seconda fase dell’interazione
I Group giocano un ruolo fondamentale: consentono di individuare, nella
totalità degli utenti, singoli individui o gruppi secondo vari criteri. È possibile
esprimere l’interesse all’informazione con l’operazione di sottoscrizione,
oppure possono essere utilizzate delle espressioni logiche collegate alla risorsa.
72

Modello dell’ambiente virtuale Il delivery dell’informazione
Si può pensare di individuare i gruppi just-in-time interpretando delle proposizioni
e applicando dei filtri sui contenuti dei profili oppure si può avere
un elenco di destinatari (Group) già pronto.
L’interazione Stuff−→Avatar è da 1 a N (unicast o multicast). L’identità
dei destinatari è conoscibile con la prospettiva dell’Avatar produttore o con
quella dello Stuff. Nel primo caso è lo stesso Avatar ad indicare chi usufruirà
delle nuove informazioni, mentre nel secondo si assume che il Group, a cui
appartiene la risorsa, sia implicitamente anche il Group destinatario.
Ai sistemi precedentemente elencati si deve aggiungere un meccanismo per
la consegna dell’informazione. La modalità con cui avviene la notifica può
essere utilizzata per stabilire la qualità del servizio (QoS) complessivamente
erogato dallo Stuff. Ad esempio un indice è definibile come rapporto tra
informazioni consegnate su esplicita richiesta dell’utente rispetto a quelle
notificate preventivamente. Questo permetterebbe di valutare la bontà del
servizio e sarebbe applicabile in contesti di front-office e back-office.
3.3 Il delivery dell’informazione
Le modifiche alle entità dell’ambiente virtuale possono essere estremamente
diverse sia per effetto della loro tipologia che delle operazioni invocate.
Ogni modifica deve essere resa nota almeno all’Avatar e al Group a cui appartiene,
altrimenti potrebbe apparire inaspettata, degradando l’awareness
del gruppo e quindi la collaborazione. Il messaggio per la consegna dell’informazione
può essere definito in due modi: inviando al destinatario l’intera risorsa
modificata (email-based), oppure inviando solo la notifica dell’avvenuto
cambiamento, lasciando all’utente l’onere dell’accesso (web-based).
La definizione dell’ambiente virtuale, abbinata ad un authoring fortemente
popolato ed eterogeneo, induce a scartare il primo approccio per i seguenti
principali motivi:
• ha senso solo per entità di tipo Stuff;
• la quantità di informazione inviata potrebbe non essere proporzionata
all’entità delle modifiche;
• l’imperizia o le dimenticanze dell’utente causano effetti collaterali in
cascata.
73

Modello dell’ambiente virtuale Il delivery dell’informazione
L’ultimo punto richiede maggiore dettaglio. Si ricorda che anche agli
Avatar è consentito indicare il destinatario dell’informazione e che agisce per
conto del suo utente. L’utente potrebbe inavvertitamente ripetere l’invio di
messaggi identici, inviare messaggi in ritardo rispetto alla scala dei tempi
lavorativi, i messaggi spediti potrebbero contenere l’allegato non corretto o
non contenerlo affatto. Tutto ciò degrada l’awareness del gruppo e quindi la
collaborazione. Nel caso migliore fa crescere il numero di repliche o di copie
dello Stuff che non solo penalizzano l’eventuale controllo delle versioni (aumentano
le diramazioni), ma abbassano globalmente il livello di automazione
dell’informazione.
Si parta dal principio che tutte le entità esistono nell’ambiente virtuale
e che sono qui identificabili, ricercabili ed ottenibili. Supponendo che un
utente User B abbia identificato ed ottenuto l’accesso in scrittura, tramite il
rispettivo Avatar, ad uno Stuff C e che l’evento debba essere notificato ad un
utente User A con una certa priorità (figura 3.3).
Discesa lato User B. La modifica allo Stuff avviene con un forte accoppiamento,
in quanto l’attività, dall’inizio alla fine, avviene all’interno di una sessione.
L’Avatar B prepara l’operazione, i parametri ed i metadati (ad esempio
Avatar destinatario dell’evento, priorità dell’evento, nome dello Stuff, ricevuta
di ritorno etc.). Il tutto viene passato ad un’entità che opera ad un livello
di astrazione più basso e che si preoccupa di imbustarlo in un messaggio
(marshalling) indirizzato allo Stuff. Quindi viene consegnato al sottosistema
che si occupa del trasporto dell’informazione che provvede a recapitarlo al
corrispettivo livello di trasporto del lato Stuff.
Salita lato Stuff C. Il livello trasporto della destinazione estrae il corpo
del messaggio e lo cede al livello soprastante. Quest’ultimo in particolare
si occupa di individuare l’operazione da applicare allo Stuff (unmarshalling).
Sullo Stuff C avvengono le modifiche e l’interpretazione coerente dei metadati.
Discesa lato Stuff C. Lo Stuff registra le modifiche e deve informare
l’Avatar A dell’evento, perciò prepara l’informativa sfruttando i metadati e
i dati relativi al tipo di operazione. L’informativa è passata al sottostante
servizio di notifica (Notification Service X) che lo imbusta in un messaggio,
indicando nell’intestazione chi e come dovrà riceverlo. Grazie al livello tra-
74

Modello dell’ambiente virtuale Il delivery dell’informazione
push
World
event
User A User B
Avatar A
Notification
Service X
Transport
pull
Notify
changes
Notification
Service X
Transport
Stuff C
unmarshalling
Transport
Figura 3.3: La notifica delle modifiche.
modify
operation
+
metadata
Avatar B
marshalling
Transport
sporto, arriva al lato dell’User B. La notifica verso il lato dell’User A avviene
con un debole grado di accoppiamento.
Salita lato User A. Il Notification Service Y riceve il messaggio dal sottostante
livello trasporto. A questo punto si possono verificare due modalità
di interazione, mutuamente esclusive, dipendenti dalla priorità in origine
assegnata dall’User A o dallo Stuff C:
• il messaggio rimane memorizzato nel Notification Service Y in attesa di
75

Modello dell’ambiente virtuale Il delivery dell’informazione
essere prelevato dall’Avatar A su richiesta dell’User A (pull);
• l’informativa viene immediatamente passata all’Avatar A e quindi fornita
all’User A (push).
Se lo Stuff C avesse richiesto la ricevuta di ritorno all’Avatar A, quest’ultimo
sarebbe stato invitato o obbligato a generare un messaggio di risposta. Il
percorso è esattamente inverso al precedente fino allo Stuff, solo che questo
verrà sollecitato in modalità push. Lo Stuff registra l’avvenuta consegna e, se
l’iniziativa è partita dall’Avatar B, provvede a notificarla con un meccanismo
del tutto analogo a quello precedentemente illustrato.
Il meccanismo è facilmente generalizzabile e scalabile nel caso in cui il
destinatario sia un Group: a fronte di una modifica basta che lo Stuff generi
un’informativa destinata a tutti i membri del gruppo. Il Notification Service
provvede ad inviare tanti messaggi quanti sono i destinatari.
76

Capitolo
4
Modello dell’informazione
versionata D3IM
Lo scopo primario di un modello dell’informazione (Information model,
IM ) è delineare le entità informative a livello concettuale, indipendentemente
da specifiche implementazioni o dai protocolli utilizzati per trasportare i
dati. Un IM deve celare tutti i dettagli implementativi e di comunicazione
al fine di rendere la progettazione la più chiara possibile. L’altro importante
compito dell’IM è modellare le relazioni tra le entità attraverso un linguaggio
naturale o un linguaggio formale oppure con un linguaggio strutturato semi
formale [Pra03].
Viceversa i modelli per i dati (Data Model, DM ) sono definiti ad un livello
più concreto ed includono molti dettagli con specifici costrutti. La principale
conseguenza è che lo stesso IM può dare vita a più DM. In pratica però non
è sempre possibile distinguere univocamente un DM dal suo IM. Esiste una
“zona grigia”, dove IM e DM si sovrappongono parzialmente. In molti casi è
veramente difficile stabilire se le astrazioni appartengono all’uno o all’altro.
In questo capitolo viene definito un Information Model. L’intenzione è
quella di renderlo quanto più generico possibile in modo da permetterne l’utilizzo
in vari contesti non necessariamente noti a priori. Per rendere più
concreta tale definizione è utile ricorrere al concetto di documento che, rima-

Modello dell’informazione versionata D3IM
nendo in un contesto molto generale, è possibile definire come un’entità che
contiene una serie di informazioni.
L’elaborabilità di un documento assume particolare rilievo quando esso
viene rappresentato all’interno di un calcolatore ed utilizzato come entità da
trasmettere. Parafrasando Rain, McCue, Slein e Buckland [Inn04], una definizione
estesa e utile per gli argomenti trattati, è la seguente: un documento è
la testimonianza di una evidenza fisica o intellettuale, memorizzata e strutturata
in una qualsiasi forma materiale, capace di essere compresa dall’uomo,
trattabile dalla macchina e comunicabile.
Molto spesso quando si considerano più informazioni distinte come un’unica
entità (raggruppate all’interno di un documento) il contenuto informativo
della somma è maggiore della somma delle singole informazioni. Si evidenzia
come l’informazione aggiuntiva sia data da correlazioni presenti fra le
varie informazioni e permetta di caratterizzare il documento come un’entità
strutturata.
Nel caso in cui questo aspetto sia trascurabile si parla di informazione
non strutturata che comunque può essere vista come un caso particolare di
quella strutturata.
Data l’importanza della tracciabilità delle modifiche nei contesti nei quali
è previsto che il modello proposto venga applicato, la gestione dell’evoluzione
temporale delle informazioni (versioning) è integrata nel modello in modo
nativo.
Per rispondere a queste esigenze il modello di documento in esame, D3IM
(Distributed Delocalized Document Information Model), è stato progettato in
modo da potersi basare su UEVM, descritto nel paragrafo 2.4 (a pagina 33).
Il documento deve essere dotato delle seguenti caratteristiche:
• deve avere una struttura a DAG nella quale siano ben distinguibili e
definiti come entità individuali i nodi che la costituiscono;
• devono esistere le seguenti tipologie di relazione fra nodi: link di riferimento
e link di composizione (terminologia ereditata dal modello
UEVM 1 .
1 È stato scelto, per convenzione, di utilizzare il termine aggregazione per intendere una
qualunque relazione fra nodi (link di composizione o di riferimento). In questo modo il
concetto di composizione è un caso particolare di quello di aggregazione, similmente alla
terminologia utilizzata in UML [RJB99].
78

Modello dell’informazione versionata D3IM Principi di strutturazione
Le caratteristiche menzionate riguardano soltanto gli aspetti strutturali e
legati al versioning delle informazioni, mentre quelle che seguono sono state
aggiunte con la finalità di caratterizzare il documento anche sotto i seguenti
punti di vista che riguardano:
• la definizione a più alto livello del concetto di informazione;
• l’introduzione del concetto di responsabilità associato all’informazione.
4.1 Principi di strutturazione
All’interno dei documenti con i quali si interagisce e si tratta quotidianamente
possono essere individuate alcune categorie di informazioni che possono
essere evidenziate analizzando il documento. Tali categorie risultano le
seguenti:
• contenuti: elementi esplicitamente fruibili dall’uomo e che sono direttamente
individuabili all’interno del documento. Rientrano in questa
categoria i testi, le immagini, le date, i nomi, i contenuti multimediali,
eccetera;
• relazioni: legami fra contenuti che possono essere di tipo esplicito o
implicito. Un esempio di legame esplicito può essere il riferimento ad
una pagina o paragrafo di un libro, ad un articolo presente in una legge,
eccetera. Dualmente un legame implicito può essere quello esistente fra
il titolo di un capitolo di un libro e il contenuto del capitolo stesso;
• informazioni aggiuntive: ulteriori informazioni associate al documento
e/o che possono essere date per scontate. Ad esempio l’autore di un
brano musicale oppure il fatto che i contenuti presenti nella prima pagina
di un quotidiano rappresentano un sunto delle notizie più importanti
del giornale;
• presentazione: informazioni necessarie per mostrare correttamente il
documento all’utente. Rientra a pieno titolo in questa categoria l’aspetto
grafico, ovvero la scelta dei caratteri, dei colori, dell’impaginazione,
eccetera. Questa categoria di informazioni fornisce un valore aggiunto
che in particolari casi è determinante per permettere la fruibilità delle
informazioni contenute nel documento. A tal riguardo si pensi alle linee
guida dettate nel contesto del web accessibile [TS06].
79

Modello dell’informazione versionata D3IM Principi di strutturazione
Queste categorie di informazioni sono state introdotte parlando di documento
in senso astratto e/o nel senso convenzionale del termine. Nel momento
in cui si intende codificare un documento per renderlo trattabile dalle
macchine occorre formalizzare al meglio questi concetti al fine di poterli
gestire efficacemente ed efficientemente da un punto di vista informatico.
A tale scopo si può ricorrere ad opportuni linguaggi di marcatura che
permettono di contrassegnare e quindi valorizzare i vari elementi contenuti
nel documento. In questo modo si riescono a codificare tutte le categorie
di informazioni e in particolare a rappresentare, esplicitamente o implicitamente,
le relazioni. Un esempio di relazione rappresentata esplicitamente è
l’insieme dei link ipertestuali presenti nelle pagine web: il link è presente ed
individuabile nel documento. Viceversa la modalità implicita si presenta in
uno degli esempi menzionati precedentemente ovvero qualora si vada a contrassegnare
il titolo di un capitolo come tale, in modo da evidenziarlo rispetto
al testo presente nello stesso: non esiste una relazione fra titolo e contenuto
del capitolo esplicitamente individuabile all’interno del documento, ma tale
marcatura permette di separare le due entità e considerarle, se necessario,
come correlate.
Da un punto di vista informatico i documenti dotati di queste caratteristiche
e codificati opportunamente vengono chiamati documenti strutturati.
I vantaggi riscontrati trattando documenti strutturati sono molteplici in
quanto gli aspetti strutturali, oltre a fornire un contenuto informativo addizionale
rispetto al caso non strutturato, permettono di garantire anche un
maggior controllo dei contenuti.
Inoltre tramite il concetto di riferimento ad altre informazioni è possibile
realizzare vari documenti che, contenendo riferimenti alle medesime
informazioni, di fatto le condividono.
Le macchine, in questo modo, diventano sistemi in grado di interpretare
e comprendere 2 il contenuto informativo dei documenti e ciò permette di
sfruttarne agevolmente le potenzialità in termini di velocità elaborativa, di
memorizzazione e comunicazione per supportare efficientemente l’uomo nella
loro trattazione.
Quindi il lavoro dell’uomo risulta agevolato in quanto può essere velocizzato
e facilitato nell’immissione, nella ricerca, nella consultazione delle
informazioni.
2 Si intende che, sulla base dei documenti codificati opportunamente, risulta possibile
scrivere algoritmi in grado di elaborare le informazioni in modo efficiente.
80

Modello dell’informazione versionata D3IM I nodi informativi del documento
4.1.1 Il concetto di responsabilità
Un aspetto estremamente importante, in modo particolare se si trattano
informazioni sensibili, è quello relativo al concetto di responsabilità sull’informazione.
Il responsabile è colui il quale ha la consapevolezza di dover
rispondere degli effetti che possono scaturire a seguito della divulgazione
dell’informazione. Il responsabile può essere una persona fisica oppure
giuridica.
Prendendo ad esempio un giornale, l’autore di un articolo è responsabile di
ciò che vi ha scritto e il direttore è anch’esso responsabile, in modo indiretto,
in quanto ne autorizza la pubblicazione.
Si osservi che a questo riguardo esistono normative, sia a livello italiano
(legge 675/1996 [Ita96], decreto legislativo n.196 del 6 Giugno 2003 [Ita03],
etc.) che internazionale, che regolamentano le modalità attraverso le quali
devono essere trattati i dati sensibili. In questo contesto la legge prevede
in modo formale l’individuazione di uno o più persone fisiche o giuridiche
che hanno la responsabilità civile e penale del trattamento dei dati sensibili
dell’interessato 3 secondo i termini di legge.
4.2 I nodi informativi del documento
Il documento D3IM, essendo un’entità strutturata, è costituito da informazioni
che ne rappresentano il contenuto (i veri e propri dati) e da informazioni
che ne rappresentano la struttura (le relazioni fra i dati). Nel modello
introdotto le informazioni che rappresentano il contenuto sono dette informazioni
atomiche mentre quelle che rappresentano gli aspetti strutturali sono
dette informazioni primitive.
L’informazione atomica è una coppia“”: essendo il“valore”
di qualunque natura e potendo associare più informazioni atomiche ad un
documento è possibile osservare che i documenti D3IM possono contenere un
qualunque insieme di informazioni eterogenee.
L’informazione primitiva modella gli aspetti strutturali: introduce delle
relazioni di tipo “genitore-figli” in cui essa è genitore e i figli sono informazioni
atomiche o primitive. L’unico vincolo esistente è che non devono nascere
cicli nella struttura ovvero non deve esistere alcun cammino (sequenza di no-
3 La legge 675/1996 [Ita96] definisce l’interessato come la persona fisica, la persona
giuridica, l’ente o l’associazione cui si riferiscono i dati personali.
81

Modello dell’informazione versionata D3IM I nodi informativi del documento
di ottenuta seguendo le relazioni “genitore-figlio”) che partendo da un nodo
permetta di ritornare al nodo stesso. Si noti come questo fatto derivi implicitamente
dall’aver definito la struttura tramite relazioni di parentela fra nodi:
dati due nodi qualunque deve essere sempre possibile distinguere l’antenato
dal successore, operazione non effettuabile in caso di cicli.
Come già anticipato il documento definito in questi termini assume una
struttura a DAG (grafo aciclico ed orientato) visibile in figura 4.1.a.
Aver modellato il documento come DAG non preclude la possibilità di
presentarlo all’utente come albero 4 , figura 4.1.b. Questa rappresentazione
può essere ottenuta applicando il seguente algoritmo:
• si parte dal nodo di interesse nel DAG (A) e si inserisce nella radice
dell’albero;
• ricorsivamente, per ogni nodo dell’albero, si inseriscono come figli i
corrispondenti figli del nodo nel DAG.
Si osservi che, in questo modo, nodi con n genitori nel DAG figurano almeno
n volte nell’albero associato (radice esclusa che è unica per definizione).
L’unico vincolo che occorre considerare nel presentare il documento all’utente
in questa forma, è che nodi del DAG che compaiono più di una volta (D, 4 e
5) devono essere contrassegnati e mantenuti identici durante tutto il ciclo di
vita del documento, pena la perdita della sua validità.
La struttura ad albero (più in generale a foresta 5 ) rientra a pieno titolo fra
quelle gestibili con DOM (Document Object Model): le operazioni di accesso
e di manipolazione di documenti D3IM possono essere effettuate tramite tale
API (per ulteriori dettagli si faccia riferimento a [ABC + 04]).
4.2.1 Identificazione dei nodi e relativo accesso
Nel modello D3IM l’identificazione dei nodi è un’operazione che deve
essere mantenuta indipendente dall’accesso fisico.
Questo è conseguenza della percezione che ha l’uomo di “documento”:
ad esempio con “categoria della patente di guida di Mario Rossi” si intende
4 Si definisce albero un grafo aciclico non orientato e connesso. In realtà la struttura in
esame è un polytree (versione orientata di albero) che, fissato un albero, nasce nel momento
in cui viene scelto uno nodo come radice. L’abuso di nomenclatura è stato effettuato in
quanto il termine “albero” è di più immediata comprensione e nella trattazione corrente
non c’è rischio di ambiguità.
5 Si definisce foresta un grafo aciclico non orientato.
82

Modello dell’informazione versionata D3IM I nodi informativi del documento
Documento
D3IM
B
Informazione astratta
associata a B
a
A
1
4 5
C
2 3
D
Associata
a D
Informazione astratta
associata ad A
Informazione
Primitiva
Informazione
Atomica
Associata
a C
Legenda
Albero
associato
B
b
A
1
Aggregazione
Incapsulamento
C
2 3
D D
4 5
4 5
Figura 4.1: Documento D3IM: DAG ed albero associato.
un’informazione ben precisa ed indipendente dal luogo e dal formato in cui
viene conservata. In pratica la categoria è la stessa informazione sia che
questa venga memorizzata negli archivi elettronici della Motorizzazione Civile
che stampata sul documento in formato cartaceo in possesso del titolare della
patente.
È utile osservare che nel web questa proprietà non è verificata: gli URL 6
servono sia per identificare la risorsa che il luogo in cui questa viene memorizzata
ovvero per accedervi.
L’esempio relativo alla patente di guida evidenzia come l’identificazione
delle risorse sia un’operazione concettualmente diversa dall’accesso e pertanto,
in generale, è opportuno che le due operazioni siano distinte. In tal caso,
una volta effettuata l’identificazione in una prima fase, è possibile procedere,
6 Uniform Resource Locator [BLMM94], sono gli indirizzi utilizzati nel web per identificare
ed accedere alle risorse. Sono un caso particolare di URI (Uniform Resource
Identifiers) [BLFIM98].
83

Modello dell’informazione versionata D3IM I nodi informativi del documento
in una fase successiva, con l’accesso. Se, come nel web, le due operazioni
si sovrappongono ci si trova di fronte ad un caso particolare del precedente,
conseguentemente la scalabilità complessiva risulta minore o, al limite,
uguale.
Queste ultime considerazioni hanno portato alla definizione degli URN
(Uniform Resource Name) [SM94, Moa97, DvGIF99, Dan97]. Un URN è
anche un URI, ma differisce da un URL per il fatto che identifica una risorsa
web indipendentemente dalla sua locazione fisica inoltre non contiene informazioni
variabili nel tempo. Un buon esempio di URN è il codice ISBN di
un libro [LPD98]: ISBN identifica un libro, ma nessuna delle sue copie.
In D3IM si definiscono Persistent Resource Identifier (PRI ) gli URN che
identificano i nodi del documento in modo univoco, questo nome mette in
evidenza la principale proprietà che caratterizza questo tipo di identificatore:
la persistenza. Ulteriori dettagli relativi alla definizione ed alla gestione dei
PRI verranno riportati nel capitolo 8.
Per accedere alla risorsa identificata dal PRI, c’è bisogno di risolverla in un
nome che ne consenta l’accesso, ovvero un URL. L’uso di PRI per identificare
le risorse e di URL per accedervi consente di riferire indirettamente le molte
repliche in differenti locazioni come mostrato in figura 4.2.b. Questa soluzione
consente di mascherare la ridondanza. Inoltre, data la stabilità di un PRI nel
riferirsi alla risorsa, è possibile muovere la risorsa da una locazione all’altra
senza che tali cambiamenti si ripercuotano sul PRI. Un PRI consente a
risorse mobili di essere indirettamente riferite attraverso un insieme di URL
che variano nel tempo.
Poiché i PRI sono ad uso e consumo della macchina, non sono necessarie
restrizioni per renderli facilmente utilizzabili e trascrivibili dall’uomo,
anche se ciò è comunque auspicabile. Purtroppo gli utenti hanno bisogno
di assegnare nomi facilmente intellegibili e condivisibili con altri per indicare
concetti e contenuti. Per questo fine sono possibili due strade di seguito
indicate.
La prima è usare un directory service, come LDAP [HM02], il quale permette
agli utenti di cercare la risorsa con lo stesso principio delle “pagine
gialle”, basato sulla ricerca del valore degli attributi assegnati ad essa. Il
principale svantaggio del directory service è la limitata scalabilità, su larga
scala, non sono ancora stati sviluppati. Attualmente la migliore soluzione
è costituita da directory service federati, che richiedono middleware e che
forniscono un unico punto di accesso.
84

Modello dell’informazione versionata D3IM I nodi informativi del documento
(a)
(b)
(c)
URL
Replica
URL
Replica
URL
Replica
URL
Replica
URN
URL
Replica
HFN HFN
URN
URL
Replica
URL
Replica
URL
Replica
URL
Replica
Figura 4.2: Nomi di risorse replicate.
La seconda consiste nell’utilizzare un sistema di nomi gerarchico comparabile
al servizio delle “pagine bianche” (elenco telefonico). Il Domain Name
System (DNS) [KR03] è un esempio di questo tipo. Sebbene non siano disponibili
gli attributi è provata la scalabilità su larga scala con milioni di utenti.
Da questa prospettiva risulta più attraente rispetto al directory service.
Per riempire il divario tra le proprietà del PRI e le necessità umane è op-
85

Modello dell’informazione versionata D3IM I nodi informativi del documento
portuno introdurre un nuovo tipo di URI come suggerito in [Sol98] e [CM03].
È definito Human Friendly Name (HFN ) un nome di alto livello progettato
a misura d’uomo [SM94]. A differenza degli URN gli HFN permettono l’uso
esplicito di nomi descrittivi. Un HFN ha bisogno di essere risolto in un URL
quando l’utente vuole accedere alla risorsa. Un modo per realizzare questa
traduzione è di collegare un HFN ad un PRI, dopodiché collegare il PRI all’URL
opportuno. Il procedimento è composto da due fasi: nella prima HFN
viene risolto in PRI e nella seconda il PRI in URL, come schematizzato in
figura 4.2.c.
Esistono molti vantaggi con quest’ultimo approccio. In primo luogo gli
utenti possono assegnare in libertà nomi di convenienza alle risorse. Se una
risorsa è replicata o spostata in un’altra locazione, ciò non ha effetti sul
nome HFN. Analogamente, se un utente decide di cambiare l’HFN non si
avranno effetti sulla posizione delle repliche. Inoltre un utente può scegliere
di usare nomi diversi per indicare la stessa risorsa, allo stesso modo con cui
vengono usati gli alias negli indirizzi di posta elettronica o nei link simbolici
del file system. Per evidenziare il fatto che gli HFN assegnano un nome logico
alla risorsa, nel modello D3IM sono stati definiti Logical Resource Identifier
(LRI ). Come per i PRI ulteriori dettagli su HFN e, più nello specifico sugli
LRI, saranno riportati nel capitolo 8.
4.2.2 Informazioni atomiche
Come anticipato l’informazione atomica è una coppia “”.
I valori che vengono memorizzati sono soggetti a verifica sintattica e di
ammissibilità.
Ad esempio l’informazione atomica “” è accurata sintatticamente,
in quanto il valore numerico appartiene all’elenco dei CAP stabiliti
dalle Poste Italiane. Invece il valore “FI-50100” è sintatticamente scorretto
oppure “01234” è sintatticamente corretto, ma inammissibile. Indubbiamente
per il generico utente, che inserisce il dato, la parte nome della coppia “”
ha un certo peso semantico. Non è però conveniente affidare tali
controlli unicamente alle capacità dell’utente in quanto (tutti quelli sintattici
e buona parte di quelli semantici) possono essere automatizzati e affrontati
da elaboratori elettronici con notevoli vantaggi sia in termini temporali che
di precisione.
Visto che il modello non è una base di dati e non è dotato di algebra rela-
86

Modello dell’informazione versionata D3IM I nodi informativi del documento
zionale sembrerebbe impossibile stabilire se il requisito di accuratezza possa
essere sempre soddisfatto. La risposta al problema consiste nell’ipotizzare che
tutte le informazioni atomiche e primitive siano create e messe a disposizione
da un’entità responsabile che ne garantisce l’accuratezza.
Per quanto riguarda le informazioni atomiche questo è ottenibile, senza
perdere in generalità, tramite incapsulamento entro informazioni primitive.
In altre parole ogni informazione atomica è associata ad una e una sola informazione
primitiva la quale permette di proiettare la coppia “”
nello spazio dei documenti D3IM. Questo è conseguenza dal fatto che ogni
istanza di una qualsiasi coppia “” non è un’informazione atomica,
ma può divenire tale se viene “inquadrata” nell’ambito dei documenti
D3IM e l’incapsulamento di cui sopra ha la finalità di svolgere questa
operazione.
Un esempio che permette di chiarire questo tema è relativo al concetto
di responsabilità dell’informazione appena citato: parafrasando ciò che
è stato introdotto in precedenza ogni informazione presente in un qualsiasi
documento D3IM deve avere un responsabile, ovvero l’entità che ha autorità
su di essa. Il concetto di responsabilità è direttamente associato alle
informazioni primitive e sarà affrontato nel paragrafo successivo. In questo
contesto è sufficiente considerare il responsabile come una proprietà, o attributo,
dell’informazione. In questi termini l’incapsulamento della coppia
“” all’interno di un’informazione primitiva permette di farle
ereditare il responsabile di quest’ultima, rendendola quindi dotata dell’attributo
necessario per poter appartenere allo spazio delle informazioni definite
in D3IM.
In questo modo il problema della gestione delle informazioni viene semplificato:
• da una parte viene ricondotto verso il gestore di quella informazione,
il quale ha le nozioni sufficienti a stabilire le regole sintattiche e le
condizioni a contorno;
• dall’altra l’utente consumatore ha il dovere di cercare i valori e non più
l’onere di acquisirli nuovamente.
In questo modo si tende anche a realizzare il presupposto ai requisiti di
unico inserimento dei dati nel sistema, pertinenza e non eccedenza. Comunque
per non rendere troppo rigido il modello dovrà essere tenuta in
considerazione anche la possibilità di:
87

Modello dell’informazione versionata D3IM I nodi informativi del documento
• inserire i dati con strategie di autonomia a responsabilità diversificata;
• correggerli ed arricchirli in fasi successive ed indipendenti.
4.2.3 Informazioni primitive
È stato anticipato che le informazioni primitive modellano gli aspetti
strutturali sfruttando il principio di aggregazione fra nodi. Ogni nodo contenente
un’informazione primitiva può essere genitore di una serie di nodi
contenenti altre informazioni primitive. L’unico vincolo esistente è che nella
struttura non siano presenti cicli (ovvero ogni informazione primitiva non
può essere figlia, nipote, pronipote, etc. o antenata di se stessa).
Le relazioni fra informazioni primitive vengono instaurate sulla base degli
indirizzi univoci e persistenti (PRI) descritti nel paragrafo 4.2.1. Si osservi
che l’esistenza di più alias (indirizzi LRI) verso l’informazione e di più repliche
della stessa (accessibili tramite gli URL) sono aspetti ininfluenti ai fini di
questa trattazione.
A seguito del concetto di “incapsulamento” introdotto nel paragrafo precedente,
le informazioni atomiche non hanno un proprio indirizzo all’interno
dello spazio dei nomi PRI definito in D3IM, ma ereditano quello dell’informazione
primitiva che le incapsula. Eventualmente è possibile ipotizzare un
meccanismo equivalente a quello delle ancore presente nel web: fissato l’indirizzo
univoco dell’informazione primitiva è possibile specificare, tramite un
parametro addizionale, qual è l’informazione atomica di interesse. In questo
modo risulta possibile indirizzare univocamente anche le informazioni atomiche.
Per quanto riguarda gli indirizzi logici (LRI) e fisici (URL) non è
possibile fare ipotesi. Ad esempio si può definire un indirizzo LRI che individui
un’informazione atomica tramite il meccanismo menzionato simile alle
ancore, come è ipotizzabile che l’accesso fisico ad un’informazione atomica
avvenga tramite un URL.
Il concetto di incapsulamento può essere visto anche come ottimizzazione
dal punto di vista ingegneristico, in quanto permette di contenere l’esplosione
del numero di indirizzi univoci presenti nello spazio dei nomi persistenti,
senza perdere in generalità: in questo modo infatti le informazioni atomiche
non hanno un proprio indirizzo univoco. Questo aspetto porta anche un altro
vantaggio: il numero di elementi distinti che costituiscono i documenti risulta
molto minore rispetto a quello che si avrebbe assegnando una propria identità
88

Modello dell’informazione versionata D3IM I nodi informativi del documento
(indirizzo PRI) alle informazioni atomiche, senza rinunciare ai vantaggi della
suddivisione granulare dell’informazione che la soluzione proposta offre.
Riassumendo, ogni informazione primitiva è quindi genitore di altre informazioni
primitive ed incapsula (contiene) al proprio interno un certo numero
di informazioni atomiche. Si osservi come da questo caso generale si possano
definire documenti, come casi particolari, introducendo ulteriori restrizioni.
Ad esempio un vincolo che può essere introdotto riguarda la mutua esclusione
fra l’aggregazione e l’incapsulamento: in questi termini ogni informazione
primitiva aggrega altre informazioni primitive senza incapsulare informazioni
atomiche oppure incapsula informazioni atomiche senza aggregare
informazioni primitive. Documenti strutturati secondo questa modalità hanno
le informazioni atomiche esclusivamente nelle foglie. Inoltre tutte le foglie
contengono necessariamente informazioni atomiche e pertanto esiste una perfetta
corrispondenza fra le foglie e le informazioni atomiche e fra gli atri nodi
e le informazioni primitive.
Un altro vincolo che può essere introdotto riguarda la possibilità di limitare
il numero di genitori fra zero e uno. Questo permette di generare
documenti con struttura ad albero (orientato) come caso particolare di DAG.
Da un punto di vista astratto è possibile considerare le informazioni primitive
come il punto di accesso all’informazione complessiva che si sviluppa
da esse fino alle foglie, come evidenziato in figura 4.1.a.
Questa associazione sarà ancora più chiara quando verrà illustrato il meccanismo
di gestione delle versioni che si innesca in corrispondenza della modifica
di un’informazione (ogni modifica ad un qualunque elemento che risulta
essere successore nella gerarchia del nodo, si ripercuote su di esso).
Infine ad ogni nodo contenente un’informazione primitiva è associato un
responsabile. Il responsabile deve garantire la correttezza della struttura
(legame logico tra le parti) e, per le informazioni atomiche incapsulate, la
correttezza dei dati associati alle coppie “”.
Per esempio si faccia l’ipotesi che la patente di guida debba contenere i
seguenti elementi:
• numero;
• categoria;
• dati anagrafici.
89

Modello dell’informazione versionata D3IM Relazioni fra i nodi informativi
La Motorizzazione Civile deve garantire la correttezza delle coppie “”
e “”. È l’anagrafe a garantire la correttezza
delle informazioni atomiche relative ai dati anagrafici, la motorizzazione
è responsabile per quanto riguarda la sola aggregazione all’interno del
documento.
4.3 Relazioni fra i nodi informativi
Un documento ha la particolarità di essere classificabile come entità autonoma
pur essendo costituito da un insieme di informazioni disgiunte. Ogni
documento ha una radice che lo individua, nel senso che questa rappresenta
il punto d’accesso al documento, la quale è un’informazione primitiva.
Dualmente ogni informazione primitiva può essere vista come radice di un
documento.
A partire dalla radice esistono delle relazioni che la mettono in collegamento
con altre informazioni primitive. Questo procedimento si ripete in
modo ricorsivo fino a quando non vengono raggiunte tutte le foglie ovvero
tutte le informazioni atomiche.
Link di composizione. Le relazioni che legano le informazioni interne
al documento (secondo i principi precedentemente descritti) si definiscono
link di composizione. In riferimento al modello UEVM, che si ricorda essere
ampiamente descritto nel capitolo 2, i link sono da intendersi come relazioni
che legano due nodi di cui uno è il padre e l’altro il figlio. In particolare questi
link sono quelli per i quali il nodo padre è di tipo C; tale corrispondenza
ha condotto alla scelta del nome “link di composizione”. Questo porta a
concludere che esiste una equivalenza fra i nodi di tipo C del modello UEVM
e le informazioni primitive di D3IM.
Link di riferimento. Come evidenziato in UEVM esiste la necessità di
introdurre delle relazioni fra documenti distinti. In UEVM questo problema
viene risolto introducendo nodi di tipo L. Equivalentemente in D3IM sono
stati definiti i link di riferimento che svolgono lo stesso tipo di funzione.
Questo tipo di collegamento, che modella il caso di correlazione fra documenti
distinti ovvero fra nodi appartenenti a documenti diversi, può essere
facilmente classificato come informazione atomica.
90

Modello dell’informazione versionata D3IM Storico dei documenti
4.4 Storico dei documenti
Ogni documento dispone di caratteristiche atte a memorizzare la sua evoluzione
temporale, chiamata storico. Tale evoluzione, sebbene sia una caratteristica
globale del documento, viene mantenuta memorizzando l’evoluzione
delle singole informazioni che lo costituiscono (a livello di nodo).
Le evoluzioni temporali delle singole informazioni (che si ricorda essere
strutturate a DAG), pur essendo mantenute separate ed associate ad esse, non
sono indipendenti: una modifica effettuata ad un’informazione che si trova ad
un livello più basso della gerarchia si ripercuote su tutti i suoi predecessori.
Questo fa sì che lo storico della radice “comprenda”, seppur indirettamente,
l’evoluzione temporale di tutto il documento. Volendo recuperare una data
versione7 , è previsto un meccanismo di navigazione nello storico che, partendo
dalla radice ed attraversando i vari nodi del documento, permette di
ricomporlo come richiesto. È utile evidenziare come il meccanismo, basandosi
su un modello estensionale, permetta, a differenza di altri modelli di
versioning, di ripercorrere lo storico del documento nel modo più naturale
possibile per l’utente: ogni versione del documento viene ricostruita correttamente
sia per quel che riguarda i dati contenuti sia per quanto riguarda gli
aspetti strutturali.
Per descrivere i meccanismi di gestione dello storico è utile inizialmente
fare riferimento ad un documento costituito da un unico nodo e, successivamente,
estendere il concetto al caso più generale.
Sotto l’ipotesi che ogni nodo, una volta creato, sia una grandezza immutabile
nel tempo l’operazione di modifica dà vita ad un nuovo nodo. Si definisce
versione un’informazione primitiva ottenuta modificando il contenuto
informativo di un nodo esistente. Anche la nascita di una nuova informazione
rientra in questa definizione considerando che tale operazione può essere vista
come la modifica dell’informazione nulla. Viene definito uno stato UPDATE
che viene associato ad ogni informazione per determinare se è necessario generare
nuove versioni oppure effettuare sovrascritture. Il valore assunto dallo
stato può essere frozen o changing rispettivamente. Le transizioni avvengono
tramite le operazioni di freeze e melt, figura 4.3.
È opportuno chiarire cosa si intende con “modifica” di un’informazione al
variare del tipo di essa:
7 In questo caso con versione si intende una ben precisa configurazione del documento.
A riguardo si faccia riferimento al capitolo 2.
91

Modello dell’informazione versionata D3IM Storico dei documenti
UPDATE
melt
changing
frozen
freeze
close [in hard]
Figura 4.3: Stato “Update” delle informazioni.
• nel caso di informazione atomica si parla di cambiamento di uno o di
entrambi i campi “nome” o “valore”;
• nel caso di informazione primitiva si parla di cambiamento di una o più
delle relazioni di aggregazione che partono dall’informazione in esame
o dei metadati ad essa associati.
Può essere utile specificare che per quanto riguarda i link di riferimento, siccome
rientrano nella prima categoria, il nodo che contiene il link si considera
modificato solo se cambia il valore stesso del link. Eventuali variazioni del
nodo riferito dal link non determinano variazioni dello storico del documento
che lo contiene.
È possibile modificare solo e soltanto l’ultimo nodo creato all’interno dello
storico e, nel caso in cui lo stato UPDATE sia frozen, quello che si genera è
un insieme ordinato di revisioni. Viceversa per modificare un nodo che non
sia l’ultimo occorre creare una diramazione o branch (figura 4.4).
L’ordinamento delle versioni nella diramazione è totale, in quanto sull’insieme
è ben definita la relazione di revisione (−→) con le seguenti proprietà:
1. riflessiva: per ogni versione x appartente ad una diramazione, si ha
x−→x;
2. antisimmetrica: per ogni versione x, y appartenenti ad una stessa
diramazione, tali che x−→y e y−→x, allora x≡y;
3. transitiva: per ogni versione x, y, z appartenenti ad una stessa diramazione,
tali che x−→y e y−→z, allora x−→z;
92

Modello dell’informazione versionata D3IM Storico dei documenti
4. confronto: per ogni versione x, y appartenenti ad una stessa diramazione,
si ha x−→y oppure y−→x.
La creazione di una nuova diramazione avviene su esplicita richiesta dell’utente.
Ad esempio consideriamo il ramo x al tempo t0 in figura 4.4. La
richiesta di nascita di una diramazione a partire dalla prima versione x.0 al
tempo t1>t0 comporta la creazione del ramo y contenente la nuova versione
y.0. Al tempo t2>t1 la modifica di x.1 viene applicata nello stesso ramo con
la revisione x.2.
Branch x (t0) Branch x (t 1 > t 0 ) Branch x (t2 > t1 > t0)
x.0 x.1 x.0 x.1 x.0 x.1 x.2
Branch y (t1) Branch y (t2)
y.0
Figura 4.4: Generazione delle revisioni.
Lo storico è interrogabile esprimendo esplicitamente la versione desiderata.
Comunque è possibile estendere l’interrogazione anche attraverso delle
proposizioni logiche: ogni versione contiene al proprio interno dei riferimenti
relativi alle versioni precedenti ed a quelle successive
4.4.1 La propagazione delle modifiche
Le versioni sono correlate attraverso l’aggregazione e possono concorrere
a formare arbitrarie strutture: se mettiamo in evidenza solo le versioni e
le relazioni di aggregazione che le connettono ciò che otteniamo è un grafo
orientato. La nascita di una nuova revisione scatena un meccanismo di propagazione
nel grafo attraverso i cammini che si sviluppano in senso opposto
rispetto alla direzione degli archi relativi ai link di composizione che partono
dall’ultima revisione di ogni branch.
Si può osservare che la propagazione all’interno della struttura del documento
corrente è un caso particolare, poiché in generale coinvolge tutti quei
y.0
93

Modello dell’informazione versionata D3IM Storico dei documenti
documenti che hanno dei sotto alberi in comune legati da link di composizione.
I link di riferimento permettono di creare correlazioni fra dati come
avviene per i link di composizione; la differenza sostanziale è che, nel caso
dei link di riferimento, non si ha la propagazione delle versioni.
Durante una sessione al massimo vengono create tante versioni quanti
sono i nodi coinvolti. Ripetute operazioni su un nodo sono parte integrante
della stessa attività. Ripetute aggiunte, cancellazioni, e cambiamenti dei
figli di un nodo genereranno una ed una sola versione relativa a quel nodo.
L’estensione temporale di una sessione è sfruttata per controllare la granularità
del versioning. I meccanismi menzionati riflettono a pieno quelli visti in
UEVM, a cui deve essere fatto riferimento per ulteriori dettagli.
4.4.2 Authoring concorrente
Consideriamo un’informazione primitiva sulla quale vengono effettuate
operazioni di lettura e scrittura, intendendo con scrittura anche la modifica
strutturale, cioè l’aggiunta o l’eliminazione di nodi. Le operazioni, pur essendo
rivolte verso la radice, coinvolgono tutti quei nodi del documento sui
quali l’utente ha i diritti per operare. In questo paragrafo, per semplicità e
senza perdere in generalità, si suppone che tutti gli utenti possano accedere
alle informazioni in lettura e che solo il relativo responsabile possa effettuare
modifiche. Ogni operazione avviene all’interno di una sessione.
Si può incorrere nella concorrenza delle operazioni per due motivi:
1. è richiesta una attività di authoring parallelo sullo stesso documento
(figura 4.5.a);
2. due o più documenti, che aggregano una stessa informazione primitiva,
vengono aperti in intervalli di tempo sovrapposti (figura 4.5.b).
Concettualmente sono attività diverse, ma in questo contesto vengono trattate
in modo indistinguibile.
Dato che le sessioni di lettura sono non distruttive e quindi meno critiche,
non richiedono complesse tecniche di gestione, a patto di tenere presente il
requisito di awareness percepito dall’utente (vedi il paragrafo 1.2 a pagina 7).
Deve esistere un opportuno sistema di accodamento delle operazioni di lettura
rispetto a quelle di scrittura.
94

Modello dell’informazione versionata D3IM Storico dei documenti
(a) (b)
Req 1 Req 2
Info1
Req 1 Req 2
Info1
Info3
Info2
Figura 4.5: Casi di authoring concorrente.
Il concetto di responsabilità sui nodi consente di limitare la propagazione
dell’apertura delle sessioni in scrittura all’interno del DAG. Ad esempio in
figura 4.5.b si possono verificare 3 situazioni:
1. nessuna delle richieste è effettuata dall’autorità responsabile della terza
informazione (info3): nessuna sessione in scrittura è possibile sui nodi
che hanno info3 (compreso) come predecessore;
2. solo una richiesta proviene dal responsabile di info3: solo uno può
modificare info3;
3. entrambe le richieste provengono dal responsabile di info3: è una situazione
effettivamente singolare, soprattutto alla luce sulle ipotesi fatte
sull’unicità del responsabile, ma può presentarsi.
Alla luce di queste considerazioni è indispensabile definire uno o più
meccanismi necessari al controllo e alla gestione delle sessioni.
Controllo delle sessioni
Con questa prospettiva si individuano tre politiche di apertura di una
sessione in scrittura:
• Strong.
95

Modello dell’informazione versionata D3IM Storico dei documenti
• Soft.
• Relaxed.
La Strong blocca sia in lettura che in scrittura tutti i nodi interessati
dall’apertura della sessione. Ad esempio, riconsiderando la figura 4.5.b, ed
ammettendo che la prima richiesta accettata sia avvenuta su info1 con modalità
Strong, successive richieste di apertura di sessione per la modifica di
info1 o semplici richieste di accesso verrebbero rifiutate.
La Soft invece blocca i nodi in scrittura senza inibire l’accesso in sola lettura.
Nell’esempio precedente verrebbero rifiutate ulteriori richieste di apertura
di sessione in scrittura su info1, ma la possibilità di accedere all’informazione
verrebbe comunque garantita.
Queste due tipologie di blocco permettono la gestione della politica di accesso
concorrente turn-taking, descritta nel sotto paragrafo 1.2.4 a pagina 17.
Come dimostrato in vari contesti questa politica, anche se comporta alcuni
inconvenienti, può risultare utile o addirittura necessaria per certe tipologie
di documenti.
Ad esempio si consideri un documento costituito da un’unica immagine
in formato Jpeg (queste considerazioni sono valide per la maggior parte dei
documenti, se non tutti, costituiti da un file in formato binario). Il formato
Jpeg è tale che ad una modifica localizzata dell’immagine non corrisponda
una modifica equivalentemente localizzata nel file. In altre parole ogni modifica,
indipendentemente dalla sua entità, può portare alla variazione di tutto
il file.
Ipotizzando quindi che due utenti modifichino l’immagine in aree non sovrapposte
(ad esempio in alto a destra e in basso a sinistra) non è possibile
fondere i cambiamenti in un’unica immagine analizzando soltanto i file modificati
senza comprenderne la codifica (in questo caso si potrebbe ipotizzare
che il sistema sia in grado di decodificare le immagini, sovrapporle ricercando
eventuali conflitti e poi codificare nuovamente il risultato dell’operazione,
ma nella pratica ciò non è possibile per innumerevoli motivi e si potrebbero
comunque trovare svariati esempi per i quali tale operazione non è possibile
neanche a livello concettuale).
Questo inconveniente impedisce, di fatto, di individuare e risolvere i conflitti:
qualora due o più utenti modificassero contemporaneamente lo stesso
documento, tutti perderebbero il lavoro svolto eccetto uno (l’ultimo che
“salva”, sovrascrivendo il documento esistente). L’unico modo per aggirare
96

Modello dell’informazione versionata D3IM Storico dei documenti
questo ostacolo è quello di ricorrere ad un blocco esclusivo del file facendo
uso dell’approccio turn-taking.
L’introduzione di due politiche di lock, la prima sia in lettura che in scrittura
la seconda solo in scrittura, risulta necessaria per garantire la massima
flessibilità del modello del documento: come noto, negli ambienti concorrenti,
possono verificarsi casi in cui, all’interno della finestra temporale necessaria
al completamento delle operazioni di modifica di un gruppo di dati, l’accesso
in lettura ad essi da parte di altri utenti potrebbe portare ad ottenere risultati
inconsistenti. Per garantire che non si verifichino letture inconsistenti si
ricorre alla politica Strong. Quest’ultima è estremamente conservativa e se è
possibile non inibire l’accesso in lettura in presenza di modifiche che richiedono
l’acquisizione esclusiva della risorsa (sia perché si riesce a garantire la
consistenza dei dati letti in modo diverso oppure perché è possibile ritenere
accettabile una certa probabilità di errore) si ricorre alla politica Soft che
risulta essere meno conservativa e vincolante.
Infine la Relaxed consente l’authoring concorrente tramite l’approccio
copy-merge descritto nel sotto paragrafo 1.2.4 a pagina 17. Occorre specificare
che, in questo caso, si ha un conflitto qualora due o più utenti modifichino
lo stesso nodo, indipendentemente dall’entità della modifica.
Nell’esempio precedente, riferito ai file Jpeg, è stato illustrato come non
sia sempre possibile individuare e risolvere i conflitti per certe tipologie di informazioni
rappresentate da un unico file (e quindi che normalmente verranno
codificate in un unico nodo D3IM). Questo non esclude che per altre categorie
di informazioni codificate all’interno di un unico nodo D3IM sia possibile
determinare algoritmi in grado di analizzarne e comprenderne il contenuto
ed agire di conseguenza per quanto riguarda la rilevazione e la gestione dei
conflitti. Un esempio che può essere citato riguarda l’authoring di codice sorgente:
in questo caso si può modellare l’ambiente inserendo il contenuto di
ogni file sorgente appartenente al progetto all’interno di un’informazione atomica.
In questo caso è abbastanza semplice comprendere come sia possibile
analizzare il contenuto dell’informazione atomica per stabilire se due utenti
hanno modificato le medesime porzioni di codice oppure porzioni diverse in
modo da applicare le politiche di gestione dei conflitti in modo equivalente
agli SCM (Software Configuration Management) descritti nel capitolo 2.
La modalità Relaxed, come evidenziato nei capitoli 1 e 2, è più adatta ad
essere usata in contesti nei quali l’accesso e la modifica dei dati avvengono
da parte di più individui e pertanto, escludendo i casi particolari che devo-
97

Modello dell’informazione versionata D3IM Lo stato di un documento
no essere gestiti ricorrendo alle politiche precedenti, è quella da utilizzarsi
preferibilmente.
In ogni modo ricorrere alla tipologia “sessione Relaxed” nelle richieste di
scrittura, incrementa la consapevolezza ad alto livello in quanto permette
all’utente di prendere atto del fatto che il documento (o parte di esso) è in
fase di aggiornamento.
In realtà, come anticipato all’inizio del paragrafo, il concetto di responsabilità
fa sì che non tutti gli utenti possano modificare indiscriminatamente
i documenti (o parti di essi) conseguentemente si ha una combinazione di
modelli: split-combine associato a turn-taking oppure a copy-merge.
4.5 Lo stato di un documento
Per definizione in D3IM lo stato di un documento è un’entità che serve
a quantificare la qualità dell’informazione che questo contiene. Così come
avviene per il versioning anche per lo stato viene fatto riferimento ai singoli
nodi: le informazioni atomiche hanno uno stato che dipende direttamente
dalla qualità delle coppie “”, mentre le informazioni primitive
assumono un valore di stato che dipende dalle informazioni che aggregano
ed incapsulano. Quindi, anche in questo caso, si prevede un meccanismo di
propagazione dello stato che, a partire dai nodi in fondo alla gerarchia, risale
gli antenati (dai figli verso i genitori) fino al capostipite assegnando, man
mano, lo stato ai nodi attraversati.
4.5.1 Lo stato delle informazioni
Lo stato delle informazioni atomiche
Un’informazione atomica può essere soggetta a modifiche oppure può essere
memorizzata in modo definitivo. Ortogonalmente esistono dei parametri
per stabilire la qualità dell’informazione. Lo stato QUALITY indica la qualità
dei dati ed è rappresentato in figura 4.6 con il formalismo delle state
chart.
Un’informazione atomica può essere una bozza (draft), ammissibile sintatticamente
(allowable) oppure accurata sintatticamente (accurate). La transizione
dello stato allowable avviene quando è verificato il controllo sintattico,
se poi sono verificate anche le restrizioni lo stato passa in accurate. Con re-
98

Modello dell’informazione versionata D3IM Lo stato di un documento
QUALITY
write-open
[in changing]
write-open
[in changing]
accurate
draft
allowable
set
soft allowable
set
syntax check
[verified]
restriction check
[verified]
Figura 4.6: Stati di un’informazione atomica.
strizioni si intendono tutte quelle regole che limitano il valore ad un intervallo
o ad un particolare insieme di valori.
Lo stato delle informazioni primitive
Come mostrato in figura 4.7, il comportamento dell’informazione primitiva
è un AND di stati delle informazioni aggregate a cui se ne aggiungono
ulteriori due, similmente definiti a quelli di un’informazione atomica, ma
propri di questa informazione. La definizione delle state chart è ricorsiva
e la complessità dipende dal numero di livelli della gerarchia associata al
documento.
Condizione necessaria e non sufficiente affinché un’informazione primitiva
risulti consistente è che ogni informazione aggregata (o tutte atomiche o tutte
primitive) sia singolarmente accurata. Per gli altri stati le seguenti condizioni
sono anche sufficienti:
1. è nello stato di bozza (draft), se almeno un’informazione aggregata è
nello stato di bozza;
2. è nello stato di ammissibile (allowable), se nessuna informazione aggregata
è nello stato di bozza ed almeno una nello stato di ammissibile;
H
99

Modello dell’informazione versionata D3IM Lo stato di un documento
info_1 ... info_N
write-open
[this in
changing]
write-open
[this in
changing]
write-open
[this in
changing]
consistency
draft
allowable
accurate
set
soft hard
Figura 4.7: Stati di un’informazione primitiva.
set
syntax check
restriction
check
3. è nello stato di accurata (accurate) sintatticamente, se ogni informazione
aggregata è accurata sintatticamente.
In tabella 4.1 sono riportate schematicamente le regole di transizione per
determinare lo stato nel caso in cui l’aggregazione sia di sole due informazioni.
Per N informazioni basterà applicare tali regole iterativamente a coppie di
informazioni disgiunte per N-1 volte.
Per le informazioni primitive è possibile un ulteriore controllo che riguarda
la verifica della consistenza. Questo permette di far transitare lo stato da
accurate a consistency.
Con controllo della consistenza si intende la verifica della coerenza logica
e/o semantica tra le informazioni aggregate. Lo stato consistency indica
quindi che l’informazione complessiva, costituita da una serie di informazioni
più semplici, è corretta nella sua globalità. Questa è un’affermazione più
H
100

Modello dell’informazione versionata D3IM Lo stato di un documento
Info 2
Draft
Info 1
Draft Allowable
Draft
Draft
Allowable Draft Allowable
Accurate Draft Allowable
Accurate
Draft
Allowable
Accurate
Tabella 4.1: Mappa per la determinazione degli stati.
forte rispetto al dichiarare che tutte le informazioni più semplici, prese singolarmente,
sono corrette. Si consideri ad esempio una via ed un numero civico
di un indirizzo: il nome della via può essere accurato così come il numero
civico, però in quella via potrebbe non esistere quel numero.
101

Parte III
Dai modelli teorici
all’architettura concreta

Capitolo
5
Architettura CISA
Il principale obiettivo che si intende raggiungere in questo progetto è
rappresentare l’informazione da un punto di vista concettuale in modo che
sia possibile:
• prevedere un metodo per rendere l’informazione condivisa;
• ridurre la complessità della comunicazione.
Come espresso in [Pra03] un Information Model non si addentra nei dettagli,
ma cerca di catturare le astrazioni ed i requisiti fondamentali. Uno
dei principali vantaggi di un Information Model è proprio la capacità di dare
vita a più Data Model. La possibilità di generare molti Data Model dallo
stesso Information Model è indice di scalabilità ed adattabilità del modello a
contesti diversi. Inoltre, per la realizzazione, è possibile scegliere tra una vasta
gamma di standard e tecnologie già esistenti, se rispondenti alle esigenze.
D’altra parte questa prospettiva rappresenta anche una forte restrizione che
consiste nel dover rimanere ad un elevato livello di astrazione. La sottile linea
che divide il modello astratto dai rispettivi modelli concreti non è sempre di
facile identificazione.
Per poter applicare i modelli descritti in precedenza occorre quindi passare
da una schematizzazione astratta ad una più concreta. Di seguito verrà proposta
un’architettura che implementa le caratteristiche astratte del modello,

Architettura CISA Visione stratificata di CISA
creata con lo scopo di costituire un’infrastruttura sulla quale basare specifiche
applicazioni. Nella definizione dell’architettura si delineano dei Data Model
conformi all’Information Model di riferimento, ma viene quindi lasciata la
massima libertà per quanto riguarda la definizione dell’applicazione.
Il progetto Collaborative Information System Architecture, in breve CISA,
definisce una stratificazione di sistemi per rendere efficace ed efficiente la collaborazione
tra utenti in rete. Il sistema non è pensato solo come riferimento
per lo sviluppo di piattaforme per le attività collaborative, ma più in generale
come ambiente operativo disponibile all’utente per svolgere attività tradizionali
e concorrenti. Tale ambiente consentirà di sfruttare in modo trasparente
la natura distribuita che sta alla base.
5.1 Visione stratificata di CISA
L’orientamento verso un’architettura stratificata è stato suggerito da S.
Melnik e S. Decker i quali, in [MD00], evidenziano come questo approccio
risulti conveniente non solo per l’internetworking, ma anche per la gestione
dei dati nello lo scenario del web semantico. Il termine interdataworking
è stato introdotto in questo contesto sulla base dell’analogia esistente fra
il modello stratificato da loro proposto e il modello stratificato utilizzato
convenzionalmente nelle reti di computer.
In questo modo è possibile ridurre considerevolmente la complessità della
soluzione al problema. A tal fine sono stati identificati dei livelli (Application,
Virtual Repository, Structure, Replica Management e Medium Dependent),
tenendo presenti i principi di:
• separation of concern: ogni livello viene definito trattando separatamente
i soli problemi che riguardano il livello stesso, mettendo da parte
problematiche inessenziali o che verranno trattate da altri livelli;
• information hiding: ogni livello espone all’esterno solo l’informazione
indispensabile alla comunicazione con i livelli adiacenti, mantenendo
interna ogni altra necessaria informazione;
• good enough: la progettazione deve essere sufficiente a risolvere il problema,
senza pretendere il miglior risultato possibile in tutte le circostanze.
104

Architettura CISA Visione stratificata di CISA
Ogni livello è tenuto a rispondere in maniera corretta alle chiamate che
gli competono e che verranno generate dai livelli ad esso adiacenti. La logica
interna, con cui le funzioni di competenza verranno elaborate, non è visibile
dall’esterno. Naturalmente la strategia good enough risulta vincente solo
se unita alla capacità del sistema di crescere e migliorarsi nel tempo. Una
possibilità per ottenere questa caratteristica è renderlo aperto in tutto il suo
ciclo di sviluppo (analisi, progettazione, implementazione e validazione).
Come nel caso del web semantico i vari layer operano ad un livello di
astrazione diverso per quel che riguarda il concetto di informazione (figura
5.1).
Quelli più alti percepiscono l’informazione come entità complessa sotto
forma di documento. Ogni documento è costituito da una serie di informazioni
elementari legate da relazioni strutturali.
Spostando l’attenzione verso i livelli intermedi gli aspetti strutturali dell’informazione
vengono meno: l’informazione è vista come tante unità elementari
indipendenti.
Infine per i livelli più bassi l’informazione è semplicemente una particolare
codifica delle entità definite ai livelli superiori, in altre parole “sequenze di
byte” (file e record di database).
Livello di astrazione
dell'informazione
Informazioni
complesse
(documenti).
Informazioni
elementari
(nodi).
Byte.
(file, database).
Application
Layer
Virtual Repository
Layer
Structure
Layer
Replica Management
Layer
Medium Dependent
Layer
Figura 5.1: Livelli dell’architettura CISA.
Con questa prospettiva, nel presente lavoro, si parla di livello (o layer)
per fare riferimento ad un contenitore logico di sottosistemi concreti e indipendenti
che manipolano ed effettuano specifiche operazioni sull’informazione
vista come entità astratta. Tali sottosistemi interagiscono fornendo o
105

Architettura CISA Visione stratificata di CISA
richiedendo servizi ad altri sottosistemi appartenenti allo stesso livello logico
oppure ad altri livelli adiacenti.
Principalmente CISA descrive i livelli Virtual Repository, Structure e Replica
Management. Vincolare e dettagliare gli strati Application e Medium
Dependent, alle estremità dello stack, non risulta conveniente ai fini, rispettivamente,
della crescita del sistema e dell’adattabilità verso il passato. Per
quanto concerne la crescita viene infatti lasciata la massima libertà per quel
che riguarda la definizione del contesto applicativo che può essere diversificato
e, equivalentemente, non vengono fissate specifiche stringenti sul formato
di storage dei dati. Quest’ultimo aspetto permette quindi di diversificare
anche le soluzioni di basso livello, aspetto che garantisce l’adattabilità con il
passato ovvero la possibilità di riutilizzare, definendo dei Medium Dependent
ad hoc, i sistemi legacy attualmente in possesso delle organizzazioni. Non
è infatti possibile ipotizzare una completa conversione dello storico dei documenti
in formato elettronico in loro possesso in un nuovo formato, i quali
dovranno pertanto essere riutilizzati all’interno del sistema “così come sono”.
Si noti come questo approccio equivalga a quello utilizzato nella definizione
della pila Internet nella quale è stata lasciata la massima libertà per quanto
riguarda la definizione del livello applicativo e dei livelli inferiori a quello di
rete.
Per quanto riguarda la modalità di interazione fra i vari livelli è stato scelto
di ricorrere ad un approccio REST-like (Representational State Transfer,
REST [Fie00, Res05]). REST è stato introdotto da Roy Thomas Fielding
ed è definito tramite un insieme di linee guida seguendo le quali si realizza
un’architettura strutturata come il World Wide Web il quale ha, nell’ultimo
decennio, indiscutibilmente dimostrato di essere scalabile e per questo è stato
preso come riferimento.
L’interazione avviene tramite il paradigma client/server: ogni livello è
client di quello inferiore (al quale richiede servizi) e server di quello superiore
(al quale fornisce dei servizi). Quindi, per ogni coppia di livelli, viene
definito un protocollo di comunicazione che, come HTTP (vedi [FIG + 99]), è
request/response. Il paradigma convenzionale di interazione fra l’utente e il
sistema è di tipo pull: in seguito ad un’azione dell’utente la pila viene attraversata
da una sequenza di request che si sviluppa dall’alto verso il basso e
da una sequenza corrispondente di response che la percorre in senso opposto.
Ogni livello si attiva per generare la response a seguito di ogni request proveniente
dal livello superiore (o da un’azione dell’utente per quanto riguarda
106

Architettura CISA Visione stratificata di CISA
il livello applicativo), eventualmente effettuando delle richieste ai livelli inferiori
(come evidenziato in figure 5.2) per richiedere l’espletamento di servizi
necessari per il completamento dell’operazione.
Richiesta dell'utente Risposta all'utente
Livelli CISA
Request - Response
Tempo
Figura 5.2: Paradigma di interazione request/response.
Un meccanismo di notifica in modalità push, che può risultare utile in svariati
contesti (ad esempio per inoltrare segnalazioni in tempo reale all’utente
a seguito di eventi che si sono verificati nel sistema), può essere introdotto in
una fase successiva dello sviluppo del progetto. Allo stato attuale è infatti
possibile ipotizzare che tale modalità operativa possa essere introdotta senza
interferire con il lavoro già svolto (rispetto al quale è una caratteristica del
tutto ortogonale) ricorrendo a protocolli ed a canali di comunicazione dedicati.
Risulta infine utile osservare come la modalità push possa essere simulata
in presenza della sola modalità pull (a scapito dell’efficienza operativa) tramite
polling. Questo permette quindi di concludere che, almeno al momento,
è possibile rimandare l’inserimento di tale modalità operativa senza perdere
in generalità.
Nei capitoli seguenti verranno descritti in modo approfondito i livelli di
CISA, mentre l’analisi dei protocolli e delle interfacce di comunicazione verrà
affrontata dettagliatamente nel capitolo 9.
107

Architettura CISA Visione stratificata di CISA
5.1.1 Application Layer
A questo livello appartengono non solo tutte le applicazioni specializzate
per trattare i documenti in particolari contesti come i tool di gestione
e di authoring, ma anche tutti i sottosistemi utilizzati direttamente (o
indirettamente) dall’utente.
Si prevede che il livello Application sia costituito da tre sottolivelli: di
presentazione, di elaborazione e di interfaccia. La presentazione pone l’informazione
in una forma tale da facilitarne la fruizione (lettura e scrittura) da
parte dell’utente; il sottolivello di elaborazione definisce tutti gli algoritmi di
livello applicativo atti a gestire il funzionamento della specifica applicazione;
l’interfaccia è necessaria per la comunicazione, tramite appositi protocolli,
con il layer sottostante. In questi termini la sottoparte di presentazione
dell’Application Layer rappresenta il front-end dell’architettura.
Nel sotto paragrafo 4.2.1 (a pagina 82) sono stati introdotti gli LRI (Logical
Resource Identifier) come particolari HFN. Tali nomi rappresentano lo
spazio di indirizzi da utilizzare a questo livello. Può essere ammesso l’uso un
sistema di nomi diverso purché sia previsto un meccanismo di traduzione da
tale sistema a LRI.
5.1.2 Virtual Repository Layer
A questo livello appartengono le entità dell’ambiente virtuale definito nel
capitolo 3: Avatar, Stuff, Group, World. Ogni entità ha uno o più nomi virtuali
(LRI) che la identificano ai quali è associato un indirizzo univoco (PRI):
il livello Virtual Repository provvede alla relativa risoluzione, vedi sotto paragrafo
4.2.1 a pagina 82. L’informazione è mantenuta in documenti D3IM
(definiti nel capitolo 4) che, in questo contesto, sono una specializzazione degli
Stuff e sono capaci di mappare entità astratte come libri, certificati, manuali,
tabelle di database, record, capitoli, paragrafi di testo, sezioni, documenti di
identità, e così via, in entità maneggiabili dagli Avatar. Per ogni documento
sono definite almeno le stesse operazioni di base previste per gli Stuff e che
verranno trattate con maggiore dettaglio nel prossimo sotto paragrafo.
È onere del livello Virtual Repository validare lo stato del documento
(come descritto nel paragrafo 4.5 a pagina 98) e permettere la navigazione
nell’universo virtuale.
In contrapposizione al livello applicativo rientra a pieno titolo, così come
tutti i livelli inferiori, nel back-end dell’architettura.
108

Architettura CISA Visione stratificata di CISA
Operazioni di base sulle entità
Alla luce delle definizioni delle entità, presentate nel capitolo 3, è possibile
stabilire con maggior dettaglio le operazioni effettuabili su di esse.
Produttori, consumatori e gestori dell’informazione agiscono su World,
Avatar, Group e Stuff conformemente ai permessi che i rispettivi Avatar
detengono. In una prospettiva ad alto livello è però più semplice pensare
che agiscano direttamente, assumendo che gli Avatar si comportino in modo
trasparente. Ciò permette di definire l’interfaccia dell’ambiente dal punto di
vista di chi lo utilizzerà.
In un’attività collaborativa il confine tra i tre ruoli sopra menzionati è ben
definito, ma non è altrettanto immediato attribuire l’insieme delle operazioni.
La partecipazione alle attività è variamente determinata e valutabile, ad
esempio chi prima si comporta da produttore può, un istante dopo, comportarsi
da consumatore e così via. È quindi conveniente introdurre anche una
classificazione più incentrata sulle individualità.
User
Admin
Producer Consumer Management
Gli utenti introducono
informazioni nel
sistema
L'amministratore
definisce permessi e
regole di produzione
dell'informazione
Gli utenti recepiscono o
prelevano informazioni
dal sistema
L'amministratore
definisce permessi e
regole di fruizione
dell'informazione
Gli utenti sono
coordinati da un
supervisione
L'amministratore
definisce i compiti
del gestore
Tabella 5.1: Decomposizione dei ruoli degli utenti.
La complessità del sistema non permette di stabilire a priori tutte le
tipologie di utenti. Ciò è anche conseguenza del fatto che si realizza un
ambiente dinamico e non vincolato da rigide regole predeterminate, capace
di adattarsi al maggior numero di contesti. È comunque possibile identificare
due principali categorie di utilizzatori, così come avviene nei sistemi operativi:
utenti generici e amministratori (tabella 5.1), tenendo presente che il sistema
dovrà anche essere in grado di catturare eventuali sfumature intermedie.
109

Architettura CISA Visione stratificata di CISA
Col termine utente si intendono non solo persone, ma anche applicazioni
o sistemi caratterizzati dal fatto che risultano esterni all’ambiente virtuale.
Ad esempio potrebbero essere client o agenti intelligenti.
Nei seguenti paragrafi verranno dettagliate le funzionalità delle entità presentate
nel capitolo 3, nel modo in cui sono percepite dagli utenti. Sarà dato
particolare rilievo ai principali servizi che dovranno fornire, senza rivelare la
propria struttura interna, e agli attori che li possono invocare.
Operazioni sugli Avatar. Un utente, prima di avviare qualunque altra
operazione, dovrà stabilire una connessione col proprio Avatar. Ciò avviene
attraverso le funzioni di login e logout che stabiliscono l’inizio e la fine di
una sessione di collegamento e determinano le transizioni tra gli stati interni
on-line ed off-line dell’Avatar.
Generalmente è richiesta l’autenticazione tra utente e Avatar tale da realizzare
la biunivocità dell’identità e delle responsabilità. Questo è un requisito
forte, ma necessario quando l’Avatar dovrà trattare dati sensibili, compiere
azioni a valore legale o, più in generale, azioni di particolare rilevanza
relativamente al contesto di interesse.
Ad ogni utente è concessa una certa libertà di movimento per collocare
il suo alter-ego virtuale nei mondi, quindi esisterà una funzionalità per simulare
gli spostamenti. Lo stesso utente potrà essere contemporaneamente
presente in più di un World, attraverso l’uso di più Avatar, a ciascuno dei
quali corrisponderà una sessione di login.
Come accennato nel capitolo 3, l’Avatar è un processo che deve essere
in grado di evolvere indipendentemente dallo stato dell’utente: può subire
operazioni e recepire messaggi per conto del suo proprietario anche quando
quest’ultimo è scollegato, permettendo di realizzare sia interazioni sincrone
che asincrone con le altre entità dell’ambiente.
Il profilo è definito come l’insieme di informazioni personali (ad esempio
età, residenza, cittadinanza, professione, hobby) che possono essere aggiunte,
eliminate o nascoste entro i limiti stabiliti dal gestore del Group di appartenenza
o dal World visitato. Ad esempio alcuni World potrebbero imporre
che alcuni dati debbano essere in chiaro per motivi amministrativi.
La creazione, la cancellazione e l’assegnazione dei permessi è a carico
dell’amministratore, il quale è un super-utente. Tramite il suo Avatar potrà
eseguire, in modo del tutto trasparente, queste operazioni su tutti gli Avatar
con minori diritti.
110

Architettura CISA Visione stratificata di CISA
Operazioni sui Group. Per i Group non ha senso parlare di sessioni di
login occorre invece parlare di appartenenza e non appartenenza al gruppo.
Sebbene sia l’Avatar ad essere sottoscritto ad un Group, si può assumere per
transitività che lo sia l’utente.
I Group sono entità dinamiche poiché possono variare nel tempo riguardo
alla struttura, al numero di utenti affiliati ed ai requisiti di appartenenza.
Alcune funzionalità assegnate all’utente e all’amministratore possono apparire
duplicate. La principale differenza consiste nell’entità su cui vengono
effettuate. Per un utente saranno riflessive, cioè applicabili solamente su se
stesso, per un amministratore di gruppo anche sugli altri.
L’avvio della sottoscrizione, cancellazione o espulsione può essere innescato
anche con procedure automatiche. Ad esempio uno Stuff capace di
monitorare l’evoluzione dei profili degli Avatar, può avviare una di queste
operazioni al verificarsi di particolari condizioni (in modo analogo ai trigger
nel contesto delle basi di dati).
Operazioni sui World. L’operazione di ingresso nel World permette di
navigare nell’ambiente virtuale. L’utente che tenta di entrare potrebbe non
aver stabilito una sessione di login, per cui deve effettuare la preventiva scelta
dell’Avatar che intende muovere nel mondo. L’uscita è una funzionalità
sottintesa, nel senso che l’utente permane nel World solamente per il tempo
necessario alla ricezione dei contenuti informativi.
Da un punto di vista strutturale i World hanno delle forti similitudini
con le directory del file system, mentre da un punto di vista di meccanismi
di comunicazione, assomigliano alle pagine Web.
Il tempo di permanenza nel mondo corrisponde al tempo necessario per
ottenerne i contenuti (sotto mondi e risorse). L’uscita è quindi determinata
in automatico alla conclusione delle operazioni legate all’acquisizione
dell’informazione. Dal lato World non è previsto il mantenimento dello
stato dell’utente, tale compito però può essere eventualmente demandato
all’Avatar.
Il successo di qualunque operazione ha come precondizione la verifica dei
permessi attuata tramite il confronto degli attributi del World con il profilo
dell’utente.
Conoscere gli Stuff disponibili è un requisito fondamentale per poter avviare
qualunque attività collaborativa o cooperativa o di interazione. L’identificazione
dell’oggetto mira all’uso dei suoi servizi.
111

Architettura CISA Visione stratificata di CISA
L’amministratore ha il compito di stabilire quali Avatar sono abilitati ad
entrare impostando opportunamente gli attributi del World come ad esempio
la visibilità, il numero massimo di richieste contemporanee e gli orari di
accesso.
L’aggiunta e la cancellazione degli Stuff, può essere concessa a qualunque
Avatar, ma di principio sono attribuite al solo amministratore.
Operazioni sugli Stuff. Ogni risorsa risiede in almeno un World. La
copia e la replicazione consentono di posizionarla in luoghi diversi. Mentre la
duplicazione garantisce l’uguaglianza degli Stuff fino all’istante antecedente
la prima modifica, la replicazione garantisce l’identità degli Stuff, a meno dei
tempi di latenza del meccanismo di sincronizzazione.
L’utente che crea uno Stuff, tramite il suo Avatar, ne determina la proprietà
e ne assume il ruolo di amministratore. Il proprietario è l’unico che
può effettuare la cancellazione. Nel caso di repliche, cancellare significa eliminarle
tutte, mentre nel caso di copie, essendo tra loro indipendenti, significa
eliminarne solamente una.
Come già discusso, l’Avatar appartiene ad almeno un Group, quindi tutti
gli affiliati al gruppo, salvo diversa indicazione, ottengono stessi diritti e
responsabilità sullo Stuff.
L’apertura e la chiusura determinano l’acquisizione e il rilascio della risorsa.
In questo intervallo di tempo si parla anche di apertura e chiusura
della sessione che si possono classificare in base ai vari gradi di lock. L’accesso
dovrà essere regolato da meccanismi di sicurezza che verificheranno gli
effettivi privilegi dell’utente in modo analogo a quanto previsto per i World.
5.1.3 Structure Layer
Questo livello si occupa della gestione del versioning dell’informazione
secondo i principi descritti nel paragrafo 4.4 a pagina 91. Trattandosi del
principale argomento di interesse nel presente lavoro di tesi questo livello
verrà descritto dettagliatamente nel capitolo 6.
5.1.4 Replica Management Layer
Il livello Replica Management è specializzato nella gestione delle sorgenti e
delle destinazioni eterogenee dei dati, ospitate nel Medium Dependent Layer.
112

Architettura CISA Visione stratificata di CISA
Replicare un’entità significa copiarla in differenti host e mantenere le copie
equivalenti nel tempo. Le repliche delle informazioni, che sono identificate
attraverso i PRI, sono indirizzate tramite gli URL [BLMM94], in quanto la
logica dello strato ha bisogno di accedere a delle risorse concrete e pertanto
è presente un opportuno meccanismo di risoluzione (LS, capitolo 8).
I compiti di questo livello riguardano:
• la sincronizzazione delle repliche;
• la conversione dei formati dei dati
(ad esempio database↔database, database↔file system).
A questo livello deve essere garantita la consistenza delle repliche. I vantaggi
della tecnica active, nota anche col nome di state-machine approach,
sono evidenziati in [CM03]. Una volta stabilito qual è la replica di riferimento,
indicata col nome di replica master, tutti gli accessi distruttivi, ovvero
quelli che attuano modifiche di qualsiasi entità ai dati, confluiscono in essa.
In pratica tutte le operazioni di modifica vengono effettuate prima sulla
replica master e successivamente applicate alle repliche secondarie; questa
modalità operativa permette di gestire la concorrenza negli accessi distruttivi
attraverso un opportuno meccanismo di lock.
Le repliche si possono trovare nello stato di lock o unlock, che indica se
sulle repliche è stata o meno aperta una sessione di scrittura. Acquisire una
replica significa acquisire tutte le repliche. Per le operazioni di lettura non
è necessario il meccanismo di lock anche se durante una sessione tutte le
operazioni di scrittura e/o di lettura effettuate, avvengono in modo atomico.
La scelta della replica master può essere fissata a priori oppure effettuata
con opportuni algoritmi distribuiti di elezione che possono tenere in
considerazione vari parametri di costo (eventualmente pesati) come ad esempio
il carico di richieste dei nodi, la distanza geografica rispetto al sistema
autoritativo, la posizione nella topologia della rete.
Il principale servizio che Replica Management Layer offre al livello Structure
è la “valorizzazione” cioè la ricerca, l’acquisizione, la conversione e la
memorizzazione dei valori. In generale le informazioni relative allo stato sono
memorizzate in un qualsiasi host. Il livello Replica Management decide il
sito da cui prelevare o su cui scrivere le informazioni in base all’URL della
replica, realizzando una sorta di instradamento delle richieste.
Gli obiettivi del servizio di gestione delle repliche (vedi [CM03]) consistono
nell’aumentare:
113

Architettura CISA Visione stratificata di CISA
• la disponibilità del sistema;
• la velocità di risposta del sistema;
• la tolleranza ai guasti.
Per quanto riguarda gli accessi non distruttivi (di sola lettura), la gestione
mira a distribuire le richieste verso le repliche in modo da ridurre i singoli
carichi di elaborazione, che altrimenti sarebbero concentrati verso un esiguo
gruppo di host con un conseguente tempo di attesa eccessivo nelle code di
accesso. Inoltre distribuendo geograficamente ed opportunamente le repliche
si riducono anche i tempi di latenza.
Nel caso in cui non sia necessario avere un elevato awareness di alto livello
(questo concetto è stato affrontato in precedenza e non è legato al sistema di
replicazione, bensì al lavoro concorrente, capitolo 1) è possibile accedere alla
replica in modo non distruttivo beneficiando dei vantaggi menzionati. Questa
ipotesi si verifica nella maggior parte degli accessi in lettura che rappresentano,
ragionevolmente, una buona percentuale delle operazioni complessive
effettuate sulla replica.
Viceversa, nel caso in cui sia necessario avere awareness di alto livello,
occorre interagire sistematicamente con le repliche in scrittura per contrassegnarle
in qualche forma in modo da ottenere l’awareness voluto.
Infine le repliche possono essere viste come copie di backup capaci di
rimpiazzare attivamente le omologhe guaste.
Gli obiettivi esposti hanno però dei costi in termini di:
1. complessità dell’implementazione. In relazione alle politiche ed ai protocolli,
l’implementazione di un sistema per la gestione delle repliche
può essere un compito costoso;
2. amministrazione. Deve essere deciso quali risorse replicare e dove le
repliche devono essere memorizzate;
3. comunicazione aggiuntiva. Dipendentemente dal protocollo usato per
mantenere aggiornate le repliche, il costo della comunicazione di risorse
replicate è superiore rispetto all’accesso ad un sistema non replicato;
4. spazio disponibile. Ovviamente più repliche occupano uno spazio superiore
rispetto a quello usato per una singola replica.
114

Architettura CISA CISA, sistema distribuito
Il problema maggiore è certamente la complessità, che d’altra parte è
insita nel modello stesso, visti gli obiettivi di ordine generale di CISA. I costi
dovuti alla ridondanza sono ammortizzati dal vantaggio di una maggiore
affidabilità. Inoltre essendo proporzionali al costo dei dispositivi di memorizzazione
di massa, come è noto, sono soggetti nel tempo alla diminuzione
di prezzo.
5.1.5 Medium Dependent Layer
Il Medium Dependent Layer può modellare un file system, un database,
un protocollo che agisce per il trasposto dei dati o anche un Legacy System.
Si distinguono due categorie di dati: dati locali e dati remoti. I dati locali
possono essere repliche di dati remoti mantenuti in cache.
I dati locali. Sono suddivisi in dati di responsabilità dell’amministratore
e repliche di dati, di responsabilità di un’altra organizzazione, ottenuti con
la comunicazione.
I dati remoti. Sono ottenuti con un protocollo di trasporto. Una volta
acquisti vengono replicati in una cache locale. L’uso di Internet e di protocolli
applicativi è estremamente indicato in quanto sono un sistema pervasivo,
disponibile su tutto il territorio (o quasi). Inoltre in molte aree il livello
collegamento ha alte prestazioni in termini di banda.
5.2 CISA, sistema distribuito
L’architettura CISA è un sistema complesso suddiviso per convenienza
in livelli distinti. Le descrizioni delle funzionalità di tali layer, effettuate nel
paragrafo precedente, evidenziano come essi stessi siano sistemi complessi e,
in alcuni casi, ulteriormente scomponibili in sistemi più elementari. Senza
entrare nel dettaglio dei layer Application e Medium Dependent, la figura 5.3
evidenzia come il compito del Virtual Repository Layer sia espletato da tre
sistemi distinti: un sistema Virtual Repository, che gestisce la logica di controllo
e le funzioni specifiche del livello e due sistemi ausiliari, State e LDNS,
utilizzati dal sistema Virtual Repository per il controllo della validità dei
documenti e la risoluzione dei nomi da LRI a PRI rispettivamente. Allo stesso
modo Replica Management Layer è scomposto in due entità separate in
115

Architettura CISA CISA, sistema distribuito
quanto il servizio di risoluzione dei nomi (da PRI ad URL) è espletato da un
sistema indipendente, nello specifico da LS.
Application Layer
Virtual Repository Layer
Structure Layer
Replica Management
Layer
Medium Dependent
Layer
State
Replica
Management
Application
Virtual
Repository
Structure
LS
Medium Dependent
LDNS
Control Plane
Application Layer
Inter Layer Controller
Figura 5.3: La pila CISA più nel dettaglio.
Infine è necessario prevedere l’esistenza di un piano di controllo (Control
Plane) trasversale all’architettura necessario per l’amministrazione, il monitoraggio
e la gestione del sistema. Il piano di controllo sarà brevemente
descritto nel paragrafo seguente.
5.2.1 Control Plane
Il piano di controllo serve per definire gli scopi e le modalità di funzionamento
dei livelli dell’architettura.
Il controllo dei layer può essere attuato agendo attraverso un livello applicativo
che si occupa anche di presentare in modo amichevole i possibili
settaggi degli attuatori della QoS. La logica di controllo permette di agire
su alcuni livelli CISA, così come uno di tali livelli può richiedere servizi al
Control Plane.
La possibilità di intervenire su alcuni piani in modo diretto, indipendentemente
dal comportamento degli altri layer, consente attività di amministrazione,
manutenzione e configurazione, che qualsiasi sistema reale prevede.
Ad esempio parametri di funzionamento quali quelli relativi alle regole per la
116

Architettura CISA Definizione di livelli, servizi e processi
distribuzione delle repliche, al comportamento delle versioni e delle informazioni
possono essere monitorati e controllati direttamente attraverso questo
piano.
Il Control Plane permette di agire e monitorare i vari layer secondo una
politica, entro certi limiti, centralizzata. Questo può essere utile per permettere
agli amministratori dei sistemi che costituiscono CISA (sicuramente
è utile nella fase di debug dell’architettura) di monitorarli e controllarne il
funzionamento nel loro insieme. In altre parole gli amministratori, grazie al
Control Plane, hanno una visione globale del funzionamento dell’architettura.
Ad esempio se ad un sistema arriva una richiesta corrotta o malformata
gli amministratori possono individuare il sistema specifico che, fra quelli
che hanno partecipando all’elaborazione di tale richiesta, non ha operato
correttamente.
Infine è prevista un’interfaccia per il salvataggio degli eventi che può essere
utilizzata dagli altri sistemi per memorizzare i dati di log su un server
remoto e centralizzato. In realtà, essendo il sistema distribuito, è possibile
parlare di centralizzazione solo su scala locale in quanto il piano di controllo
è strettamente correlato con la figura dell’amministratore di sistema che ha
la funzione di gestire tutte le problematiche legate ad un numero finito e ben
determinato di apparati CISA. Come esempio si può pensare ai dispositivi
di proprietà di una data organizzazione che delega uno o più amministratori
ad occuparsi della relativa gestione. I dispositivi appartenenti ad altre
organizzazioni non rientrano, ovviamente, nel gruppo di sistemi su cui i suddetti
amministratori hanno autorità ed è per questo motivo che si parla di
centralizzazione su scala locale.
Il sottosistema finalizzato alla gestione dei dati di log può essere utilizzato
per un altro scopo, può essere utile infatti per interagire attivamente,
ad esempio in fase di debug del sistema, con le varie componenti che lo
costituiscono sulla base degli eventi che esse stesse notificano al piano di
controllo.
5.3 Definizione di livelli, servizi e processi
CISA è un’architettura distribuita ovvero un insieme di entità di elaborazione
connesse tramite una rete di comunicazione.
La rete di comunicazione fa parte quindi dell’infrastruttura di base uti-
117

Architettura CISA Definizione di livelli, servizi e processi
lizzata da CISA per il proprio funzionamento, infatti ogni apparato proprio
di CISA è un sistema di livello applicativo della pila ISO/OSI.
In questo scenario è possibile utilizzare anche la nomenclatura relativa
all’ingegneria del software, che opera per definizione al livello applicativo
OSI, e ricorrere al termine tier per fare riferimento ai layer CISA.
Data la complessità del sistema e la moltitudine di elementi in gioco è
necessario introdurre delle convenzioni relative alla nomenclatura utilizzata
in modo da evitare spiacevoli incomprensioni.
Parlando di layer (livello, tier o strato) viene fatto riferimento alle entità
illustrate nei paragrafi precedenti: Application Layer, Virtual Repository
Layer, Structure Layer, Replica Management Layer e Medium Dependent
Layer. Queste entità sono definite ad un livello di astrazione massimo e non
è possibile delinearle come entità individuali all’interno dell’architettura di
rete.
In riferimento all’architettura di rete è più opportuno parlare di servizio
dotato di uno o più punti di accesso. Escludendo il layer applicativo sul quale
viene lasciata la massima libertà, le tipologie di servizio possibili e le relative
interfacce, che sono state definite in CISA seguendo la filosofia REST, sono in
numero limitato e definito a priori. In modo particolare è possibile inquadrare
ogni livello CISA come fornitore, verso il livello superiore, di un servizio ben
determinato.
Con servizio si intende un sistema software costituito da un insieme di
entità equivalenti fra loro (processi) che operano, individualmente o in collaborazione,
per svolgere lo stesso tipo di attività. Il concetto di equivalenza è
relativo alla mansione svolta e non alle modalità con cui il singolo processo
opera; esiste quindi un protocollo che, tramite un’interfaccia ben definita e
comune a tutte le entità, permette di usufruire del servizio offerto. La risoluzione
degli hostname in indirizzi IP di Internet, effettuata dal DNS (Domain
Name System), è un esempio di servizio fornito da un insieme di entità, i
server dei nomi, che operano in collaborazione [KR03].
In CISA le entità appena introdotte sono processi ovvero programmi in
esecuzione [TW97] su host di rete (computer fisici o macchine virtuali). L’accezione
a cui si fa riferimento è quella utilizzata nel contesto dei sistemi operativi.
Inoltre tali processi, per poter erogare dei servizi all’esterno, devono
essere individuabili in rete tramite indirizzi di livello applicativo di OSI 1 e
1 In riferimento a reti basate sullo stack TCP/IP è possibile fare riferimento a coppie
“IP:PORTA”.
118

Architettura CISA Definizione di livelli, servizi e processi
pertanto si può parlare di processi in esecuzione su host.
L’architettura più semplice in grado di fornire un servizio è costituita da
un singolo processo ospitato in un host, ma generalmente un servizio viene
fornito da un cospicuo insieme di processi distinti.
Per quanto riguarda i servizi che sono forniti da due o più processi si
hanno le seguenti possibilità:
• i processi coinvolti nella fornitura del servizio sono indipendenti. Questo
è il caso ideale che garantisce il grado di parallelismo massimo in quanto
ogni processo riesce ad espletare tutte le richieste che gli vengono inoltrate
senza dover chiamare in causa altri processi ad esso equivalenti.
Le prestazioni del servizio scalano linearmente con il numero di processi
che lo erogano e questa è la situazione ideale. Esempi di questo tipo
sono Application Service, Virtual Repository Service, Structure Service
e State Service;
• i processi coinvolti nella fornitura del servizio sono non indipendenti.
In questo caso esiste una correlazione fra i processi in gioco, questo
significa che per espletare le richieste che vengono inoltrate ad uno di
essi potrebbe sorgere la necessità di chiamarne in causa altri. In questo
caso non è possibile fare ipotesi sulla scalabilità in quanto dipende dal
grado di accoppiamento che non è noto a priori. Esempi di questo tipo
sono LS Service e LDNS Service che sono costituiti da una griglia di
processi che collaborano l’uno con l’altro per poter rispondere a richieste
di risoluzione rivolte ad uno qualunque di essi. Il problema della
risoluzione viene affrontato nel capitolo 8; per quanto riguarda la scalabilità,
in questo caso specifico, è possibile anticipare che è equiparabile
a quella dimostrata sul campo da DNS in quanto LS ed LDNS operano
secondo gli stessi principi.
Per i livelli più bassi l’analisi si complica in quanto ci si scontra col fatto
che i dati hanno un responsabile (come persona fisica o come organizzazione)
e sono replicati fisicamente un numero di volte indipendente dal numero
di host che operano a livello Replica Management e Medium Dependent.
In ogni caso al crescere delle quantità dei dati il sistema scala linearmente
aumentando il numero di apparati 2 .
2 In questo caso parlare di processo risulta riduttivo in quanto occorre considerare che
i dati devono essere memorizzati su un qualche supporto fisico.
119

Architettura CISA Definizione di livelli, servizi e processi
I problemi sorgono fissando l’attenzione su un ben particolare dato e
volendo analizzare la scalabilità del sistema al crescere degli utenti interessati
ad esso. In questo caso, trattando l’accesso in sola lettura, il sistema scala
proporzionalmente al numero di repliche del dato (che in ogni caso condiziona
il numero di apparati).
Per quanto riguarda le scritture l’ipotesi di esistenza di un unico responsabile
(che deve garantire la correttezza delle informazioni) è un requisito
che porta ad ipotizzare che il numero di utenti da esso autorizzati ad operare
sull’informazione stessa sia limitato al fine di mantenere un controllo sufficiente
su di essa. Quindi questo aspetto rientra nella scelta delle politiche di
gestione dei diritti di accesso all’informazione, ma, a seguito di una fase di
analisi effettuata sul contesto applicativo nel quale il sistema dovrà operare
(vedi [Inn04]) e considerando che le politiche di gestione di scrittura sui dati
sono possibilmente ottimistiche (vedi sotto paragrafo 1.2.4, a pagina 17), la
scalabilità anche in questo caso non dovrebbe rappresentare un problema.
In figura 5.4 vengono riportate le relazioni esistenti tra livelli, servizi e
processi che costituiscono il sistema CISA. Due processi hanno la possibilità
di comunicare se i relativi servizi sono collegati tramite una freccia. In particolare
la direzione della freccia indica in quale verso si sviluppa la richiesta:
l’elemento dal quale essa parte è il richiedente del servizio ovvero il client,
mentre quello nel quale essa termina è il fornitore del servizio ovvero il server.
La figura 5.4 evidenzia anche altri aspetti: in particolare è possibile osservare
che esistono processi che forniscono servizi ad altri processi, rappresentati
tramite il case di un server, e processi che forniscono servizi all’uomo
attraverso un’interfaccia utente, rappresentati tramite un personal computer
dotato di monitor e tastiera. Tenendo conto di questa convenzione grafica
è possibile osservare come tutti i processi in gioco offrano servizi ad altri
processi rispettando i vincoli imposti dal modello stratificato presentato nel
paragrafo 5.1, ad eccezione di quelli appartenenti ad Application Layer e, almeno
in parte, di quelli presenti nel Control Layer. Questo aspetto, insieme
al fatto che Control Layer può agire su altri processi oppure essere fornitore
di servizi ad altri processi, ne evidenzia la doppia natura:
• attiva (per quanto riguarda la possibilità di intervenire su altre entità);
• passiva (per quanto riguarda la capacità di fornire un sistema di memorizzazione
degli eventi).
Infine è possibile distinguere i servizi che vengono espletati da processi
120

Architettura CISA Definizione di livelli, servizi e processi
Application
Layer
Virtual
Repository
Layer
Structure
Layer
Replica
Management
Layer
Medium
Dependent
Layer
Application
Type 1
Virtual
Repository
Service
Structure
Service
Replica
Management
Service
Medium
Dependent
Service
...
Legenda: tipologie di processi
Processo dotato di
interfaccia utente
Application
Type N
LDNS
Service
State
Service
LS
Service
Processo privo di
interfaccia utente
Figura 5.4: Livelli, servizi e processi.
Control
Plane
Control
Service
indipendenti e non indipendenti. In particolare quelli non indipendenti sono
messi in risalto da una interconnessione di rete (nello specifico LDNS Service,
LS Service e Replica Management Service), gli altri sono isolati ad indicare
121

Architettura CISA Definizione di livelli, servizi e processi
la loro indipendenza e che agiscono, quindi, in autonomia.
Di seguito, facendo sempre riferimento alla figura 5.4, vengono brevemente
descritti i servizi presenti nell’architettura, suddivisi per layer di appartenenza.
Application Layer. Il livello applicativo fornisce servizi direttamente all’utente.
I servizi forniti possono essere di vario tipo e CISA non entra nel
merito della loro definizione. Quindi, in riferimento alla figura, Application
Type X (con X compreso fra 1 ed N) rappresenta una specifica applicazione
CISA con la quale l’utente interagisce ideata per svolgere una particolare funzione.
Il concetto di servizio in questo caso, data la generalità del problema
e il fatto che è l’utente ad essere il fruitore dello stesso, è da considerarsi di
più ampio spettro e più astratto e gli scenari che possono essere realizzati
sono i più diversificati.
In generale Application Layer può essere modellato come sistema ulteriormente
stratificato e suddiviso in tre livelli, riportati di seguito dal più alto al
più basso:
• presentazione: gestisce l’interazione con l’utente sia per quanto riguarda
la visualizzazione che l’acquisizione dei dati;
• elaborazione: implementa gli algoritmi per l’elaborazione dei dati e per
la gestione del funzionamento della specifica applicazione;
• interfaccia: si occupa della comunicazione fra l’applicazione e Virtual
Repository.
Il seguente esempio è sicuramente utile per chiarire questa scenario. Si
pensi ad una situazione, estremamente semplificata rispetto al caso reale,
nella quale un libero professionista si rivolge al proprio commercialista per la
compilazione del modello annuale di dichiarazione IVA [dedF06]. Il software
del commercialista, di livello Application di CISA, è dotato di un’interfaccia
utente (individuabile nel contesto del layer di presentazione) attraverso la
quale l’utilizzatore può effettuare:
• l’inserimento e la visualizzazione dei dati dei clienti;
• l’inserimento e la visualizzazione delle fatture;
• la richiesta del calcolo dei dati necessari alla compilazione del modello
di dichiarazione IVA.
122

Architettura CISA Definizione di livelli, servizi e processi
Per quanto riguarda i primi due punti il layer di elaborazione può essere considerato
del tutto trasparente in quanto sia i dati dei clienti che le fatture
sono informazioni agevolmente mappabili in documenti D3IM. A seguito dell’inserimento
o della richiesta di visualizzazione di questo tipo di informazioni
(da parte del commercialista) il layer Application si interfaccia con Virtual
Repository per il salvataggio o l’accesso ad esse come richiesto.
Il calcolo delle parametri necessari alla compilazione del modulo è un’operazione
più complessa e in questo caso entra in gioco il layer di elaborazione:
l’algoritmo richiede a Virtual Repository tutti i documenti necessari relativi
al cliente e tutte le sue fatture (dell’anno fiscale di interesse). Sulla base di
questi dati calcola i valori da inserire nel modello come richiesto, applicando
i criteri stabiliti dalla Agenzia delle Entrate.
Si noti come in un ambiente totalmente distribuito l’Agenzia delle Entrate
avrebbe potuto accedere direttamente ai dati relativi al libero professionista
(eventualmente immessi dal commercialista) per il calcolo delle tasse (nello
specifico l’IVA) senza la necessità di obbligare il cittadino a compilare alcun
modulo come avviene attualmente.
Questo esempio mette in luce che gli scenari possibili sono innumerevoli e
pertanto le soluzioni tecniche che possono presentarsi nelle fasi di analisi e di
progettazione del layer Application possono essere estremamente diversificate.
In riferimento alla figura si pensi, ad esempio, all’Application Type N che
potrebbe essere un’applicazione a 2-tier basata su interfaccia web: in questo
caso esistono svariati processi che interagiscono direttamente con l’utente (i
web browser) e uno o più processi, sicuramente diversi sotto ogni punto di
vista dai precedenti, che costituiscono l’Application Server. In questo caso il
client utente interagisce in HTTP con l’Application Server ed è l’Application
Server a richiedere servizi a Virtual Repository. Viceversa l’Application Type
1 potrebbe essere un’applicazione con interfaccia grafica integrata: ogni utente
ha un’istanza dell’applicazione completa, operante sul proprio terminale,
la quale comunica direttamente con Virtual Repository.
Virtual Repository Layer. A questo livello si localizzano tre servizi
distinti:
• Virtual Repository Service, svolge tutte le funzionalità previste dal Livello
Virtual Repository ad eccezione della risoluzione da nomi logici (LRI)
in nomi persistenti (PRI) e della validazione dell’informazione;
123

Architettura CISA Definizione di livelli, servizi e processi
• LDNS Service, effettua la risoluzione da LRI in PRI;
• State Service, effettua la validazione dell’informazione.
Structure Layer. Il livello Structure ospita al proprio interno un solo tipo
di servizio: Structure Service. Questo servizio copre tutte le funzionalità
fornite dal livello CISA in esame.
Replica Management Layer. A questo livello si localizzano due servizi
distinti:
• Replica Management Service, svolge tutte le funzionalità previste nel
Replica Management Layer ad eccezione della risoluzione da nomi persistenti
(PRI) in URL. Dipendentemente dal protocollo e dalla politica
utilizzata per la gestione delle repliche potrebbe esistere un certo accoppiamento
fra tali processi. Le metodologie possibili sono infatti
due:
– si ricorre ad un meccanismo di delega attraverso cui il processo al
quale è stata effettuata la richiesta di servizio (accesso o modifica
di un dato) contatta il processo responsabile del dato che può valutare
se soddisfare o meno la richiesta. Questa è la situazione a cui
è stato fatto riferimento precedentemente che determina l’instaurarsi
dell’accoppiamento. Il vantaggio di questa soluzione consiste
nel fatto che il responsabile del dato, visto come informazione
astratta (identificata da un PRI, nome persistente ed univoco), ne
detiene direttamente il controllo per quel che riguarda la gestione
delle politiche di accesso. Si osservi che parlare di una particolare
replica di tale dato è un concetto diverso;
– si ipotizza che il processo al quale è stata effettuata la richiesta
di servizio acceda autonomamente al processo di livello Medium
Dependent che detiene la particolare replica in esame. Questo tipo
di interazione fra processi appartenenti a layer adiacenti verrà
discusso in modo più approfondito successivamente, parlando dell’architettura
di rete di CISA e, più nello specifico, di multiplexing
e demultiplexing (paragrafo 9.1.1) in CISA.
Allo stato attuale dell’evoluzione del progetto non è possibile effettuare
la scelta della strategia da utilizzare in quanto non è possibile stimare
124

Architettura CISA Definizione di livelli, servizi e processi
quali risvolti pratici comportino i vantaggi e gli svantaggi evidenziati.
Pertanto questo aspetto sarà da trattare negli sviluppi futuri.
• LS Service, effettua la risoluzione da PRI in URL.
Medium Dependent Layer. Medium Dependent Service fornisce al Livello
Replica Management un’interfaccia unificata per l’accesso fisico ai dati. I
processi che operano con questa finalità possono essere di vario tipo in quanto
i dati possono essere memorizzati in varie forme (file system, database, etc.)
e conseguentemente il relativo accesso può essere effettuato secondo criteri
diversi. Inoltre esiste la necessità di garantire la compatibilità verso i sistemi
legacy pertanto occorre prevedere l’esistenza di un meccanismo di “traduzione”
che permetta di convertire le informazioni in un formato unificato
interpretabile senza ambiguità dagli strati superiori.
Control Plane. Il Control Plane è stato descritto nel sotto paragrafo 5.2.1.
In questa sede è utile evidenziare che è un aggregato di servizi diversificati (in
figura, Control Services) che operano per le finalità riportate precedentemente.
Alcuni di questi servizi hanno un’interfaccia utente (ad esempio è possibile
ipotizzare l’esistenza di specifici tool di amministrazione), altri ne sono privi
(ad esempio, escludendo l’aspetto attivo che potrebbe richiedere l’intervento
umano, l’infrastruttura di logging).
125

Capitolo
6
Versioning in CISA
L’architettura CISA è stata progettata applicando la separation of concern
cercando di massimizzarne i benefici e, a tal fine, sono stati individuati
alcuni livelli che espletano vari servizi, ognuno dei quali si occupa di un
compito ben determinato e definito.
L’architettura è stata introdotta nel capitolo 5 nel quale sono stati illustrati
i principali sistemi e sottosistemi che la costituiscono con una descrizione
delle loro funzionalità. L’unico layer che è stato trascurato è Structure. Il
motivo di questa scelta è legato al fatto che Structure si occupa del versioning
dell’informazione, argomento di maggior interesse nel presente lavoro di tesi
e pertanto affrontato dettagliatamente in questo capitolo e nel successivo i
quali ne evidenziano i dettagli progettuali.
Si ricorda che il versioning è un’operazione finalizzata al mantenimento ed
alla gestione dell’evoluzione temporale dell’informazione e, nel caso specifico,
il layer Structure implementa le funzionalità relative al versioning previste
nel modello di documento D3IM, descritto nel capitolo 4.
D3IM è stato definito con la finalità di ottenere un modello per i dati
il più vantaggioso possibile nel contesto di sistemi finalizzati per il lavoro
collaborativo.
I concetti di cooperazione, di versioning e la descrizione di alcuni siste-

Versioning in CISA Da D3IM al versioning in CISA
mi esistenti finalizzati al lavoro collaborativo sono stati trattati in modo
approfondito nei capitoli 1 e 2.
6.1 Da D3IM al versioning in CISA
Il modello dell’informazione D3IM è stato progettato ispirandosi al modello
di documento di UEVM (paragrafo 2.4 a pagina 33) con la finalità di
applicare gli stessi principi relativamente al versioning delle informazioni.
Si ricorda che UEVM è un modello che permette di gestire le versioni di
documenti strutturati ad albero con la particolarità di riuscire a versionare
anche gli aspetti strutturali. In altre parole il documento è visto come una
“istantanea” delle informazioni sia per quel che riguarda il loro contenuto che
per le relazioni esistenti fra di esse. UEVM quindi applica il versioning alle
configurazioni (paragrafo 1.3 a pagina 18) del documento.
Il fatto che UEVM si limiti a gestire documenti strutturati ad albero
deriva dal considerare l’informazione come entità individuale: il documento.
In UEVM due documenti diversi sono entità distinte e completamente
scorrelate.
In D3IM viceversa l’informazione è distribuita e una delle caratteristiche
di maggior rilievo del modello è proprio la condivisione delle conoscenza fra
soggetti (e documenti) diversi. Il documento in D3IM è considerato come
l’aggregazione di informazioni distribuite.
Questo porta ad una struttura più generale rispetto a quella ad albero in
quanto la condivisione di un’informazione fra due documenti distinti genera
un DAG: si hanno due alberi parzialmente sovrapposti e l’intersezione è data
esattamente dal sotto albero che rappresenta l’informazione condivisa. Generalizzando,
lo stesso risultato si ottiene anche nel caso della condivisione
di un’informazione da parte di N documenti, con N arbitrario.
Da questa considerazione si deduce che le generiche relazioni fra nodi
D3IM portano ad avere un DAG. Per questo motivo, e comunque per avere
maggiore flessibilità nella modellazione dell’informazione, in D3IM si parla
di DAG anche limitatamente al contesto del singolo documento.
Infine il modello di documento di UEVM tiene conto esclusivamente delle
informazioni e delle loro relazioni strutturali con la finalità di versionarle.
D3IM prende in considerazione anche altre problematiche come il concetto
di responsabilità e di stato dell’informazione, dello spazio dei nomi, eccete-
127

Versioning in CISA Lo storico in CISA
ra, aspetti che non risultano di fondamentale importanza nel contesto del
versioning e pertanto non verranno trattati in questo ambito.
6.2 Lo storico in CISA
Il servizio di gestione del versioning (o dello storico) di un documento,
secondo le specifiche stabilite nel modello D3IM, viene fornito integralmente
ed esclusivamente dal layer Structure di CISA. Quindi, in riferimento a
Structure, è possibile parlare equivalentemente di layer o di servizio (a patto
di assegnare ad ogni termine il giusto significato concettuale) in quanto non
vi è rischio di ambiguità.
Per poter introdurre, in modo dettagliato, quale sia il servizio che effettivamente
viene fornito da Structure, e come questo sia conforme alle specifiche
dettate da D3IM, è necessario evidenziare che i seguenti aspetti sono
indipendenti:
• la gestione dello storico del documento ovvero l’insieme di tutti quei
meccanismi necessari per la creazione, l’aggiornamento e il mantenimento
della consistenza dello stesso. Queste operazioni sono del tutto
interne al layer e le modalità operative secondo le quali vengono
espletate non riguardano i sistemi esterni;
• la navigazione nello storico del documento ovvero l’insieme di tutti quei
meccanismi finalizzati a fornire il servizio di indirizzamento all’informazione
versionata, in quanto deve essere possibile, per i livelli superiori,
“spostarsi” nello spazio delle versioni; in caso contrario l’importanza
dell’esistenza del versioning verrebbe del tutto vanificata.
6.2.1 La struttura dello storico
Prima di entrare nel merito di come il layer Structure implementi le specifiche
dettate dal modello D3IM è utile ricordare brevemente la nomenclatura
e i principi generali utilizzati nell’ambito del versioning.
Una configurazione è un’istantanea del sistema (documento), ad un certo
istante di tempo. Il paradigma di versioning utilizzato in CISA si applica alle
configurazioni: ogni modifica (tempo discreta 1 ) alla configurazione genera
1 Per poter considerare variazioni tempo continue, in questo contesto, è necessario
ricorrere ad opportune tecniche di campionamento.
128

Versioning in CISA Lo storico in CISA
una nuova revisione del documento. Con modifica si individua un’operazione
che comprende una o più variazioni all’interno della configurazione. L’entità
della modifica nel suo complesso è una grandezza che può essere gestita sia
dall’utente che in modo automatico dal sistema e dipende dall’entità e dal
numero delle singole variazioni elementari che la costituiscono.
L’insieme delle revisioni è una codifica dell’evoluzione temporale delle
configurazioni ed è quindi un insieme nel quale esiste un ordinamento totale:
date due revisioni ra e rb si ha che ra < rb oppure rb < ra oppure ra e rb
sono la stessa configurazione. Lo storico di un documento descritto in questi
termini è lineare ed è costituito dall’insieme delle sole revisioni.
Uno storico di questo tipo può essere sufficiente a modellare l’evoluzione
temporale di un’informazione, ma può non essere abbastanza flessibile da
favorire la cooperazione fra più utenti e, in generale, l’authoring su di essa in
modo concorrente.
Senza entrare nel merito della questione (già affrontata in dettaglio nei capitoli
1 e 2) è necessario poter creare esplicitamente delle diramazioni (branch)
all’interno dello storico per permettere lo sviluppo concorrente (quindi in
parallelo) su due o più rami indipendenti. Creare branch all’interno di uno
storico lineare porta ad avere una struttura dello storico ad albero. In questo
caso con revisione si intende una nuova versione di un elemento presente in
un determinato branch.
Infine può risultare necessario far convergere (operazione di merge) due
rami distinti su un unico ramo e così la struttura complessiva che si ottiene
è un DAG.
Il DAG permette quindi di rappresentare le relazioni fra un qualunque
insieme di versioni di un’informazione.
A tal riguardo può essere utile riferirsi nuovamente al paragrafo 2.1 e, in
particolare, alla figura 2.1 a pagina 25.
D3IM nel layer Structure
D3IM è un modello strutturato e prevede l’esistenza di due tipologie di
informazioni:
• primitive;
• atomiche.
129

Versioning in CISA Lo storico in CISA
Le informazioni atomiche vengono incapsulate in informazioni primitive:
solo queste ultime hanno un indirizzo univoco (PRI) e possono essere
associate ai nodi del DAG relativo al documento. Tali nodi contengono
quindi:
• le informazioni atomiche costituite da coppie “”, i dati
veri e propri definiti nei livelli superiori;
• i metadati definiti nei livelli superiori;
• le relazioni verso altri nodi, proprie delle informazioni primitive.
Per il livello Structure esistono quindi nodi al cui interno è possibile individuare
due sezioni distinte, che nascono a seguito del principio di imbustamento
presente in CISA in quanto architettura stratificata.
Tali nodi, rappresentati schematicamente in figura 6.1, sono costituiti da:
• un header, che contiene tutti i metadati necessari al mantenimento delle
relazioni definite a livello Structure;
• un body, nel quale Structure imbusta tutti i dati e i metadati che non
sono di sua competenza (ma di competenza dei livelli superiori).
Indirizzamento
PRI
Header Body
Dati e metadati di
competenza di Structure
Dati e metadati di competenza
dei livelli superiori
Figura 6.1: Nodi di livello Structure.
6.2.2 Relazioni fra nodi di livello Structure
Il DAG a cui è stato fatto riferimento nel sotto paragrafo 6.2.1 è ottenuto
andando a considerare le informazioni atomiche, le informazioni primitive e
i link di composizione definiti nel modello D3IM.
130

Versioning in CISA Lo storico in CISA
Si ricorda che D3IM definisce anche un altro tipo di relazione fra nodi che
è rappresentata dai link di riferimento. Tali link non hanno nessun legame
con la gestione delle versioni, sono infatti definiti ai livelli Application e
Virtual Repository ed essendo informazioni atomiche per Structure risultano
incorporate nel body.
In riferimento al modello D3IM, in corrispondenza dei link di composizione,
è necessario prevedere un meccanismo che permetta di propagare le
modifiche dei figli verso i genitori. Tale algoritmo rientra a pieno titolo fra le
mansioni legate alla gestione dello storico e pertanto deve essere definito ed
applicato nel contesto del layer Structure. Structure deve quindi prevedere
un secondo tipo di link, detto link di propagazione, che permetta di risalire
nella gerarchia dei nodi presenti nel dominio del documento per propagare le
versioni come richiesto dal modello D3IM.
In corrispondenza di tutti i link di composizione presenti nell’ultima revisione
di ogni branch di qualsiasi nodo, esistono i relativi link di propagazione
che hanno verso opposto.
Documento al tempo t 0
X1
P1 P2
C1 C2
Y1 Z1
Legenda: tipologie di link
Documento al tempo t 1
C1
Link di Propagazione
Link di Composizione
Link di Versione
X1
C2
P3
V2
C3
X2
C4
Y1 Y2 Z1
V1
Figura 6.2: Gestione dei link di propagazione.
Per chiarire questo concetto si faccia riferimento alla figura 6.2 nella quale
il documento al tempo t0 è costituito da una radice X1 che aggrega due figli
P4
131

Versioning in CISA Lo storico in CISA
Y1 e Z1 tramite opportuni link di composizione, rispettivamente C1 e C2.
Esistendo una sola revisione di ogni nodo a tali link di composizione vengono
associati i link di propagazione P1 e P2. Il documento al tempo t1 appare
dopo una modifica (in conformità al meccanismo previsto in D3IM) relativa
a Y e propagata alla radice X. In questo caso i link di propagazione P1 e P2
sono stati rimossi e sono stati inseriti P3 e P4 in corrispondenza dei link di
composizione C3 e C4 presenti nell’ultima revisione della radice X.
Infine esiste un terzo tipo di link, detto link di versione, che permette
di rappresentare le relazioni presenti fra nodi appartenenti allo storico di
una determinata informazione. Fanno parte di questa categoria i legami
esistenti fra una revisione e la successiva, una revisione e la precedente etc.
(tutte le tipologie di link che rientrano in questa categoria verranno introdotte
dettagliatamente nel paragrafo 7.2 a pagina 169). In figura 6.2 è presente un
esempio nel quale si ipotizza l’esistenza dei soli link di versione presenti dalla
revisione precedente a quella successiva.
La gestione integrale dei link di versione e di propagazione è indubbiamente
di competenza del livello Structure. Il discorso è diverso se si parla
dei link di composizione, in tal caso esiste una minima sovrapposizione delle
mansioni fra Virtual Repository e Structure.
Virtual Repository è responsabile della gestione degli aspetti strutturali
dei documenti. Questo significa che la definizione (ovvero la creazione), la
modifica, la cancellazione e la navigazione nello spazio delle relazioni che i
suddetti link definiscono sono operazioni di sua competenza.
Dall’altro lato c’è Structure che deve poter propagare le versioni dai figli
verso i genitori seguendo i link di propagazione. Prendendo l’esempio precedente
(figura 6.2), la nascita di una nuova versione del figlio (Y2) crea,
tramite il meccanismo di propagazione, una nuova versione del genitore (X2)
che deve essere connessa, tramite un link di composizione (C3), alla nuova
versione del figlio.
La creazione della nuova versione del genitore è a carico del layer Structure
il quale, per poter connettere tale elemento alla nuova versione del figlio, deve
essere in grado di manipolare i link di composizione (nell’esempio si tratta di
creare C3 e C4).
Si osservi che non esiste una reale violazione della separation of concern
in quanto le motivazioni che spingono i due layer ad agire sui link di
composizione sono diverse.
Inoltre, operando come descritto più avanti, non esiste neanche la viola-
132

Versioning in CISA Lo storico in CISA
zione dell’information hiding che si avrebbe permettendo ad entrambi i layer
di intervenire sulle relazioni strutturali. È infatti sufficiente affidare a Structure
l’onere di definire e gestire la struttura dati che permette di descrivere
le relazioni individuate dai link di composizione. In altre parole tali link vengono
gestiti esclusivamente da Structure e mantenuti all’interno dell’header
del nodo definito a questo livello. Inoltre è necessario corredare l’interfaccia,
fornita a Virtual Repository, di opportune primitive e/o definire il formato
dei messaggi scambiati fra i due livelli in modo da permettere a Virtual
Repository di agire, secondo le proprie necessità e competenze, sugli aspetti
strutturali del documento. Questo permette a Virtual Repository di inserire,
modificare ed eliminare i link di composizione in base alle proprie esigenze e
navigare nello spazio del documento che essi contribuiscono a definire.
Questo meccanismo è simile a quello presente in DOM: l’interfaccia messa
a disposizione permette all’utilizzatore di creare, modificare, cancellare e
navigare fra i nodi dell’albero del documento (nel caso in esame l’utilizzatore
è il livello Virtual Repository), mentre è la libreria in uso (che implementa
DOM) ad avere l’onere di gestire la logica interna della struttura e la codifica
delle relazioni fra nodi (in questo caso tale compito spetta a Structure).
6.2.3 Gestione delle revisioni: la propagazione
Nel modello D3IM le informazioni atomiche costituiscono l’insieme dei
dati contenuti nel documento. Essendo il documento strutturato, tali dati
sono messi in relazione tramite le informazioni primitive. La struttura è gerarchica:
i nodi che si trovano ai livelli più alti della gerarchia rappresentano,
da un punto di vista concettuale, il punto d’accesso all’informazione strutturata
che si sviluppa da essi fino alle foglie. Modificare uno qualunque dei nodi
appartenenti a tale gerarchia significa modificare l’informazione complessiva.
Considerando l’esempio di un libro, costituito da capitoli suddivisi a loro
volta in paragrafi che sono un insieme di frasi, modificare una frase significa
modificare il paragrafo che la contiene, ma anche il capitolo contenente il
paragrafo e, in ultima analisi, tutto il libro.
D3IM permette di modellare il comportamento descritto tramite il concetto
di propagazione che viene applicato sui genitori in corrispondenza della
nascita di una nuova revisione dei figli all’interno della gerarchia del documento.
Si osservi che la richiesta di salvataggio di una variazione del contenuto
133

Versioning in CISA Lo storico in CISA
di un nodo non genera necessariamente una nuova revisione. A tal riguardo
possono presentarsi due casi, che dipendono dal valore dello stato UPDATE
del nodo (paragrafo 4.4 a pagina 91):
• frozen: il sistema crea una nuova revisione del nodo ed avvia il meccanismo
di propagazione (viene creata una nuova revisione in quanto il
nodo di partenza è “congelato” e non può essere modificato);
• changing: il sistema sovrascrive il contenuto del nodo e non attua
nessuna propagazione.
Nel seguito di questa trattazione, se non espressamente specificato, si
assume che lo stato UPDATE valga “frozen”. Il motivo è dovuto al fatto
che in corrispondenza della nascita di una nuova revisione occorre comunque
apportare alcune variazioni (sovrascritture) alle strutture dati di competenza
di Structure, interne al nodo di partenza. Nel caso in cui il valore sia “frozen”
il salvataggio è infatti costituito dalle seguenti tre fasi:
1. creazione della nuova revisione;
2. modifica del contenuto della revisione precedente per l’aggiornamento
delle relazioni di versione;
3. esecuzione dell’algoritmo di propagazione verso i genitori.
Ognuna di queste fasi prevede la sovrascrittura (operazione equivalente al
caso in cui il valore sia “changing”) dei nodi interessati per applicare su di
essi le modifiche richieste. Per quanto riguarda il caso 1 la sovrascrittura
è necessaria per inserire il contenuto corretto nel nodo appena creato, negli
altri due casi serve per aggiornare i vari link in gioco.
Il meccanismo di propagazione è stato descritto nel paragrafo 2.4 (a pagina
33) nel quale è descritto il modello UEVM. Si noti, come osservato in
precedenza, che in questa sede, a differenza del caso preso in esame in UEVM,
la struttura di riferimento è un DAG e quindi ogni nodo può avere zero, uno
o più genitori (mentre in UEVM può avere al massimo un genitore in quanto
la struttura è un albero). Questo aspetto è ininfluente ai fini dell’algoritmo
di propagazione a patto di applicarlo a tutti i genitori presenti.
134

Versioning in CISA Lo storico in CISA
Propagazione “push” e propagazione “pull”
Il concetto di responsabile dell’informazione è legato alle politiche di
accesso all’informazione stessa che riguardano sia la lettura che la modifica.
Senza perdere in generalità si assume che:
• l’identificazione dell’utente avvenga contestualmente alla sua proiezione
nel sistema, ovvero tramite l’Avatar;
• il responsabile decida quali sono gli Avatar autorizzati ad accedere in
lettura o in scrittura ad una data informazione;
• sia presente un’infrastruttura finalizzata alla gestione degli aspetti legati
alla sicurezza operativa dell’architettura che permetta di associare
ogni azione (individuabile nel sistema) ad un Avatar.
Si consideri, per esempio, l’accesso ad un’informazione da parte di un
utente: questo, tramite il proprio Avatar A, fa pervenire la richiesta di lettura
a Virtual Repository. Conseguentemente si innescano tutti i meccanismi
necessari per il reperimento e la successiva presentazione dell’informazione
all’utente. Una delle operazioni che senz’altro viene effettuata riguarda l’accesso
fisico ad una delle repliche da parte di Replica Management. Si suppone
che il meccanismo di cui sopra sia in grado di associare all’Avatar A l’azione
di lettura che Replica Management si vede pervenire da Structure. Questa
associazione permette a Replica Management, ad esempio, di ricercare l’Avatar
A nella tabella degli utenti autorizzati ad accedere alla risorsa in modo
da poter stabilire se soddisfare o meno la richiesta 2 .
Alla luce di questa breve descrizione 3 , è possibile analizzare le due modalità
previste per il meccanismo di propagazione: push e pull. Si osservi che
queste non sono mutuamente esclusive: è possibile portare a termine l’aggiornamento
di tutti i nodi interessati dalla propagazione operando in parte
in modalità “push” e in parte in modalità “pull”.
2 La gestione delle identità e dei permessi sui nodi del documento è onere di Virtual Repository.
Si noti però che anche a livello Replica Management (ed eventualmente Medium
Dependent) devono essere previsti dei meccanismi di gestione di politiche per l’accesso
ai dati, che altrimenti potrebbero essere letti e/o modificati (in modo fraudolento) senza
possibilità di controllo.
3 In CISA gli aspetti legati alla sicurezza, alla gestione dei diritti, etc. sono in fase di
sviluppo e, nel presente contesto possono essere considerati fra le problematiche per le
quali la formalizzazione della soluzione viene rimandata a sviluppi futuri.
135

Versioning in CISA Lo storico in CISA
Push. L’algoritmo “push”, eseguito in modo centralizzato, aggiorna ogni
elemento presente nella gerarchia degli antenati del nodo (N) dal quale parte
il meccanismo di propagazione. Viene infatti eseguito integralmente dal
processo di livello Structure che riceve la richiesta di modifica di N per conto
dell’Avatar A che ha effettuato la richiesta.
Questa soluzione ha il vantaggio di essere la più semplice, ma ha almeno
due inconvenienti.
Il primo è relativo al fatto che l’Avatar A deve essere stato precedentemente
autorizzato ad intervenire su tutti i nodi della gerarchia. Questo
aspetto complica la procedura di aggregazione per composizione che deve
quindi prevedere una fase nella quale vengono concessi i diritti di modifica
(almeno degli aspetti strutturali) ai responsabili di tutti i documenti presenti
nella gerarchia.
Nell’esempio di figura 6.3 l’inserimento della nuova relazione di composizione
dal nodo H al nodo I deve essere accompagnato dall’aggiunta dei
responsabili B e C fra gli autorizzati alla modifica dei nodi, presenti nella
gerarchia, sotto la responsabilità di A (nello specifico i nodi G ed H).
Questa operazione è necessaria per permettere la propagazione. Ad esempio
la modifica del nodo N da parte di C deve poter essere propagata, a nome
di C, su tutta la gerarchia.
L’altro inconveniente riguarda la scalabilità del sistema. In questo caso
infatti il costo computazionale dell’algoritmo a carico di un singolo processo
aumenta linearmente con il numero di nodi che si trovano al di sopra di esso
nella gerarchia. Questo limita il numero di documenti che possono aggregare
per composizione una data informazione. Si ricorda comunque che l’aggregazione
per composizione è solo una delle due alternative: ai livelli superiori è
possibile gestire l’aggregazione per riferimento che, non coinvolgendo i meccanismi
di propagazione, non ha nessuno degli inconvenienti menzionati e
in molti casi può risultare più che sufficiente per modellare le relazioni esistenti
fra le informazioni (si pensi che i collegamenti fra pagine web presenti
nel WWW sono l’equivalente prototipale dei link di riferimento del modello
D3IM).
Pull. L’algoritmo “pull” prevede che l’aggiornamento degli elementi appartenenti
agli antenati del nodo N, da cui parte il meccanismo di propagazione,
venga effettuato dai relativi responsabili. La descrizione di questa modali-
136

Versioning in CISA Lo storico in CISA
G
Responsabile A
Relazione
Preesistente
N
M
Responsabile C
H
L
I
Nuova
relazione
Responsabile B
Figura 6.3: Concessione dei diritti di modifica a tutti i responsabili nella
gerarchia di successori.
tà operativa, che sotto certi aspetti permette di superare alcune limitazioni
della precedente, viene lasciata agli sviluppi futuri.
Il motivo di questa scelta è conseguenza del fatto che la modalità push è
comunque sufficiente per l’efficacia del sistema e per implementare la modalità
pull risulta necessario ricorrere al meccanismo di notifica introdotto nel
paragrafo 5.1 (a pagina 107) attualmente in fase di definizione.
Il principio di base è il seguente: il processo di layer Structure che riceve
la richiesta di modifica di N attua la propagazione in modalità push per ogni
antenato sul quale l’Avatar A ha autorità (in questo caso A è il responsabile
dell’informazione oppure è stato autorizzato dal responsabile ad operare su
di essa). Nel momento in cui, risalendo nella gerarchia, incontra un elemento
137

Versioning in CISA Lo storico in CISA
per il quale A non ha autorità il processo termina ed invia al responsabile
che ha autorità su di esso una notifica per segnalargli l’aggiornamento avvenuto.
Tale Avatar (o meglio un agente software che opera per suo conto) può
richiedere, secondo la modalità “pull”, la lettura dei nodi aggiornati e avviare
conseguentemente, tramite lo stesso o un altro processo di layer Structure, la
propagazione sui nodi di sua competenza. Questo meccanismo continua fino
al termine dell’aggiornamento di tutti gli antenati.
In riferimento all’esempio di figura 6.3 il processo di livello Structure,
al quale viene richiesto il salvataggio delle modifiche sul nodo N, effettua
la propagazione a M. Il responsabile dell’antenato di M (il nodo L) è B ed
è diverso da C, responsabile di M. Il processo di livello Structure non si
preoccupa quindi della propagazione verso L, ma si limita ad inoltrare una
notifica di aggiornamento al suo responsabile, B. L’Avatar di B, tramite un
opportuno agente, si preoccupa di aggiornare L dando vita ad un nuovo
meccanismo di propagazione che, nell’esempio, prosegue fino ad I. L’ulteriore
variazione di responsabile che si ha risalendo verso H dà vita ad una nuova
notifica verso A e l’algoritmo prosegue secondo la modalità descritta.
Si osservi come entrambi i problemi evidenziati con la modalità “push”
risultino risolti. Da un lato non è necessario “ereditare” i diritti in fase di aggregazione,
in quanto sarà l’Avatar del responsabile di ogni nodo a procedere
con la propagazione su di esso, dall’altro la scalabilità risulta effettivamente
più elevata poiché la propagazione globale avviene tramite l’esecuzione di un
algoritmo totalmente distribuito. Si osservi che, in questo caso, esiste un
rovescio della medaglia: il vantaggio ottenuto in termini di efficienza viene
pagato in termini di complessità nella definizione ed implementazione dell’algoritmo
e del protocollo di comunicazione a causa della maggiore difficoltà
che si incontra per garantirne l’efficacia.
6.2.4 Branching e merging
Le operazioni di branching e di merging risultano essere, da un punto di
vista logico, legate alla gestione dello storico di un documento e sono state
introdotte nel paragrafo 2.1 a pagina 24. Creare un branch può essere utile
per i motivi più disparati che variano in base al contesto. Quello che è certo
è che risulta necessario, parlando di versioning in senso lato, considerare i
branch e la loro gestione. Nella “gestione” rientrano le operazioni di creazione
138

Versioning in CISA Lo storico in CISA
dei branch, di navigazione dello storico, costituito da più rami di sviluppo
paralleli, ed ovviamente di convergenza (merge).
Nel momento in cui si crea un branch la gestione dell’evoluzione temporale
al suo interno risulta essere del tutto indipendente rispetto a quella relativa
al documento di provenienza.
Generare un branch equivale a creare un nuovo documento che abbia in
comune con quello di partenza almeno un nodo dello storico. In conclusione
all’interno di ogni branch esiste un ordinamento totale delle revisioni che modella
l’evoluzione temporale del documento (relativo a quel branch), inoltre
non esiste nessuna correlazione fra revisioni appartenenti a branch diversi, se
non quella di avere predecessori (nello storico) comuni.
L’equivalenza a cui è stato appena fatto riferimento fra branch e nuovo
documento non è soltanto concettuale, ma è stata sfruttata ampiamente nella
pratica in molti SCM (Software Configuration Management), fra i quali il già
citato Subversion, CVS, eccetera.
Per comprendere le scelte che hanno permesso di introdurre nel layer
Structure le operazioni di branch e di merge è sicuramente utile fare riferimento
a Subversion (paragrafo 2.8, pagina 53) che utilizza un modello di
versioning molto simile a quello definito in CISA (entrambi i modelli derivano
da UEVM).
Richiami di branching e merging in Subversion
In Subversion non è previsto un meccanismo esplicito per la gestione dei
branch, in particolare non esiste nessun comando o primitiva che ne permetta
la creazione. I branch vengono gestiti esplicitamente e consapevolmente
dall’utente tramite il comando di copia: nel momento in cui l’utente desidera
creare un branch effettua una copia del sotto albero del file system in cui
sono memorizzati tutti i file relativi alla configurazione a partire dalla quale
intende creare il nuovo branch.
Il manuale ufficiale di Subversion [CSFP04] consiglia, senza porre nessun
vincolo, di operare creando una directory nel repository per ogni progetto 4 ,
tale directory deve a sua volta contenere due sotto directory chiamate“trunk”
e “branches”.
4 Nel caso in esame è opportuno parlare di documento. In realtà, per semplificare, si
può supporre di creare un nuovo repository per ogni documento in modo da garantire
l’indipendenza degli storici.
139

Versioning in CISA Lo storico in CISA
documento1
trunk
file1
file2
branches
il_mio_branch
file1
file2
altro_branch
file1
file2
documento2
trunk
fileA
fileB
dir
branches
Figura 6.4: Organizzazione tipica di un progetto gestito con Subversion.
La prima di esse (“trunk”) contiene i file relativi al ramo principale, l’altra
(“branches”) tante sotto directory quanti sono i branch creati dall’utente.
In riferimento alla figura 6.4, per creare il branch il mio branch, relativo
all’intero progetto documento1, l’utente crea per prima cosa l’opportuna
directory in branches e successivamente copia in essa il contenuto di trunk.
L’operazione di copia deve essere effettuata agendo direttamente sul repository
tramite lo specifico comando di copia e non effettuando la copia dei singoli
file all’interno della directory di lavoro dell’utente. Tale comando permette
a Subversion di effettuare la copia e, allo stesso tempo, di far condividere lo
storico (fino all’istante precedente all’operazione) fra la sorgente e la destinazione
della copia stessa. È scorretto effettuare prima la copia all’interno
dell’area di lavoro dell’utente e successivamente il commit per aggiornare il
repository poiché in tal modo il sistema non riconosce i file copiati come legati
agli originali e verrebbero quindi considerati come nuove entità con un
proprio storico indipendente da quello della sorgente.
fileC
140

Versioning in CISA Lo storico in CISA
È buona regola infatti non effettuare il checkout 5 di tutto il progetto,
ma soltanto della directory contenente il branch di interesse in modo tale
da far figurare nell’area di lavoro dell’utente soltanto tale branch. In questo
modo non è possibile effettuare copie di file da un branch all’altro all’interno
dell’area di lavoro, neanche accidentalmente.
Per quanto riguarda il merging, il concetto di fusione di un branch in un
altro si ritrova in modo indiretto tramite il concetto di antenato. Il merging
è infatti un’operazione definita fra due directory distinte. Nel caso in cui
il contenuto delle due directory sia costituito da elementi che condividono
una parte dello storico (ovvero che sono stati creati tramite copia e quindi
associabili indirettamente al concetto di branch) il sistema li confronta nei
contenuti: per le directory significa operare ricorsivamente entrando al loro
interno, per i file significa compararli riga per riga.
Supponendo che uno sviluppatore che opera nel ramo principale crei un
file (o directory) con lo stesso nome e la stessa posizione relativa di quello
creato da un secondo sviluppatore che opera nel branch, i due file omonimi
vengono trattati, durante il merge, come entità distinte in quanto non condividono
nessun antenato nello storico e pertanto non vengono confrontati.
Il sistema avverte l’utente, che ha richiesto il merge, della presenza di un
conflitto senza risolverlo direttamente. Se questo comportamento, che permette
di capire che le due entità in esame appartengono a due branch diversi,
non è quello voluto è possibile inibire la verifica di parentela e in tal caso il
confronto avviene comunque.
Branching da D3IM a CISA
Per proseguire con l’analisi del problema è utile descrivere come potrebbe
essere implementato un clone di Subversion adattato come applicazione
basata sull’architettura CISA. Questo permette sia di comprendere meglio
i principi che hanno condotto alla definizione del branching (e del merging)
in CISA sia di mostrare come CISA risulti un’architettura flessibile e adattabile
(tramite la definizione di un opportuno livello applicativo) a svariati
contesti, uno dei quali potrebbe essere appunto lo sviluppo concorrente di
codice sorgente da parte di più programmatori (ambito nel quale si colloca
Subversion).
5 Si ricorda che l’operazione di checkout è quella che serve per effettuare una copia locale
(nell’area di lavoro dell’utente) di tutti o alcuni file presenti nel repository.
141

Versioning in CISA Lo storico in CISA
Per prima cosa occorre definire il modello per i dati: ogni progetto gestito
in Subversion può essere definito come documento D3IM, operando come
segue:
• i file e le directory in Subversion sono informazioni primitive in D3IM;
• il contenuto dei file in Subversion corrisponde alle informazioni atomiche
di D3IM.
Un file quindi è rappresentato da un’informazione primitiva che ne permette
l’identificazione e da un’informazione atomica che ne memorizza il
contenuto. Si osservi che è possibile rappresentare il file anche in modo più
dettagliato considerando il contenuto come entità strutturata (ad esempio,
per i file di testo, inserendo ogni riga del file in un’informazione atomica distinta
oppure, per il codice sorgente, andando a codificare in D3IM gli aspetti
strutturali in esso presenti).
I documenti così definiti sono strettamente strutturati ad albero in quanto
la loro struttura riflette quella del file system 6 e sono, a pieno titolo,
documenti D3IM validi.
Le operazioni di aggiunta, cancellazione o modifica di un file (o directory)
nel progetto equivalgono all’aggiunta, la cancellazione o la modifica di un
nodo dell’albero del documento. A seguito di tale azione risulta modificata
anche la directory che contiene il file (o directory) in esame: tale modifica
si propaga verso l’alto fino alla radice del progetto con lo stesso meccanismo
di propagazione presente in D3IM. Questo aspetto è evidente nella modalità
con cui Subversion assegna i numeri di versione. Tali numeri sono relativi al
progetto nella sua interezza e non alle singole parti che lo costituiscono.
A questo punto è possibile riprendere la descrizione della modalità operativa
di Subversion relativa al branching ed al merging ed applicarla al contesto
in esame. L’operazione di copia di uno o più elementi nel repository è tale
che l’elemento di origine e l’elemento di destinazione condividono lo stesso
storico fino al momento della copia. Il caso più semplice che può essere
ipotizzato è quello nel quale è presente una singola informazione primitiva
(la directory, vuota, radice del progetto). Creare un branch in questo caso
significa generare una diramazione dello storico di un nodo, figura 6.5.
6 In realtà, ricorrendo all’uso di link simbolici, è possibile creare strutture più complesse
(DAG) che non hanno interesse nella presente trattazione.
142

Versioning in CISA Lo storico in CISA
Storico dell'elemento
Storico condiviso
R1 R2 R3 R4
Copia o
Branch
R2.1 R2.2
Figura 6.5: Risultato della copia di un file in Subversion: branch in D3IM.
Deve essere quindi previsto un meccanismo che permetta di creare un
branch nello storico di un nodo al fine di considerarne tutta l’evoluzione temporale,
diramazioni comprese. Il concetto di branch deve comunque restare
distinto dal concetto di revisione sia per il sistema che per l’utente. I nodi del
documento a livello Struttura contengono al più un puntatore alla revisione
seguente e da zero ad infiniti puntatori a branch.
In riferimento alla figura 6.5, durante la navigazione nello storico, nel caso
in cui venga richiesto l’elemento seguente al nodo R2 il sistema fornisce R3
(che rappresenta l’effettivo successore) e l’indicazione che esiste un branch il
cui primo elemento è R2.1.
Si osservi che in generale, mentre per creare la nuova revisione è sufficiente
effettuare un commit sul nodo, per creare un branch occorre richiamare esplicitamente
un’opportuna primitiva. Questo permette da un lato di evidenziare
al massimo la differenza tra i concetti di revisione e di branch, dall’altro di
creare un branch anche a partire dall’ultima revisione disponibile dell’elemento.
Per eseguire quest’ultima operazione è necessario un meccanismo
esplicito di creazione dei branch.
In figura 6.6 è riportato un esempio di come Subversion operi al fine di
creare la copia della directory G (genitore) contenente un solo file F (figlio).
Per Subversion creare un branch di un’informazione primitiva significa
creare, ricorsivamente, un branch di ogni nodo dell’albero di cui essa è radice.
Questo comportamento in CISA viene ottenuto richiedendo il branching
143

Versioning in CISA Lo storico in CISA
Storico dell'elemento genitore
G1 G2
F1 F2
G2.1
F2.1
Storico dell'elemento figlio
Link di
Composizione
Link di Revisione
Link di Branch
Figura 6.6: Risultato della copia di una directory in Subversion.
dei nodi di interesse a livello Application (o Virtual Repository) in quanto
è un’operazione che concettualmente è applicata al documento come entità
strutturata. Questa scelta permette di ottenere anche una maggiore
flessibilità rispetto a quella di Subversion in quanto permette di ipotizzare
l’esistenza di diramazioni nelle quali non viene effettuato il branch di ogni
nodo dell’albero lasciando uno o più nodi in comune fra il branch e il ramo
principale.
Quest’ultimo caso è messo in evidenza in figura 6.7 nella quale la radice
G ha due figli: F’ e F”. Il branch del documento è stato effettuato creando
un branch della radice e del figlio F’ mentre il figlio F”non è stato duplicato.
Questo permette di propagare le modifiche di F”in entrambi i rami di sviluppo
(il ramo principale, che si sviluppa creando una nuova revisione di G2, e del
branch che si sviluppa creando una nuova revisione di G2.1).
In figura 6.8 è presente l’effetto della propagazione. L’azione scatenante è
la modifica di F”2 che, al tempo T , genera la revisione F”3 e la propagazione
avviene su entrambi i branch dando vita alle revisioni G3 nel ramo principale
e G2.2 nel branch. Per semplicità il figlio F’, presente in figura 6.7, non è
stato riportato in quanto non viene modificato durante la propagazione: G3
continua ad aggregare F’2 come G2 e G2.2 continua ad aggregare F’2.1 come
G2.1.
144

Versioning in CISA Lo storico in CISA
G1 G2
F''1 F''2
Figlio F''
G1 G2
F'1 F'2
Figlio F'
F''1 F''2
Figlio F''
Radice G
F'2.1
G2.1
Figura 6.7: Branch in D3IM con un figlio condiviso.
G3
G2.1 G2.2
F''3
Radice G
Legenda
T = istante
della nascita
del nodo F''3
Relazioni
Nodi
Tempo t < T Tempo t ≥ T
Figura 6.8: Propagazione in presenza di un figlio condiviso.
Merging da D3IM a CISA
L’operazione complementare al branching è il merging. Da un punto di
vista concettuale effettuare un merge significa integrare le modifiche presenti
su un branch in un altro branch. Nella pratica questa operazione può essere
effettuata secondo modalità diverse che variano con il contesto.
Supponendo quindi di operare con documenti D3IM occorre stabilire cosa
significhi fondere informazioni atomiche e informazioni primitive, elementi
che costituiscono i documenti presenti nei due branch di interesse. In realtà
si ricorda che le informazioni atomiche sono incapsulate all’interno di quelle
Abc
Abc
145

Versioning in CISA Lo storico in CISA
primitive e, a livello Structure, sono del tutto invisibili.
Il concetto di merge di informazioni atomiche è comunque necessario e
si è scelto di fornire ai livelli superiori a Structure delle modalità di fusione
elementari a partire dalle quali essi possano definire metodologie di merge
più complesse (in base alle proprie esigenze).
È possibile definire un’operazione di confronto fra due informazioni atomiche
(che dipende dal tipo di informazione atomica trattata e quindi, in
ultima analisi, dal contesto) che ne determina l’uguaglianza o la differenza.
Nel primo caso il merge è banale e il risultato è l’informazione stessa; altrimenti
l’operazione di confronto può permettere di stabilire l’entità della
differenza e si possono presentare le seguenti situazioni:
• il contesto permette al sistema di scegliere una delle due informazioni
automaticamente, scartando l’altra;
• il contesto non permette al sistema di effettuare una scelta, in tal caso
è l’utente a dover prendere una decisione;
• le informazioni sono diverse, ma confrontabili nei contenuti: il sistema,
automaticamente o sotto la supervisione dell’utente, genera una terza
informazione atomica sulla base di convenzioni prefissate.
L’ultimo caso è interessante perché è quello relativo all’esempio, introdotto
precedentemente, di Subversion: le informazioni atomiche sono rappresentate
dal contenuto di file (molto probabilmente codice sorgente scritto
in formato testuale); quindi è possibile applicare un confronto riga per riga,
operazione che permette di integrare le differenze nel caso in cui non siano
presenti conflitti (il sistema genera automaticamente la nuova versione) oppure
è in grado di rilevarli e permette all’utente di intervenire (il sistema
genera la nuova versione sotto la supervisione dell’utente).
Per quanto riguarda le informazioni primitive, occorre specificare cosa si
intende per uguaglianza tra di esse. Da un punto di vista astratto è possibile
considerarle come il punto di accesso all’informazione complessiva che si
sviluppa da esse fino alle foglie, come evidenziato nel sotto paragrafo 4.2.3.
Questo porta alla conclusione che il concetto di uguaglianza fra informazioni
primitive non è esprimibile esclusivamente sulla base del confronto del
contenuto informativo dei nodi che le rappresentano, ma in generale occorre
andare a considerare e confrontare ricorsivamente i nodi che tali informazioni
primitive aggregano. Dato che questo compito spetta ai livelli superiori
146

Versioning in CISA Lo storico in CISA
occorre delegare a loro anche la scelta dei criteri finalizzati alla valutazione
dell’uguaglianza o meno tra informazioni di questo tipo.
A seguito di questa considerazione è possibile concludere che Structure
deve fornire un supporto per il merging che permetta ai livelli superiori di
coprire tutte gli scenari possibili.
In riferimento alla figura 6.9 la seguente definizione di merging, valida
al livello Structure, permette di ottenere questo risultato: fondere (merge)
due elementi A e B (nodi D3IM) appartenenti a branch diversi dello stesso
storico, significa generare un terzo elemento C ottenuto da essi a seguito
dell’esecuzione di un determinato algoritmo. Il nuovo elemento C figura nello
storico come successore sia di A che di B e, per convenzione, appartiene al
ramo di A. La definizione e l’esecuzione dell’algoritmo di generazione vengono
lasciate al livello applicativo e possono essere quindi diversificate in base al
contesto.
Storico dell'elemento
A
B
C
Fusione o Merge
A,B in C.
Figura 6.9: Merge di due nodi.
Si osservi che, in questi termini, il merge è un’operazione definita fra due
branch che fonde il secondo sul primo. Questo si nota anche osservando che
A e B devono essere l’ultima revisione nel relativo branch, come mostrato in
figura. L’operatore di “merge” non è quindi commutativo: fondere A e B su
C è diverso da fondere B e A su C. Nel primo caso C appartiene al ramo di A
mentre nel secondo al ramo di B.
Il fatto che l’elemento C sia il successore di entrambi gli elementi si evidenzia
considerando che, a seguito di un’operazione di merge, viene attuata
147

Versioning in CISA Lo storico in CISA
la propagazione delle versioni in modo equivalente su entrambi i branch di
origine.
G'7 G'8
A
B
Nuove relazioni
Vecchie relazioni
G''4 G''5
C
Abc Nuovi nodi
Abc Vecchi nodi
Figura 6.10: Propagazione a seguito di un merge.
Facendo riferimento alla figura 6.10 G’7, prima del merge, aggrega per
composizione A mentre G”4 aggrega B. L’operazione di merge ha come risultato
C. La nascita di C avvia il processo di propagazione dando vita a G’8 e
a G”5.
Si osservi che effettuare il merge di un ramo su un altro è un’operazione
che determina, per convenzione, il raggiungimento della fine del branch; dopo
aver effettuato il merge non risulta più possibile generare nuove revisioni a
partire dai nodi fusi l’uno con l’altro, i nodi A e B dell’esempio precedente.
Questa limitazione è soltanto apparente in quanto è possibile generare nuovi
branch partendo da essi. In questo modo si può comunque “simulare” la
strategia di lavoro che consiste nel portare avanti lo sviluppo su due branch
separati integrando, quando necessario, le modifiche di uno nell’altro. Infatti
si può pensare che C appartenga ad uno dei due branch di partenza (ad
esempio quello nel quale si trova A) mentre a partire dall’altro (B) viene
generato un nuovo branch sul quale continuare lo sviluppo.
Un esempio relativo a questo caso è riportato in figura 6.11.a. In particolare
A, B e C sono i nodi che in figura sono stati creati rispettivamente al
148

Versioning in CISA Lo storico in CISA
tempo 1, 2 e 3. Lo sviluppo vuole essere portato avanti anche su un ramo
secondario e per questo motivo viene creato, al tempo 4, un nuovo branch.
Successivamente viene effettuato il merge con il ramo di sviluppo principale;
si osservi che non è obbligatorio effettuare questa operazione immediatamente
in quanto è possibile creare un numero arbitrario intermedio di nuove
revisioni.
Tempo
Storico dell'elemento
1 3
2
Ramo Principale
Branch
Ramo Secondario
Merge
4
Merge
Branch
a) Sequenze di branch
e di merge.
5
6
Tempo
Storico dell'elemento
1 3
Integrazione
Ramo Principale
2 4
Ramo Secondario
b) Integrazioni a livello
applicativo.
5
Integrazione
Figura 6.11: Gestione di due rami di sviluppo concorrente.
Infine un’altra strategia possibile consiste nel definire un “merge di livello
applicativo” che, a partire da B, integri le modifiche in A generando C, senza
rendere B antenato di C a livello Structure. In questo modo, partendo da
B, è possibile continuare lo sviluppo generando nuove revisioni. Un esempio
relativo a quest’ultimo caso è riportato in figura 6.11.b, come in precedenza,
i nodi A, B e C corrispondono rispettivamente a quelli creati al tempo 1, 2 e
3.
Gestione degli aspetti strutturali del documento
Il branching e il merging sono stati definiti e discussi, in modo rigoroso,
in riferimento ad un singolo nodo D3IM oppure in riferimento al caso di un
nodo D3IM aggregato per composizione da altri nodi.
Per quanto riguarda le relazioni “figlio-genitori”, necessarie per la gestione
della propagazione delle modifiche, l’aver considerato soltanto due livelli
6
149

Versioning in CISA Lo storico in CISA
della gerarchia nella struttura del documento non è limitativo. Tutti i ragionamenti
effettuati, possono essere ripetuti ricorsivamente permettendo quindi
di risalire, livello dopo livello, la struttura di un qualunque documento,
indipendentemente dalla sua dimensione.
Al contrario le relazioni inverse, quelle “genitore-figli”, necessarie per modellare
la struttura del documento, non vengono gestite dal livello Structure
e pertanto, in questo contesto, non risulta strettamente necessario discutere
come devono essere trattate in riferimento al branching e al merging.
In ogni caso il branching e il merging di un documento, visto nella sua
globalità, sono strettamente legati al versioning e risulta quindi interessante
presentare alcuni possibili scenari nei quali si mostra come possono essere
applicati in contesti reali.
Si considerino, ad esempio, dei documenti (costituiti da un numero arbitrario
di nodi) che devono essere trattati nei branch come un’unica entità.
Questo è esattamente il caso gestito da Subversion in quanto la copia del
ramo principale in un branch è ricorsiva e si sviluppa dalla radice fino alle
foglie dell’albero, comprendendo tutti gli elementi.
Per quanto riguarda D3IM questo significa creare un branch di ogni nodo
secondo le modalità esposte in precedenza e connettere il nodo che si ottiene
a seguito del branch di ogni genitore al nodo ottenuto dal branch dei figli
come introdotto in figura 6.6 ed ulteriormente evidenziato in figura 6.12.
La fase di merging viene trattata in modo duale andando ad applicare
opportuni algoritmi di confronto e generando una nuova versione per ogni
coppia di nodi che vengono fusi. Si osservi che, in questo esempio, è necessario
fondere tutti i nodi degli alberi relativi ai documenti D1 e D2 per ottenere un
terzo documento che concettualmente rappresenta il risultato dell’operazione.
Teoricamente niente vieta di fondere soltanto una parte dei nodi ed ottenere
una struttura ibrida nella quale non risulta possibile individuare tre
documenti distinti, ma parzialmente sovrapposti.
Dualmente è possibile effettuare il branch anche solo su una parte dei
nodi di interesse, come anticipato in figura 6.7: in questo caso il documento
ottenuto condivide una parte della struttura con il documento di partenza.
Questo modo di operare può risultare utile ad esempio quando si ha a che
fare con documenti che fanno riferimento ad informazioni che non possono
essere modificate dall’utente. In questo caso può avere senso per l’utente
effettuare il branch soltanto dei nodi sotto la sua diretta responsabilità.
In ogni modo, quello che è necessario evidenziare è che la consistenza
150

Versioning in CISA Lo storico in CISA
G
F1 F2
Doc. D1
Branch
Branch
Branch
Branch del
documento
G.1
F1.1 F2.1
D2 = branch di D1
Figura 6.12: Branch di un intero documento.
delle operazioni a livello di branch e di merge deve essere garantita dai livelli
superiori a Structure, così come la struttura del documento, visto che le due
entità sono strettamente correlate. Structure permette di operare creando
branch o fondendoli (con merge) su singoli nodi delegando ai livelli superiori
l’onere di inserire all’interno di essi il contenuto corretto (sia per quanto
riguarda i dati e i metadati delle informazioni atomiche, che per quanto
riguarda gli aspetti legati alla struttura del documento e i metadati delle
informazioni primitive).
6.2.5 La navigazione nello storico
Il layer Structure gestisce l’evoluzione temporale dei documenti e si attiva
a seguito di richieste che nascono ai livelli superiori. La gestione interna
dello storico è senz’altro necessaria, ma, affinché sia utile, occorre che questo
fornisca anche dei metodi finalizzati alla navigazione all’interno dell’insieme
di dati che codificano le varie versioni dei nodi.
Si ricorda che due versioni diverse della stessa informazione sono codificate
all’interno di due nodi distinti di livello Structure i quali hanno un proprio
indirizzo univoco (PRI) che li identifica. Tali elementi possono essere messi
in relazione tramite link di versione, ma focalizzando l’attenzione sull’entità
151

Versioning in CISA Lo storico in CISA
nodo, senza analizzare il suo contenuto, non è possibile distinguere se questo
contiene una determinata versione di una certa informazione oppure un’altra
informazione. In questi termini quindi due versioni differenti sono considerate
due informazioni distinte come nel caso di un’informazione primitiva che
aggrega, per composizione, un’altra informazione primitiva oppure di due
informazioni che non hanno nessun legame fra loro.
Alla luce di questa considerazione è possibile evidenziare come, senza
aggiungere ulteriori condizioni, il livello Virtual Repository possa accedere
ad ogni elemento dello storico di una data informazione semplicemente
conoscendone l’indirizzo univoco PRI.
Ovviamente un meccanismo di accesso di questo genere, che si basa su indirizzamento
assoluto, non può essere sufficiente per permettere una gestione
flessibile dello storico e, in questo caso, non sarebbe neanche corretto parlare
di “navigazione”.
La scelta effettuata consiste nell’aver previsto un meccanismo di navigazione
relativo all’interno dello spazio delle versioni.
L’accesso ai nodi informativi avviene tramite l’indirizzo persistente del
nodo al quale può essere aggiunto un parametro di versione. Il parametro di
versione è facoltativo per permettere la navigazione anche in termini assoluti.
L’utilizzo del parametro di versione in abbinamento ai PRI permette di
introdurre una definizione formale degli indirizzi relativi al livello Structure.
Tali indirizzi sono definiti con la sintassi esposta in in figura 6.13 con
notazione BNF.
::= "#"
::= "R_NEXT" | "R_PREV" | "H_ROOT" |
"B_ROOT" | "T_ABSLAST" | "T_RELATLAST"|
"B_LAST" | "H_GRAPH"
::= definizione nel paragrafo 8.3
Figura 6.13: Sintassi degli indirizzi di livello Structure.
La navigazione avviene per passi e parte da uno degli elementi il cui
indirizzo persistente è noto ai livelli superiori. Prendendo come riferimento
152

Versioning in CISA Lo storico in CISA
il nodo in questione viene richiesto, secondo un indirizzo relativo, un altro
nodo presente nello storico della stessa informazione. L’esempio più semplice
che può essere menzionato riguarda la navigazione fra una revisione e la
successiva o la precedente.
Partendo, ad esempio, dall’elemento N0 è possibile procedere in avanti
nelle revisioni operando nel modo seguente:
N1 ← richiedi(N0,rev_successiva)
N2 ← richiedi(N1,rev_successiva)
N3 ← richiedi(N2,rev_successiva)
...
richiedi(A,B) è un metodo che permette a Virtual Repository di richiedere
il nodo che partendo da A è raggiungibile tramite il parametro di versione B.
6.2.6 I parametri di versione
In questo sotto paragrafo vengono descritti i parametri di versione che
sono stati individuati e ritenuti utili nella fase di analisi.
Nella definizione è stata usata la seguente convenzione: il nome del parametro
è diviso, tramite il simbolo “ ”, in due parti: la prima è una singola
lettera e serve per identificare l’ambito in cui opera (i valori ammessi sono:
R per revision, H per history, B per branch ed infine T per time), la seconda
è una stringa che definisce una relazione all’interno del contesto in cui il
parametro è definito.
I parametri, riportati di seguito, sono accompagnati da una breve descrizione:
• R_NEXT: Revision, Next. Si riferisce alla revisione successiva del nodo
corrente. Si osservi che, a seguito di una richiesta con tale parametro
di versione, possono presentarsi i seguenti casi:
– non esiste la revisione successiva: la risposta è quindi negativa.
Questo è il caso dell’ultimo elemento presente nel ramo;
– esiste la revisione successiva: la risposta fornisce il nodo che la
contiene;
153

Versioning in CISA Lo storico in CISA
– ortogonalmente il nodo può essere radice di un branch, in questo
caso la risposta contiene, se esiste, il nodo relativo alla revisione
successiva e l’indirizzo univoco (PRI) del primo elemento del
branch. In questo modo viene soddisfatta la richiesta relativa alla
revisione successiva e i livelli superiori vengono messi a conoscenza
dell’esistenza del branch con la possibilità di indirizzarli.
• R_PREV: Revision, Previous. Si riferisce alla revisione precedente del
nodo corrente. In modo duale a R_NEXT possono presentarsi i seguenti
casi:
– non esiste la revisione precedente: la risposta è quindi negativa.
Ciò si verifica solo per la radice dello storico;
– esiste la revisione precedente: la risposta fornisce il nodo che la
contiene.
– il nodo può essere stato creato come nuova revisione o in seguito
ad un’operazione di merge. In quest’ultimo caso, similmente
a quanto è stato definito per le diramazioni, nella risposta sono
presenti il nodo che contiene la revisione precedente (che si trova
sullo stesso ramo del nodo di partenza) e l’indirizzo univoco (PRI)
dell’elemento precedente presente nell’altro branch.
• H_ROOT: History, Root. Questo parametro di versione si riferisce alla
radice dello storico ovvero al primo elemento che è stato creato.
• B_ROOT: Branch, Root. Si riferisce alla radice del branch ovvero all’elemento
che è stato preso come riferimento per creare il branch. Si
osservi che per quanto riguarda i nodi appartenenti al ramo principale
B_ROOT coincide con H_ROOT.
• T_ABSLAST: Time, Absolute Last. Elemento dello storico più recente
(da un punto di vista temporale).
• T_RELATLAST: Time, Relative Last. Elemento più recente presente nello
storico, relativamente al nodo di partenza ovvero per il quale tale nodo
figura fra gli antenati. Equivale al T_ABSLAST dello storico ipotetico
ottenuto considerando tutti i nodi dello storico iniziale a partire dal
nodo in esame (tale nodo rappresenta quindi la radice dello storico
ipotetico).
154

Versioning in CISA Lo storico in CISA
Storico completo dell'elemento
1 2 3 13
Il numero
rappresenta
l'istante t di
creazione
della versione.
Elemento di
riferimento
4 6
14 15 16
5 7 8 10
T_ABSLAST
T_RELATLAST
Storico
ipotetico relativo
9 11 12
all'elemento creato al tempo t=7
Figura 6.14: Esempio di elemento più recente relativamente al nodo di
partenza.
In figura 6.14 è riportato un esempio: il nodo preso come riferimento
è quello creato al tempo t=7. L’elemento T_ABSLAST relativo ad un
qualunque elemento dello storico, e quindi anche al nodo creato al tempo
t=7, è il nodo creato al tempo t=16. La risoluzione dell’elemento
T_RELATLAST, ovvero quello più recente relativamente al nodo creato a
t=7, è il T_ABSLAST dello storico ipotetico di cui il nodo creato a t=7
è la radice e, nel caso specifico, è rappresentato dall’elemento creato al
tempo t=12.
A C
B D
Branch
Ramo Principale
E F
B_LAST sul
ramo principale
B_LAST sul branch
Figura 6.15: Esempi di “last” relativi al branch.
155

Versioning in CISA Lo storico in CISA
• B_LAST: Branch, Last. Ultima revisione del branch. In riferimento al
caso riportato in figura 6.15 il B_LAST relativo ai nodi A, C, E ed F è F,
mentre quello relativo ai nodi B e D è D.
• H_GRAPH: La struttura dello storico. Quest’ultimo parametro di versione
si differenzia dagli altri in quanto non è utilizzato per ottenere una
particolare versione di N all’interno dello storico, ma per permettere a
Virtual Repository e/o Application di avere una visione globale dello
storico stesso. La struttura viene fornita, opportunamente codificata
all’interno di un documento D3IM, sotto forma di DAG nel quale ogni
elemento contiene l’indirizzo univoco (PRI) del corrispondente nodo
nello storico ed eventualmente altri metadati di interesse. La struttura
può essere completa o parziale (ad esempio localizzata nell’intorno
del nodo di riferimento) e questo aspetto viene gestito tramite un opportuno
attributo specificato nella richiesta. Si osservi che lo stesso
risultato che si ottiene tramite questo parametro di versione può essere
raggiunto, a livello Virtual Repository, visitando tutto il grafo relativo
allo storico dell’informazione di interesse tramite l’utilizzo degli altri
parametri di versione che Structure mette a disposizione. H_GRAPH non
è da considerarsi quindi utile nell’ottica dell’efficacia del sistema, ma
in quella dell’efficienza. I benefici di questa soluzione sono evidenti facendo
in modo che Structure codifichi (e mantenga aggiornato) il grafo
associato allo storico su un’opportuna struttura dati e che quindi riesca
a soddisfare la richiesta senza effettuare la visita (al posto di Virtual
Repository) di tutto lo storico. Considerando che i nodi dello storico
sono, per definizione, non eliminabili, la struttura può solo crescere nel
tempo. Questo vincolo permette tuttavia di ideare soluzioni per la sua
memorizzazione e gestione che scalino, senza difficoltà, all’aumentare
della dimensione ricorrendo ad opportune tecniche di partizionamento.
La definizione e l’introduzione effettiva di questa primitiva vengono
lasciate a sviluppi futuri.
156

Capitolo
7
Il servizio fornito dal layer Structure
Nel capitolo 6 è stato affrontato il problema del versioning dell’informazione
nel contesto dell’architettura CISA. Il problema è stato inquadrato,
ricondotto al modello dell’informazione D3IM (descritto nei capitoli 3 e 4)
ed affrontato da un punto di vista teorico.
In questo capitolo verranno trattate le varie problematiche da un punto
di vista più tecnico con la finalità di completare la progettazione, eseguita
per passi successivi, dell’intero sistema e, nello specifico, del layer Structure.
I compiti del layer Structure sono svolti da un unico tipo di servizio che
può essere erogato, in autonomia, da uno o più processi di livello applicativo
ISO/OSI. A tal riguardo si ricorda che alcuni servizi, come quelli legati alla
risoluzione dei nomi, non possono essere forniti unicamente da un solo processo,
ma i vari processi devono essere in grado di cooperare. Anche se, per
questa tipologia di servizio, è possibile che alcune richieste vengano espletate
esclusivamente dal processo al quale vengono rivolte questo è, a tutti gli
effetti, un caso particolare.
Nel contesto del layer Structure parlare di layer, di servizio o di processo
è quindi del tutto equivalente (a patto di assegnare ad ogni termine il giusto
significato concettuale) in quanto non vi è rischio di ambiguità.
Nella prima parte del presente capitolo verranno prese in esame l’interfac-

Il servizio fornito dal layer Structure Interfacce
cia che Structure fornisce a Virtual Repository e quella utilizzata da Structure
per l’interazione con Replica Management.
Nella seconda parte verranno introdotte, tramite il formalismo degli XML
Schema, le strutture dati interne al livello.
Infine, nella terza parte, verranno progettati gli algoritmi utilizzati all’interno
del layer Structure con il fine di arrivare a definire esaustivamente
l’implementazione del sistema, anche in sviluppi futuri.
7.1 Interfacce
La finalità del layer Structure è quella di fornire al layer Virtual Repository
il servizio di mantenimento e memorizzazione dell’evoluzione temporale
dell’informazione attraverso la definizione e gestione del relativo storico e
della navigazione all’interno di esso.
Per Virtual Repository il layer Structure è quindi un’entità remota alla
quale effettuare richieste di servizio. Come evidenziato nel capitolo 5, per
raggiungere questo risultato occorre definire un protocollo di comunicazione
che permetta alle due entità di interagire.
L’interazione è basata sul paradigma client/server: il client è rappresentato
da Virtual Repository che agisce da fruitore del servizio fornito da
Structure, il server. In questi termini Virtual Repository agisce da attore 1 nei
confronti di Structure il quale mette a disposizione un’interfaccia attraverso
la quale interagire. Tale interfaccia è mappabile sulle primitive del protocollo
che vengono invocate da Virtual Repository per le richieste di servizio e
la cui definizione implementativa è lasciata a sviluppi futuri. Il protocollo,
definendo il formato e l’ordine dei messaggi scambiati tra le due entità e le
azioni che hanno luogo a seguito della trasmissione e/o ricezione di un messaggio
(o di altri eventi), definisce l’API di comunicazione fra le logiche di
controllo di Virtual Repository e Structure, nell’accezione del contesto dell’interfaccia
bidimensionale descritta nel capitolo 9 nel sotto paragrafo 9.1.1.
L’API così definita rappresenta, secondo l’approccio tipico delle telecomunicazioni,
il Service Access Point (SAP) utilizzato da Virtual Repository per
la comunicazione con Structure.
Nel sotto paragrafo seguente verrà quindi introdotta l’interfaccia secondo
1 Con attore si intende un’entità esterna rispetto al sistema in esame che scambia con
esso messaggi in ingresso e/o in uscita. Il contesto è relativo ai diagrammi UML [RJB99].
158

Il servizio fornito dal layer Structure Interfacce
il formalismo dei diagrammi dei casi d’uso di UML. La finalità è quella di
presentare i vari tipi di richieste che possono essere effettuate ad alto livello
a Structure dando, allo stesso tempo, una breve descrizione delle azioni che
vengono svolte dal layer.
Successivamente viene introdotta, con la stessa modalità, l’interfaccia vista
da Structure messa a disposizione da Replica Management. Questo è utile
per evidenziare come Structure si avvalga del livello Replica Management per
soddisfare le richieste effettuate da Virtual Repository.
Per convenzione è stato scelto di assegnare i nomi ai casi d’uso nel modo
seguente: identificativo sistema.identificativo contesto.numero. L’identificativo
del sistema permette di associare il caso d’uso ad un sistema specifico,
in questo caso “Str” corrisponde a Structure e “Rep” a Replica Management.
L’identificativo del contesto specifica a quale entità del sistema il caso d’uso
si riferisce, ad esempio “Int” è l’interfaccia. Infine il numero sequenziale
permette di creare un nome univoco per ogni caso d’uso come richiesto per
rispettare le specifiche dettate da UML.
Alla fine del presente capitolo, nel paragrafo 7.3, verranno riportate alcune
considerazioni necessarie per comprendere a fondo la semantica delle
primitive.
7.1.1 Interfaccia mostrata a Virtual Repository
Nella descrizione che segue con sistema si intende il layer Structure,
principale soggetto dell’interazione.
In figura 7.1 è riportato il diagramma dei casi d’uso che permette di riassumere
graficamente le primitive che Structure espone a Virtual Repository.
Caso d’uso: Str.Int.GET
ID: UC.Str.Int.1
Attori: Virtual Repository.
Precondizioni:
159

Il servizio fornito dal layer Structure Interfacce
Figura 7.1: Casi d’uso relativi all’interfaccia mostrata da Structure a Virtual
Repository.
1. Deve essere noto il PRI del nodo N.
Sequenza degli eventi:
1. Il caso d’uso inizia quando il Virtual Repository ha la necessità di accedere
ad un elemento presente nello storico di N ed effettua la richiesta
di accesso specificando il PRI di N e il parametro di versione.
Il parametro di versione può essere (si ricorda che la definizione dei
parametri di versione è presente nel sotto paragrafo 6.2.6 a pagina 153):
• nessuno: per richiedere la versione corrente (esattamente il nodo
N);
• R_NEXT: per richiedere la versione successiva;
• R_PREV: per richiedere la versione precedente;
• H_ROOT: per richiedere la prima versione del nodo;
• B_ROOT: per richiedere la radice del branch (nel caso in cui il nodo
appartenga al ramo principale B_ROOT coincide con H_ROOT);
160

Il servizio fornito dal layer Structure Interfacce
• T_ABSLAST: per richiedere l’ultima versione creata (più recente da un
punto di vista temporale) presente all’interno dello storico completo;
• T_RELATLAST: per richiedere l’ultima versione creata (più recente
da un punto di vista temporale) che ha il nodo di partenza fra gli
antenati nello storico;
• B_LAST: per richiedere l’ultima versione presente nel branch corrente;
• H_GRAPH: per richiedere il DAG che rappresenta lo storico del nodo
N.
2. Il sistema, partendo da N, richiede a Replica Management (si faccia
riferimento al caso d’uso UC.Rep.Int.1) tutti i nodi necessari al raggiungimento
di Nx (nodo richiesto tramite il parametro di versione).
3. Il sistema restituisce il nodo Nx a Virtual Repository oppure un messaggio
di errore.
Scenari secondari:
1. Se viene richiesta la versione R_NEXT di un nodo nel quale hanno origine
uno o più branch, il sistema risponde fornendo la nuova revisione (se
esiste) e la lista di indirizzi del primo elemento di ogni branch. Questo
permette al Virtual Repository di creare una nuova richiesta sul branch
di interesse.
2. Se viene richiesta la versione R_PREV di un nodo ottenuto tramite un’operazione
di merge il sistema risponde fornendo la revisione precedente
e l’indirizzo del genitore presente nell’altro branch.
Caso d’uso: Str.Int.COMMIT
ID: UC.Str.Int.2
Attori: Virtual Repository.
Precondizioni:
161

Il servizio fornito dal layer Structure Interfacce
1. I nodi interessati devono esistere 2 ed essere stati precedentemente marcati
come RELAXED, LOCKED STRONG o LOCKED SOFT dal richiedente
del COMMIT, caso d’uso UC.Str.Int.5.
Sequenza degli eventi:
1. Il caso d’uso inizia quando il Virtual Repository ha la necessità di salvare
un documento o parte di esso ed effettua la richiesta di commit
specificando quali nodi sono stati modificati.
2. Il sistema sovrascrive (riferimento ad UC.Rep.Int.2/3/4.) o crea nuove
versioni di tali nodi (riferimento ad UC.Rep.Int.5) in base alla politica
di gestione esistente (legata allo stato UPDATE).
3. Vengono eseguiti gli algoritmi di propagazione delle versioni.
4. Il sistema restituisce un messaggio al Virtual Repository che può essere
positivo o di errore.
Caso d’uso: Str.Int.CREATE
ID: UC.Str.Int.3
Attori: Virtual Repository.
Sequenza degli eventi:
1. Il caso d’uso inizia quando Virtual Repository ha la necessità di creare
un nuovo documento o di aggiungere nuovi elementi ad un documento
esistente; in entrambi i casi effettua una richiesta di creazione di nuovi
nodi.
2. Il sistema effettua una richiesta di creazione a Replica Management per
ogni nodo da creare (riferimento ad UC.Rep.Int.5).
3. Il sistema restituisce un messaggio al Virtual Repository che può essere
positivo (in tal caso contiene il PRI del nuovo nodo) o di errore.
2 Per inserire nuovi elementi occorre fare riferimento al caso d’uso UC.Str.Int.3
162

Il servizio fornito dal layer Structure Interfacce
Caso d’uso: Str.Int.BRANCH
ID: UC.Str.Int.4
Attori: Virtual Repository.
Precondizioni:
1. I nodi di partenza devono esistere.
Sequenza degli eventi:
1. Il caso d’uso inizia quando Virtual Repository ha la necessità di creare
un branch nello storico di uno o più nodi.
2. Il sistema crea un nuovo nodo (riferimento ad UC.Str.Int.3) e copia in
esso il contenuto della versione indicata del nodo di partenza oppure,
se specificato da Virtual Repository, direttamente il nuovo valore che il
nodo deve assumere;
3. Il sistema inserisce nell’elemento di partenza le informazioni necessarie
per accedere al nuovo branch nella fase di navigazione dello storico;
4. Il sistema restituisce un messaggio a Virtual Repository che può essere
positivo (in tal caso contiene il PRI del nuovo nodo, radice del branch)
o di errore.
Caso d’uso: Str.Int.MARK
ID: UC.Str.Int.5
Attori: Virtual Repository.
Precondizioni:
163

Il servizio fornito dal layer Structure Interfacce
1. I nodi di interesse devono esistere.
2. Il nodo non deve avere nuove versioni ovvero deve essere l’elemento più
recente del branch affinché le etichette RELAXED, LOCKED STRONG
o LOCKED SOFT possano essere applicate.
Sequenza degli eventi:
1. Il caso d’uso inizia quando Virtual Repository ha la necessità di marcare 3
una lista di nodi e per farlo utilizza i seguenti parametri (i primi due
possono essere applicati contemporaneamente):
• OBSERVED, per mettere i nodi sotto osservazione;
• RELAXED, per indicare che l’utente è interessato alla modifica dei nodi
(con il fine di applicare una strategia di aggiornamento ottimistica
massimizzando l’awareness di alto livello);
• LOCKED_STRONG, per acquisire il lock Strong (sia in lettura che in
scrittura, vedi il sotto paragrafo 4.4.2) sui nodi;
• LOCKED_SOFT, per acquisire il lock Soft (solo in scrittura, vedi il sotto
paragrafo 4.4.2) sui nodi;
• NULL, per indicare che si intendono rimuovere tutte le etichette.
2. Il sistema accede ai vari nodi ed assegna gli identificativi in modo atomico
(ulteriori dettagli saranno riportati nel paragrafo 7.3).
3. Nel caso in cui tale operazione risulti possibile restituisce un messaggio
positivo, altrimenti di errore.
Caso d’uso: Str.Int.MERGE
ID: UC.Str.Int.6
Attori: Virtual Repository.
Precondizioni:
3 Ulteriori dettagli sulle etichette, e in generale sul meccanismo di marcatura, verranno
riportati nel sotto paragrafo 7.3.3.
164

Il servizio fornito dal layer Structure Interfacce
1. Devono esistere due nodi Nb1 e Nb2 che rappresentato l’ultima revisione
presente nei branch distinti b1 e b2 appartenenti allo stesso storico.
Sequenza degli eventi:
1. Il caso d’uso inizia quando Virtual Repository ha la necessità di fondere
i due branch b1 e b2 su un unico ramo e specifica i PRI di Nb1 e Nb2 e il
nodo (nuovo) Nsucc creato dall’unione di Nb1 e Nb2.
2. Il sistema crea un nuovo nodo, inserisce in esso Nsucc, lo rende successore
di Nb1 ed Nb2 ed appartenente al ramo di Nb1.
3. Il sistema restituisce un messaggio a Virtual Repository che può essere
positivo o di errore.
7.1.2 Interfaccia fornita da Replica Management
In questo caso l’attore principale (il client) è Structure che richiede l’espletamento
di alcuni servizi a Replica Management (il server).
Nella descrizione che segue con sistema si intende quindi il Livello Replica
Management, principale soggetto dell’interazione.
In figura 7.1 è riportato il diagramma dei casi d’uso che permette di
riassumere graficamente le primitive che Replica Management fornisce a
Structure.
Caso d’uso: Rep.Int.GET
ID: UC.Rep.Int.1
Attori: Structure.
Precondizioni:
1. Deve essere noto il PRI del nodo N.
Sequenza degli eventi:
165

Il servizio fornito dal layer Structure Interfacce
Figura 7.2: Casi d’uso relativi all’interfaccia mostrata a Structure da
Repository Management.
1. Il caso d’uso inizia quando Structure ha la necessità di accedere all’elemento
N ed effettua la richiesta di accesso specificandone il PRI.
2. Il sistema recupera una qualunque replica valida di N.
3. Il sistema restituisce il nodo N a Structure oppure un messaggio di errore
(se il nodo non esiste).
Caso d’uso: Rep.Int.LOCK
ID: UC.Rep.Int.2
Attori: Structure.
Precondizioni:
1. Deve essere noto il PRI del nodo N.
Sequenza degli eventi:
166

Il servizio fornito dal layer Structure Interfacce
1. Il caso d’uso inizia quando Structure ha la necessità di accedere in modo
esclusivo all’elemento N (per la lettura o per la scrittura) ed effettua la
richiesta di blocco specificandone il PRI.
2. Il sistema accede alla replica master sulla quale applica il lock.
3. Il sistema restituisce un messaggio a Structure che può essere positivo se
riesce ad applicare il lock o di errore in caso contrario (se il nodo è già
bloccato oppure non esiste).
Caso d’uso: Rep.Int.PUT
ID: UC.Rep.Int.3
Attori: Structure.
Precondizioni:
1. Deve essere noto il PRI del nodo N.
2. Il nodo N deve essere stato precedentemente bloccato (riferimento ad
UC.Rep.Int.2) dal processo di layer Structure che intende effettuare la
richiesta di aggiornamento.
Sequenza degli eventi:
1. Il caso d’uso inizia quando Structure ha la necessità di aggiornare l’elemento
N ed effettua la richiesta PUT specificando integralmente il nuovo
valore del nodo.
2. Il sistema accede alla replica master sulla quale applica l’aggiornamento.
3. Il sistema restituisce un messaggio a Structure che può essere positivo
se l’aggiornamento riesce o di errore in caso contrario (se il nodo non è
stato bloccato oppure non esiste).
4. Il sistema provvede ad aggiornare le varie repliche.
167

Il servizio fornito dal layer Structure Interfacce
Caso d’uso: Rep.Int.UNLOCK
ID: UC.Rep.Int.4
Attori: Structure.
Precondizioni:
1. Deve essere noto il PRI del nodo N.
2. Il nodo N deve essere stato precedentemente bloccato dal processo di
layer Structure che intende effettuare la richiesta di rilascio del blocco.
Sequenza degli eventi:
1. Il caso d’uso inizia quando Structure intende rimuovere il lock da un
nodo bloccato ed effettua la richiesta di UNLOCK specificando il PRI
del nodo N.
2. Il sistema accede alla replica master sulla quale applica l’aggiornamento
di stato.
3. Il sistema restituisce un messaggio a Structure che può essere positivo
se l’aggiornamento riesce o di errore in caso contrario (se il nodo non è
stato bloccato oppure non esiste).
Caso d’uso: Rep.Int.CREATE
ID: UC.Rep.Int.5
Attori: Structure.
Sequenza degli eventi:
168

Il servizio fornito dal layer Structure La struttura dati interna a Structure
1. Il caso d’uso inizia quando Structure intende creare un nuovo nodo ed
effettua una richiesta CREATE.
2. Il sistema crea la replica master del nuovo elemento. La primitiva prevede
la possibilità di creare il nodo ed acquisirne il lock direttamente oppure
di crearlo soltanto.
3. Il sistema restituisce un messaggio a Structure che può essere positivo
(in tal caso contiene il PRI del nuovo nodo) o di errore.
7.2 La struttura dati interna a Structure
In questo paragrafo viene introdotta la struttura dati necessaria per definire,
gestire e mantenere lo storico di un’informazione che, in questo caso, è
da considerarsi come nodo del layer Structure.
La struttura viene definita tramite un XML Schema, standard preso come
riferimento in CISA per la modellazione dei dati, del formato dei messaggi
dei protocolli, eccetera 4 .
Nel sotto paragrafo successivo i vari elementi dello Schema verranno commentati,
operazione necessaria per comprendere a fondo sia la loro funzione
che gli algoritmi descritti successivamente, nel paragrafo 7.3.
7.2.1 XML Schema
In questo paragrafo viene riportato lo XML Schema che permette di descrivere
i nodi D3IM a livello Structure sia in formato testuale che in formato
grafico nelle figure 7.3 e 7.4. Tali figure evidenziano la struttura, i dati e i
metadati presenti in un nodo senza entrare nel dettaglio della sintassi degli
XML Schema. In particolare la prima rappresenta una visione generale della
struttura tralasciando i link di versione (ovvero i link che permettono di generare
le relazioni fra nodi all’interno dello storico), la seconda rappresenta
proprio tali link.
Lo Schema non è stato commentato in quanto, in caso contrario, sarebbe
risultato eccessivamente dispersivo. Un’accurata descrizione di esso è comunque
presente nel sotto paragrafo successivo; gli elementi vengono descritti
nello stesso ordine con il quale compaiono nello Schema.
4 La scelta di XML per la modellazione dei dati è stata dettata dalla flessibilità,
compatibilità e portabilità che questo standard offre [Fra05].
169

Il servizio fornito dal layer Structure La struttura dati interna a Structure
Lo Schema è il seguente:
XML Schema - Definizione nodi D3IM a livello Structure di CISA
Author: Davide Chini
Date: 09/03/2006
Revision: 0.1
170

Il servizio fornito dal layer Structure La struttura dati interna a Structure
171

Il servizio fornito dal layer Structure La struttura dati interna a Structure
172

Il servizio fornito dal layer Structure La struttura dati interna a Structure
7.2.2 Descrizione dello XML Schema
La prima entità () serve per
includere un altro Schema, per la precisione pri.xsd, che contiene la definizione
degli indirizzi univoci e persistenti (PRI) definiti in D3IM (evidenziata
in figura 7.5).
Si osservi che nel paragrafo 8.3 sarà riportata un descrizione dettagliata
degli indirizzi PRI e una loro definizione formale sia tramite espressione regolare
(presente all’interno del tag xs:pattern in figura 7.5) che notazione
BNF.
Le entità successive definiscono sign e updateStateEnum.
Il primo di essi contiene “la firma” che Structure applica al nodo in fase
di creazione e/o di modifica e contiene tutti i parametri ritenuti utili per
173

Il servizio fornito dal layer Structure La struttura dati interna a Structure
node
header
body
anyType
0..*
nodeId
concurrency
structure
history
anyElement
0..*
0..*
observed
relaxed
child
parent
historyId
versionId
created
modified
update
versionLinks
lockStrong
Figura 7.3: Albero del XML Schema: visione globale.
0..*
0..*
lockSoft
+
+
+
174

Il servizio fornito dal layer Structure La struttura dati interna a Structure
history
histotyId
versionId
created
modified
update
versionLinks
+
+
0..1
0..*
0..2
0..1
0..1
revisionNext
branch
revisionPrevious
branchRoot
historyRoot
timeLast
firstRevision
branchLast
Figura 7.4: Albero del XML Schema: particolare dei link di versione.
value="urn:pri:(0\.|([1-9][0-9]*)\.)*(0|([1-9][0-9]*))
/[0-9a-zA-Z\-_.,();:=+$!~*’]+"
Figura 7.5: XML Schema che rappresenta gli indirizzi PRI.
l’identificazione dell’operazione. Si osservi che la definizione di tale elemento
può essere estesa e/o modificata. L’elemento structProcessId rappresen-
175

Il servizio fornito dal layer Structure La struttura dati interna a Structure
ta l’identificativo univoco del processo di livello Structure che ha effettuato
l’operazione (di creazione e/o modifica); occorre definire un meccanismo che
permetta di assegnare dei nomi univoci ai processi CISA (è opportuno che tale
meccanismo sia unificato all’interno di tutta l’architettura). Una possibile
soluzione è quella di proiettare i singoli processi all’interno dello dei spazio
dei nomi D3IM; è possibile ottenere questo risultato assegnando ad essi alcuni
nomi logici, un nome univoco (il cui valore sarebbe quello da inserire
nell’elemento structProcessId in esame) e un URL (che permette l’individuazione
e quindi l’accesso del processo in rete) esattamente come avviene
per le informazioni primitive.
Il secondo, updateStateEnum, rappresenta l’enumerazione dei possibili
stati assunti da UPDATE: FROZEN e CHANGING.
L’elemento successivo, node, definisce formalmente il nodo nel contesto
del layer Structure. Tale elemento, come evidenziato in figura 7.3, è suddiviso
in due sezioni: header e body. Questa distinzione è stata introdotta nel
paragrafo 6.2.1 ed è conseguenza dell’imbustamento, operazione che viene
effettuata in quanto CISA è un’architettura stratificata.
All’interno dell’elemento body viene infatti inserita la codifica del nodo
definita a livello Virtual Repository senza che Structure (information hiding)
sia interessato ad interpretarne il contenuto.
L’elemento header contiene invece tutti i dati e metadati di competenza
del layer Structure e quindi definiti in questo contesto. Sono presenti quattro
gruppi di elementi:
• nodeId: non è un vero e proprio gruppo, in quanto è un unico elemento
e rappresenta l’indirizzo univoco del nodo (PRI);
• concurrency: gruppo che contiene le informazioni necessarie per la
gestione della concorrenza negli accessi;
• structure: gruppo che contiene tutti gli elementi necessari alla rappresentazione
degli aspetti strutturali dei documenti D3IM;
• history: gruppo che contiene tutti gli elementi necessari alla gestione
e al mantenimento dello storico.
Per quanto riguarda nodeId non occorre specificare altro.
Il gruppo concurrency contiene le etichette, introdotte con il caso d’uso
UC.Str.Int.5, per la gestione della concorrenza. In particolare ad ogni nodo
176

Il servizio fornito dal layer Structure La struttura dati interna a Structure
può essere applicato un numero arbitrario di etichette observed e relaxed
ed una etichetta a scelta tra lockStrong e lockSoft. Ogni etichetta è un
elemento di tipo pri e tale indirizzo serve ad identificare l’entità (Avatar
dell’utente) che l’ha creata.
Il gruppo structure contiene due tipi di elementi: i figli del nodo (child),
che rappresentano le relazioni di aggregazione per composizione, e i genitori
(parent), che rappresentano le relazioni inverse. Il sistema deve quindi garantire
la consistenza della struttura: per ogni relazione child presente da
un generico nodo Np verso uno dei propri figli Nc deve esistere una relazione
parent in Nc verso Np e viceversa.
Si osservi che le relazioni parent hanno un attributo (backPropagation)
booleano (non presente in figura 7.3, si faccia quindi riferimento allo Schema
in formato testuale) che permette di stabilire se per quel particolare genitore
è attiva o meno la propagazione all’indietro delle versioni.
Il gruppo history contiene vari elementi, descritti di seguito:
• historyId: identificativo dello storico. Per convenzione è stato scelto
di utilizzare il PRI del nodo radice dello storico, indirizzo univoco per
definizione;
• versionId: identificativo della versione all’interno dello storico. La
sintassi è definita tramite l’espressione regolare [Goy06] riportata in
figura 7.6. Tale espressione regolare permette di rappresentare la cate-
([1-9][0-9]+\.[1-9][0-9]*\.)*[1-9][0-9]*
Figura 7.6: Espressione regolare che definisce gli identificativi di versione.
goria delle stringhe contenenti un numero arbitrario positivo di elementi
costituiti da cifre terminanti con un punto e una sequenza terminale di
cifre. Le sequenze di cifre rappresentano numeri interi e non possono
iniziare con “0”. Il numero di caratteri “.” deve essere pari, vale a dire
che la quantità di sequenze di cifre presenti è sempre dispari. Il motivo
di questo vincolo sarà chiarito più avanti.
177

Il servizio fornito dal layer Structure La struttura dati interna a Structure
Ad esempio, appartengono a questa classe le seguenti stringhe: “21”,
“8.9.12”, eccetera. Non appartengono a questa classe le seguenti stringhe:
“7.”, “.12”, “01.3”, “Ver=1.4”, “8.9.12.4”, eccetera. In particolare
l’ultima mostrata non è valida in quanto è presente una quantità
pari (non dispari) di sequenze di cifre. La struttura dell’identificativo
Identificatore
assoluto del branch
N 1 .N 2 . ... .N n .B id .R id
Identificatore
della radice
del branch
Identificatore
della revisione
Identificatore
relativo del
branch
Figura 7.7: Convenzione sui nomi dei nodi relativi allo storico.
è riportata in figura 7.7.
Tale rappresentazione permette di individuare univocamente le versioni
all’interno dello storico e il branch di appartenenza.
Per convenzione le prime N −1 cifre rappresentano l’identificatore assoluto
del branch all’interno dello storico. Questo identificatore si ottiene
aggiungendo al nome del nodo dal quale il branch è stato creato una
cifra sequenziale, l’identificatore relativo del branch. In questo modo
il primo branch del nodo “X.Y.Z” è “X.Y.Z.1”, il secondo branch è
“X.Y.Z.2”, eccetera.
In ogni branch è presente almeno un nodo e l’ultima cifra del nome
identifica la revisione relativamente al branch. In riferimento all’esempio
precedente la prima revisione nel primo branch è “X.Y.Z.1.1”, la
seconda revisione nel primo branch è “X.Y.Z.1.2”, la n-esima revisione
nel m-esimo branch è “X.Y.Z.m.n”;
• created: rappresenta la data e l’ora di creazione dell’elemento e contiene
l’identificativo del processo di livello Structure che lo ha creato.
Inoltre, nell’ipotesi in cui ogni azione che si sviluppa nel sistema sia riconducibile
ad un Avatar, contiene anche l’identificativo (PRI) di tale
Avatar;
• modified: contiene le medesime informazioni del parametro created
178

Il servizio fornito dal layer Structure La struttura dati interna a Structure
con la differenza che viene aggiornato ad ogni modifica di un qualunque
elemento presente nel nodo (sia nel caso di sovrascritture dei contenuti
che di aggiornamento dei metadati, ad esempio a seguito dell’aggiunta
del link di versione verso la revisione successiva);
• update: rappresenta lo stato che stabilisce la politica di gestione del nodo.
I valori ammessi sono changing e frozen: nel primo caso le richieste
di aggiornamento vengono gestite con sovrascrittura, nel secondo
tramite la nascita di nuove revisioni (e la relativa propagazione);
• versionLinks: gruppo di elementi che serve per codificare i link di
versione verso gli altri nodi. Tali elementi sono:
– revisionNext: indirizzo del nodo che rappresenta la nuova revisione;
– branch: elemento complesso che contiene i dati relativi al branch
radicato nel nodo. Tali dati sono:
∗ firstRevision: indirizzo del nodo che rappresenta la prima
revisione del branch;
∗ branchLast: indirizzo dell’ultimo nodo presente nel branch.
Questo campo, per motivi di efficienza, è presente solo nella
radice del branch. A seguito di una richiesta di accesso al
branchLast l’algoritmo viene eseguito in due passi: nel primo
si accede alla radice del branch e nel secondo all’elemento
richiesto. I vantaggi di questa soluzione sono evidenti nel
caso di nascita di una nuova revisione. Se ogni nodo del ramo
possedesse l’indirizzo del branchLast, il tempo necessario per
la nascita di una nuova revisione scalerebbe linearmente con il
numero di revisioni del branch (tutti i riferimenti andrebbero
aggiornati). Al contrario, la modalità attuata, permette di
aggiornare soltanto l’elemento radice (operazione che avviene
in tempo costante rispetto agli elementi nello storico) senza
penalizzare eccessivamente la fase accesso (ulteriori dettagli
saranno riportati nel paragrafo 7.3);
– revisionPrevious: indirizzo del nodo che rappresenta la revisione
precedente rispetto alla corrente;
179

Il servizio fornito dal layer Structure Introduzione agli algoritmi
– branchRoot: indirizzo del nodo che rappresenta la radice del branch;
– historyRoot: indirizzo del nodo radice dello storico, secondo le
convenzioni utilizzate è il nodo con identificativo “1”;
– timeLast: indirizzo del nodo che, considerando l’intero storico,
è stato introdotto più recentemente. Questo campo, per motivi
di efficienza, è presente solo nella radice di ogni branch e valgono
tutte le considerazioni riportate per il caso del branchLast. In
particolare deve memorizzare l’indirizzo dell’ultimo elemento inserito
nel ramo principale oppure in uno dei branch di cui il nodo
è radice. Si osservi che nella radice dello storico il campo time-
Last assume il significato dell’elemento inserito più recentemente
in assoluto ed è il valore a cui occorre fare riferimento per la risoluzione
del parametro di versione T_ABSLAST. I valori timeLast
presenti nelle radici dei vari branch servono per risolvere le richieste
relative al parametro T_RELATLAST come sarà più chiaro in
seguito.
7.3 Introduzione agli algoritmi
Il questo paragrafo verranno introdotti gli algoritmi che il sistema di versioning
dovrà implementare, in modo particolare verrà messo in evidenza il
comportamento di ogni processo di livello Structure a seguito delle richieste
di servizio effettuate da Virtual Repository (tramite l’interfaccia descritta nel
sotto paragrafo 7.1.1). Inoltre questo punto di vista permette di evidenziare
come Structure si relazioni con Replica Management tramite l’interfaccia
descritta nel sotto paragrafo 7.1.2.
Infine verranno introdotte alcune problematiche che sorgono nella progettazione
di un sistema complesso come CISA, per esempio quelle legate
alla gestione della concorrenza per mantenere lo spazio delle informazioni
consistente.
I formalismi utilizzati per la descrizione degli algoritmi sono sostanzialmente
due: il linguaggio naturale e i diagrammi di sequenza definiti in UML
([RJB99]).
180

Il servizio fornito dal layer Structure Introduzione agli algoritmi
7.3.1 Accesso ai documenti
L’accesso alle informazioni è un’operazione che viene avviata dai livelli
di CISA che si trovano sopra a Structure. L’aggregazione dei nodi che costituiscono
i documenti viene svolta da Virtual Repository. In particolare si
ricorda che le relazioni fra nodi previste in D3IM sono di due tipologie: link
di riferimento e link di composizione.
La prima categoria di link è equivalente alle informazioni atomiche, pertanto
viene definita e gestita integralmente ai livelli superiori; naturalmente
anche per quanto riguarda il versioning viene trattata come tale. Un’informazione
atomica varia se viene modificata la coppia “” ovvero,
nel caso in esame, il link stesso. Non vi è correlazione con le eventuali modifiche
all’elemento riferito. Si osservi che si considera indirettamente modificata
l’informazione primitiva che la incapsula e sulla quale vengono applicati gli
algoritmi di versioning.
La seconda categoria di link è strettamente legata al concetto di propagazione
delle modifiche e pertanto la gestione interna dei link di composizione
è a carico del layer Structure. A seguito di una richiesta di accesso ad un
elemento da parte di Virtual Repository, il layer Structure fornisce quindi il
contenuto del body del nodo (definito nel layer stesso, paragrafo 7.2) e, in
un’opportuna struttura dati, la lista dei figli aggregati per composizione.
In questo modo Virtual Repository può analizzare il contenuto di sua competenza
(presente nel body di livello Structure) ed estrarre i link di riferimento
codificati come informazioni atomiche.
A questo punto Virtual Repository ha a disposizione tutti i link uscenti dal
nodo e può selezionare quelli di interesse sui quali, ricorsivamente, proseguire
nell’accesso per la visita dell’intero documento.
7.3.2 Uso del parametro di versione
Nella descrizione della modalità di accesso appena introdotta non viene
fatto riferimento al parametro di versione.
Si ricorda che il parametro di versione è stato introdotto per permettere
la navigazione all’interno dello storico delle informazioni, quindi in questo
sotto paragrafo verrà descritto come viene utilizzato.
Si ricorda anche che il meccanismo di propagazione permette di riportare
le modifiche attuate ai nodi che si trovano più in basso nella gerarchia del
documento verso quelli che si trovano più in alto. Questo vuol dire che ogni
181

Il servizio fornito dal layer Structure Introduzione agli algoritmi
modifica ad un qualunque elemento del documento si ripercuote fino alla
sua radice. In altre parole, partendo dalla revisione corretta della radice del
documento, è possibile ottenere la configurazione completa di esso applicando
l’algoritmo ricorsivo descritto in precedenza (che opera con indirizzamento
assoluto).
Senza escludere la possibilità che Virtual Repository richieda tutti i nodi
del documento esplicitando un particolare parametro di versione, l’approccio
convenzionale di accesso all’informazione versionata consiste nel reperire la
versione voluta della radice del documento e poi, ricorsivamente, accedere ai
livelli inferiori della gerarchia senza parametro di versione.
Infatti, operando in questo modo, si ha la garanzia (fornita dal meccanismo
di propagazione) che il documento ricostruito sia consistente sia nei
contenuti che nella struttura.
Accesso alla versione
Per il layer Structure, indipendentemente dalla politica stabilita e utilizzata
dai layer superiori, l’accesso ad un’informazione tramite parametro di
versione è relativo ad un singolo nodo. In questo sotto paragrafo verranno
brevemente descritti alcuni dei possibili meccanismi per l’accesso ad una
specifica versione:
• R_NEXT, R_PREV, H_ROOT, B_ROOT: in riferimento allo Schema riportato
nel sotto paragrafo 7.2.1 ed alla figura 7.4, l’accesso da parte del layer
Structure a questo tipo di informazioni (che avviene a seguito di una
richiesta di tipo GET(PRI+PAR_VER) da parte di Virtual Repository),
avviene in due passi di elaborazione:
1. accesso al nodo di partenza tramite una richiesta GET(PRI) a
Replica Management (riferimento UC.Rep.Int.1);
2. ricerca dell’indirizzo della versione voluta all’interno della sezione
header → history → versionLinks e successivo accesso tramite
GET a Replica Management;
• T_ABSLAST, B_LAST: in questo caso l’accesso avviene in tre passi:
1. accesso al nodo di partenza tramite una richiesta GET(PRI) a
Replica Management;
182

Il servizio fornito dal layer Structure Introduzione agli algoritmi
2. ricerca dell’indirizzo della radice dello storico (in caso di richiesta
di accesso a T_ABSLAST) o della radice del branch (in caso di
B_LAST) nella sezione: header → history → versionLinks e
successivo accesso tramite GET a Replica Management;
3. ricerca dell’indirizzo della versione voluta all’interno della sezione:
header → history → versionLinks e accesso, finale, tramite
GET a Replica Management.
La figura 7.8 mostra i tre passi necessari per l’indirizzamento e l’accesso
al “last” sia nel caso in cui il “last” sia relativo all’ultimo elemento
modificato cronologicamente (parametro di versione T_ABSLAST) che
nel caso in cui sia relativo all’ultima revisione del branch (parametro di
versione B_LAST). Nel primo caso il nodo identificato con R1 rappresenta
la radice dello storico, nel secondo caso la radice del branch.
(2) first
R1 R2 R3 R4 R5
(3) last
Figura 7.8: Accesso al nodo “last” in tempo costante.
• T_RELATLAST: in questo caso l’accesso avviene in N passi (con N inferiore
o uguale al numero di elementi presenti dal nodo di partenza alla
fine del ramo a cui appartiene):
1. accesso al nodo di partenza tramite una richiesta GET(PRI) a
Replica Management;
2. ricerca dell’indirizzo della revisione successiva all’interno della sezione:
header → history → versionLinks ed accesso ad essa
tramite GET a Replica Management. Questo punto si ripete fino
(1)
183

Il servizio fornito dal layer Structure Introduzione agli algoritmi
al raggiungimento della fine del ramo oppure al raggiungimento di
un nodo che è radice di uno o più branch;
3. nel caso del raggiungimento del termine del ramo l’ultima revisione
rappresenta l’elemento voluto altrimenti viene effettuata la
ricerca dell’indirizzo del timeLast (che, per come è stato definito,
rappresenta l’elemento voluto) all’interno della sezione: header →
history → versionLinks e accesso, finale, tramite GET a Replica
Management.
Questo algoritmo può essere reso più chiaro se applicato ad un esempio
concreto. A tal proposito si faccia riferimento alla figura 6.14 presente
nel paragrafo 6.2.6 a pagina 155. La sequenza degli eventi è la seguente:
– viene richiesto il T_RELATLAST del nodo creato al tempo t=7;
– partendo dal nodo creato a t=7 l’algoritmo procede con la scansione
delle revisioni successive fino al raggiungimento della fine del
branch a cui tale nodo appartiene oppure di un nodo radice di uno
o più branch. Il nodo di partenza può soddisfare immediatamente
una, o entrambe, le condizioni. Nel caso in cui vengono verificate
entrambe ha la precedenza il fatto che il nodo è radice di uno o
più branch. Nell’esempio si avanza fino al nodo creato al tempo
t=8, radice di un branch;
– se il nodo a cui l’algoritmo è giunto è l’ultima revisione del ramo il
risultato è il nodo stesso. Invece se, come nell’esempio, è la radice
di uno o più branch, contiene l’indirizzo dell’elemento voluto nel
link di versione timeLast.
In figura 7.9 è mostrato il diagramma di sequenza relativo ad una richiesta
di accesso al documento da parte dell’utente. Le interazioni fra utente e
Application e fra Application e Virtual Repository non interessano in questo
contesto e non sono descritte in modo formale.
La sequenza degli eventi è la seguente:
• l’utente richiede il documento all’applicazione agendo sull’interfaccia
utente che questa fornisce;
• Application richiede, tramite una chiamata all’opportuna primitiva, il
documento a Virtual Repository (passo 2);
184

Il servizio fornito dal layer Structure Introduzione agli algoritmi
Figura 7.9: Diagramma di sequenza relativo all’accesso ad un documento.
• al passo 3, Virtual Repository richiede la radice a Structure specificandone
l’indirizzo univoco pri ed, eventualmente, il parametro di versione
invocando la primitiva GET (UC.Str.Int.1);
• al passo 4 Structure richiede a Replica Management il nodo corrispondente
all’indirizzo specificato (pri);
• nel caso in cui Virtual Repository non abbia specificato il parametro di
versione i passi 5 e 6 non vengono eseguiti. Viceversa Structure (passo
5) analizza l’header del nodo e sceglie il link di versione da seguire.
Tale link specifica l’indirizzo PRI nella nuova revisione la quale (passo
6) viene richiesta a Replica Management. Se il parametro di versione è
R_NEXT, R_PREV, H_ROOT oppure B_ROOT la procedura termina in quanto
il nodo richiesto a Replica Management è quello voluto. Viceversa se il
parametro di versione è T_ABSLAST o B_LAST occorre un altro passo di
elaborazione e, in tal caso, vengono ripetuti un’ulteriore volta i passi 5
e 6. Infine se il parametro di versione è T_RELATLAST occorrono altri
185

Il servizio fornito dal layer Structure Introduzione agli algoritmi
passi di elaborazione e, in tal caso, vengono ripetuti i passi 5 e 6 quanto
necessario;
• i passi 7 ed 8 servono per recuperare (ricorsivamente) tutti i nodi del
documento che alla fine viene fatto pervenire ad Application e mostrato
all’utente. Si osservi che normalmente in questa fase, ver par non
viene specificato in quanto, una volta individuata la versione corretta
della radice, si ricostruisce correttamente la configurazione voluta del
documento seguendo i link verso i figli con parametro di versione nullo.
7.3.3 Modifica di documenti
L’operazione di modifica delle informazioni è senza dubbio più complessa
rispetto a quella di indirizzamento ed accesso illustrata precedentemente. Si
tratta infatti di un’operazione distruttiva e pertanto deve essere rigidamente
regolamentata per evitare problematiche di inconsistenza dei dati dovute ad
eventuali accessi concorrenti.
Il livello Structure, compatibilmente con la visione che ha dell’informazione
e collaborando con i livelli ad esso adiacenti, permette di implementare
le politiche di accesso e di authoring concorrente previste nel modello D3IM
e descritte nel paragrafo 4.4.2.
Si ricorda che le politiche attuate sono le seguenti:
• Strong: blocca in scrittura e in lettura tutti i nodi interessati all’apertura
della sessione.
• Soft: blocca i nodi in scrittura lasciando la possibilità di accesso in
lettura.
• Relaxed: consente di effettuare authoring concorrente tramite l’approccio
copy-merge.
Le prime due prevedono il blocco esclusivo di un insieme di nodi appartenenti
ad uno o più documenti. La scelta dei nodi sui quali acquisire il lock è
di competenza dei livelli superiori a Structure in quanto si basa sugli aspetti
strutturali del documento.
La Relaxed, permette di attuare politiche ottimistiche e, in prima approssimazione,
si potrebbe pensare che non sia necessario contrassegnare i nodi
186

Il servizio fornito dal layer Structure Introduzione agli algoritmi
che si intende modificare. In CISA invece si è scelto di applicare ad essi un’etichetta
il cui unico aspetto funzionale è relativo all’aumento dell’awareness
di alto livello.
Infine è stato individuato un ulteriore caso, utile per aumentare ulteriormente
l’awareness di alto livello. Questo risultato può essere ottenuto
prevedendo due tipologie di etichette: una, già descritta, relativa ai nodi sui
quali si intende effettuare una modifica; l’altra relativa agli elementi di interesse
coinvolti in sola lettura per i quali si intende ricorrere allo schema di
interazione Publish & Subscribe [Inn04].
La finalità del primo tipo di etichetta è quella di aumentare l’awareness degli
altri utenti che possono essere interessati al nodo sul quale si sta operando.
Dualmente il secondo tipo di etichetta serve per aumentare il proprio livello
di awareness, fornendo all’utente un metodo per essere informato su eventuali
modifiche effettuate dagli altri utenti sui nodi di interesse. Si noti che
l’introduzione del meccanismo di notifica visto nel capitolo 5 permetterebbe
di informare l’utente in modalità push.
Alla luce di queste considerazioni sono state identificate le quattro etichette
applicabili tramite l’operazione di “marcatura” del nodo descritte nel
caso d’uso UC.Str.Int.5 (a pagina 163):
• OBSERVED 5 , per mettere i nodi sotto osservazione;
• RELAXED, per indicare che l’utente è interessato alla modifica del nodo;
• LOCKED_STRONG, per acquisire il lock Strong (sia in lettura che in scrittura)
sul nodo;
• LOCKED_SOFT, per acquisire il lock Soft (solo in scrittura) sul nodo;
• NULL, per indicare che si intendono rimuovere tutte le etichette.
Si osservi che le prime due etichette possono essere applicate contemporaneamente
6 e che il loro inserimento in un nodo è un’operazione distruttiva
e quindi occorre trattarla come tale.
In conclusione l’operazione di marcatura dei nodi deve essere effettuata
prima di ogni operazione di modifica. Nella figura 7.10 viene descritta la
sequenza dei passi che devono essere svolti per applicare la marcatura:
5Serve per effettuare l’equivalente della sottoscrizione definita nel contesto dello schema
di interazione Publish & Subscribe.
6Le etichette LOCKED_STRONG e LOCKED_SOFT vengono utilizzate in modo esclusivo in
quanto garantiscono, per definizione, che nessun altro possa modificare il nodo.
187

Il servizio fornito dal layer Structure Introduzione agli algoritmi
• l’utente (o per suo conto l’applicazione) stabilisce la lista dei nodi
da modificare e le politiche di accesso da applicare. Inoltre vengono
individuati eventuali nodi da mettere sotto osservazione;
Figura 7.10: Diagramma di sequenza relativo alla prenotazione per la
modifica di un documento.
• Virtual Repository viene messo nella condizione di effettuare la richiesta
di marcatura dei nodi (passi 1 e 2);
• Virtual Repository effettua la richiesta di marcatura tramite la primitiva
MARK. La richiesta viene effettuata fornendo una tabella (table)
nella quale vengono indicati tutti i nodi da marcare con le relative etichette.
La finalità di questo approccio è di garantire al Livello Virtual
Repository che l’operazione di marcatura avvenga in modo atomico: se
tutti i nodi sono etichettabili l’operazione riesce, altrimenti fallisce;
• al passo 4 viene richiesto il LOCK in modo esclusivo su tutti i nodi a
Replica Management 7 ;
7 Si ipotizza che l’operazione di LOCK restituisca un parametro che permetta, se ne-
188

Il servizio fornito dal layer Structure Introduzione agli algoritmi
• al passo 5 il sistema applica le etichette;
• al passo 6 viene richiesto il rilascio del LOCK.
Lo scenario appena mostrato si riferisce al caso in cui l’operazione MARK
riesce con successo. Si osservi che la politica descritta deve essere in grado
di gestire correttamente il ciclo relativo al passo 4 che risulta, operando in
questo modo, l’unico punto critico dovuto alla concorrenza e sul quale occorre
prestare la massima attenzione in fase progettuale. I problemi che possono
sorgere sono relativi ad eventuali “deadlock” e in generale sono quelli che
tipicamente si presentano nel caso in cui vengano condivise risorse fra entità
asincrone tramite politiche di“locking”. L’approfondimento di questo aspetto
viene lasciato agli sviluppi futuri.
La politica descritta, nell’ipotesi di rendere “sicuro” il ciclo al passo 4, risolve
il problema della concorrenza anche se è estremamente conservativa e in
grado di operare solo nelle ipotesi che hanno permesso di formulare la politica
di propagazione “push” descritta nel sotto paragrafo 6.2.3 (a pagina 133).
Il salvataggio delle informazioni è possibile soltanto se i nodi di interesse
sono stati precedentemente etichettati come appena descritto. Nella figura
7.11 viene mostrata la sequenza temporale degli eventi nel caso in cui
tutti i nodi interessati si trovino nello stato FROZEN:
• l’utente decide di salvare le modifiche e i layer Application e Virtual
Repository si mettono nelle condizioni di effettuare il commit verso
Structure;
• viene richiesta a Structure l’operazione COMMIT specificando una lista
(list) contenente tutti i nodi modificati;
• il sistema richiede la versione precedente di tutti i nodi presenti nella
lista (passo 4);
• il sistema (followBackPropagation()) segue i link di propagazione all’indietro
richiedendo tutti i nodi interessati in modo ricorsivo al passo 5,
applicando il meccanismo di propagazione “push”;
• il sistema applica ai nodi il LOCK al passo 6, dato che conosce esattamente
quali sono quelli interessati dalla modifica;
cessario, di determinare se il nodo richiesto precedentemente non sia stato nel frattempo
modificato. Altrimenti, per avere la garanzia di consistenza, occorre effettuare nuovamente
la GET dei nodi acquisiti.
189

Il servizio fornito dal layer Structure Introduzione agli algoritmi
Figura 7.11: Diagramma di sequenza relativo alla richiesta di salvataggio di
un documento.
• il sistema crea la nuova revisione di ogni nodo (passo 7);
• il sistema richiede al passo 8 il salvataggio di tutti i nodi coinvolti fino al
passo precedente in quanto in quelli appena creati deve essere inserito
il valore aggiornato dell’informazione mentre in quelli già esistenti (che
contengono le revisioni precedenti) occorre aggiornare i link di versione.
Si osservi che il diagramma di sequenza non è esaustivo in quanto occorre
andare ad aggiornare anche i link di versione presenti nella radice di
190

Il servizio fornito dal layer Structure Introduzione agli algoritmi
ogni branch che si incontra fino al raggiungimento del ramo principale
e nella radice dello storico di ogni nodo. Nella radice del branch di appartenenza
del nodo occorre aggiornare i link branchLast e timeLast,
mentre in tutti gli altri soltanto timeLast. Si capisce quindi che l’inserimento
di una nuova versione, dal punto di vista dell’aggiornamento
dei parametri legati allo storico, è un’operazione che scala linearmente
con il numero di branch. Questo non rappresenta un problema in
quanto il numero di branch è un parametro che deve essere tenuto sotto
controllo per non rendere lo storico stesso eccessivamente complesso da
trattare da parte dell’utente;
• il sistema rilascia il LOCK su tutti i nodi come ultimo passo.
Si osservi che tutte le considerazioni riguardanti l’accesso concorrente in
scrittura e l’atomicità della primitiva MARK possono essere estese anche al
caso del COMMIT.
Il concetto di sessione
Il paradigma di interazione REST prevede che le entità interessate siano,
per quanto possibile, stateless. Seguendo questa filosofia il concetto di
sessione, così come previsto ed introdotto in UEVM, viene gestito in modo
implicito: si assume che l’apertura della sessione avvenga nel momento in cui
i nodi vengono marcati e che si abbia la chiusura della stessa in concomitanza
della fase di COMMIT.
La chiusura implicita della sessione è attuata nel diagramma di sequenza
di figura 7.11. Il sistema infatti, partendo dalla lista dei nodi effettivamente
modificati, segue i link di propagazione all’indietro per individuare tutti i
nodi interessati dalla propagazione. Per ognuno di essi viene creata una e
una sola nuova versione indipendentemente dal fatto che quel nodo venga
incontrato una o più volte durante la risalita nella gerarchia dei nodi. Tale
versione comprende tutte le variazioni effettuate sui discendenti durante la
sessione.
Servizi di branching e di merging
Le primitive necessarie per effettuare le operazioni di branch e di merge
sono state progettate in modo tale che operino anch’esse su una lista di nodi
con la finalità di rendere tali operazioni atomiche per Virtual Repository.
191

Il servizio fornito dal layer Structure Introduzione agli algoritmi
Per quanto riguarda il BRANCH è possibile affermare che può essere affrontato
con le stesse modalità descritte per l’operazione di COMMIT con la differenza
che non è necessario marcare precedentemente i nodi di partenza in quanto,
avendo il significato logico di copia dell’informazione, non occorre prevedere
nessun meccanismo che aumenti l’awareness di alto livello. Addirittura applicare
le etichette, come descritto per il caso di modifica dell’informazione,
sarebbe un’operazione fuorviante per l’utente.
L’operazione di MERGE può essere ricondotta al caso di modifica dell’informazione,
pertanto viene svolta secondo le medesime modalità. Questa
similitudine deriva dal fatto che effettuare un MERGE equivale a creare una
nuova revisione sul ramo verso il quale si attua la fusione, con la differenza
che, in questo caso, devono essere aggiornati anche i link di versione presenti
sui nodi che si trovano sull’altro branch.
192

Capitolo
8
Il servizio di risoluzione dei nomi
I nomi user-friendly (HFN) sono stati introdotti nel capitolo 4 (in particolare
nel sotto paragrafo 4.2.1 a pagina 86) al fine di colmare il divario tra la
denominazione interna al sistema con identificativi unici (URN) e le esigenze
di alto livello dell’utente. Il principale vantaggio è la possibilità di realizzare
visioni multiple della stessa risorsa, simulando contesti coerenti all’esperienza
quotidiana degli utenti. Il sistema degli URN consente l’indirizzamento di
insiemi di repliche che sono singolarmente accessibili a basso livello tramite
URL.
Nel modello stratificato CISA ogni livello ha bisogno di un indirizzo che
distingua il punto di accesso sull’interfaccia. In particolare i nomi HFN sono
adatti ad indirizzare le entità di Virtual Repository Layer, mentre gli URN
rispondono alle esigenze di unicità delle entità dei livelli Structure. Infine
gli URL si prestano per l’accesso alle risorse, di competenza del Replica
Management Layer.
I tre spazi dei nomi devono essere tra loro relazionati attraverso due meccanismi
di risoluzione: il primo si occupa di risolvere HFN in URN ed il
secondo si occupa di risolvere URN in URL. La risoluzione deve essere possibile
anche in modo inverso, ovvero dato un URL di una replica deve essere
possibile risalire al rispettivo URN, e quindi a tutti i possibili HFN.
I concetti alla base del sistema sono fondamentalmente analoghi alle speci-

Il servizio di risoluzione dei nomi Requisiti dei nomi
fiche generali del DNS (Domain Name System) [Moc87a, Moc87b]. Si ricorda
che i principali componenti del DNS sono:
• Domain Name Space: spazio dei nomi è strutturato ad albero;
• Name Server: programmi che detengono la struttura ad albero del dominio
e l’insieme delle informazioni correlate. Un name server è detto
Authority per alcune parti del Name Space. Le autorità sono organizzate
in unità chiamate Zone, le quali possono essere automaticamente
distribuite.
• Resolver: programmi che estraggono l’informazione dai Name Server
in risposta alle richieste dei client.
Nel sistema in discussione la risoluzione è affidata a server strettamente
correlati al responsabile dell’informazione. Sebbene in seguito l’informazione
possa migrare, il servizio di risoluzione è marginalmente incurante di questo
aspetto: l’accesso e la risoluzione sono due attività completamente indipendenti.
Questo approccio consente di rispondere al requisito di mantenere,
quando possibile, il legame con la sorgente. Si prevede quindi che la risoluzione
rimanga sempre in carico ai server di risoluzione di proprietà dell’organizzazione
di cui fa parte il responsabile che inserisce la prima (ed unica)
volta l’informazione.
8.1 Requisiti dei nomi
Il sistema è caratterizzato da tre tipologie di nomi: HFN, URN e URL.
Questi sono utilizzati per finalità diverse. Mentre per URN ed URL esistono
delle specifiche standardizzate, per gli HFN esiste una forte esigenza, ma
nessun vincolo precisamente dichiarato. In particolare i requisiti di base
degli URN coincidono con quelli degli URI (Uniform Resource Identifier), in
quanto gli URN ne costituiscono un sottoinsieme.
Il sistema delle applicazioni ha bisogno di ricercare ed identificare le informazioni
che devono essere elaborate. Al crescere della connettività della
rete la capacità di usare risorse remote, indipendentemente gestite, diventa
una necessità prioritaria.
Un URN identifica un insieme di repliche ovvero un’unità di informazione,
mentre un URL identifica la locazione dell’istanza di una risorsa all’interno
194

Il servizio di risoluzione dei nomi Requisiti dei nomi
dell’insieme. La risorsa, identificata prima tramite un URN e poi acceduta
tramite un URL, può risiedere in uno o più host, può muoversi o non essere
disponibile a tutti.
Un URL indica una particolare replica di una risorsa e dove questa risiede,
mentre la risorsa stessa è indicata dagli URN. Sotto questo punto di
vista l’obiettivo degli URN è fornire un identificatore globalmente unico e
persistente, usabile anche per riconoscere e per accedere alle caratteristiche
della risorsa (Uniform Resource Characteristic, URC) o alla risorsa stessa.
In questo paragrafo verranno formulati i requisiti degli HFN e brevemente
riportati quelli degli URN al fine di delineare le principali caratteristiche e
presupposti per la definizione dei rispettivi spazi di nomi per CISA. Per
quanto riguarda gli URL il sistema è completamente definito in [BLMM94].
8.1.1 Requisiti per gli HFN
Il sistema dei nomi ad alto livello in relazione all’architettura CISA deve
essere:
• comprensibile e facilmente usabile dall’essere umano;
• facilmente memorizzabile e ricollegabile ad un contesto;
• riferito alla struttura dell’ambiente virtuale;
• facilmente analizzabile da un elaboratore;
• non legato alla locazione delle risorse fisiche utilizzate;
• tale da facilitare la navigazione;
• composto da parole semplici.
8.1.2 Requisiti per gli URN
La persistenza di un identificativo indica l’indipendenza dalla mutabilità
dell’ambiente. L’assegnazione è immutabile, in quanto la mutabilità di una
risorsa è indipendente dall’assegnazione del relativo identificativo.
Affermare che un URN è persistente, cioè che ha un lungo tempo di vita,
comporta assumere come valide le seguenti proprietà:
195

Il servizio di risoluzione dei nomi Requisiti dei nomi
• mobilità: le repliche possono muoversi fisicamente da una macchina
all’altra; i responsabili possono spostarsi all’interno dell’organizzazione
oppure le organizzazioni autoritative possono unirsi, trasformarsi o
dividersi;
• evoluzione: il sistema è continuamente in evoluzione cioè nuovi sottosistemi
e protocolli possono essere creati ed i vecchi aggiornati.
Requisiti non funzionali
Portata globale. Un URN è un nome globale, la cui portata non implica
una locazione. Ovunque ha lo stesso significato.
Unicità globale. Lo stesso URN non può essere assegnato a due o più
differenti risorse (che non siano repliche).
Persistenza. Il tempo di vita di un URN è indefinito, cioè una volta creato
non è rimovibile. Questa assunzione implica che un URN è globalmente unico
per sempre e può essere utilizzato per riferire una risorsa oltre il tempo di
vita della risorsa stessa.
Scalabilità. Gli URN possono essere assegnati a qualsiasi risorsa che deve
essere mantenuta disponibile in rete per un tempo indefinito.
Supporto Legacy. Lo schema deve permettere il supporto a sistemi di
nomi già esistenti, come ad esempio DOI (Digital Object Identifier) [Fou04]
e ISBN.
Estendibile. Lo schema degli URN deve permettere la crescita dello spazio
dei nomi.
Indipendenza. L’autorità che assegna i nomi è l’unica responsabile nel
determinare le condizioni sull’emissione del nome.
Risolubile. Un URN non deve ostacolare la risoluzione (ovvero la traduzione
in URL). In particolare deve esistere un meccanismo flessibile che traduca
un URN in un URL.
196

Il servizio di risoluzione dei nomi LRI: gli identificatori logici delle risorse
8.1.3 Requisiti sulla codifica
In aggiunta ai precedenti requisiti ne esistono ulteriori, relativi alla codifica
e valevoli sia per HFN che per URN.
Coerente ad altre codifiche. La codifica deve essere il più possibile
coerente con altri schemi di nomi già esistenti.
Semplicità del confronto. L’algoritmo per confrontare tra loro gli URN
(HFN), intesi come stringhe, deve essere semplice, locale e deterministico.
Trascrivibile dall’uomo. Per l’uomo deve essere possibile trascrivere gli
URN (per gli HFN tale operazione deve risultare il più semplice possibile)
per cui devono essere:
• composti da una sequenza sufficientemente limitata di caratteri;
• case insensitive;
• non complicati dall’uso di simboli speciali.
Trasportabile. Un URN (HFN) è tale da essere identicamente trasportabile
sia nei messaggi dei comuni protocolli Internet sia su carta.
Trattabile dalla macchina. Un URN (HFN) deve essere processabile dai
calcolatori.
Riconoscibile. La codifica di un URN (HFN) deve essere riconoscibile
durante il parsing di un testo.
8.2 LRI: gli identificatori logici delle risorse
Si definisce identificatore logico di una risorsa (LRI, Logical Resource
Identifier) un nome HFN, appartenente all’insieme degli URI. Il nome è composto
da più parti suddivise dal carattere “/” ed ogni singola parte rappresenta
un’entità logica dell’ambiente virtuale. L’insieme delle parti, separate
da “/”, rappresenta il percorso. L’ultima entità è quella che si vuole individuare.
L’intero percorso assieme all’entità da individuare è il nome logico
197

Il servizio di risoluzione dei nomi LRI: gli identificatori logici delle risorse
dell’entità. Il formato completo è illustrato in figura 8.1 con notazione BNF
(Backus-Naur Form).
Si osservi che l’insieme di caratteri utilizzabile per la definizione
dei nomi è quello definito nel contesto degli URI [BLFIM98].
Questa soluzione è stata scelta in base a quelle che sono state ritenute
le esigenze attuali del progetto e può essere estesa, in modo da permettere
l’agevole codifica di stringhe appartenenti anche ad altri idiomi, nel momento
in cui questo risulti necessario. A tal proposito è possibile fare riferimento
agli Internationalized Resource Identifiers (IRI) descritti in [DWSC05].
::=
::= "lri://"()
::= (/)*
::=
::=
::= ";" | ":" | "&" | "=" | "+" | "$" | "," |
"-" | "_" | "." | "!" | "~" | "*" | "’" |
"(" | ")" | "a" | "b" | "c" | "d" | "e" |
"f" | "g" | "h" | "i" | "j" | "k" | "l" |
"m" | "n" | "o" | "p" | "q" | "r" | "s" |
"t" | "u" | "v" | "w" | "x" | "y" | "z" |
"A" | "B" | "C" | "D" | "E" | "F" | "G" |
"H" | "I" | "J" | "K" | "L" | "M" | "N" |
"O" | "P" | "Q" | "R" | "S" | "T" | "U" |
"V" | "W" | "X" | "Y" | "Z" | "0" | "1" |
"2" | "3" | "4" | "5" | "6" | "7" | "8" |
"9"
Figura 8.1: Sintassi dei Logical Name.
Essendo i World ed i Group due concetti totalmente disgiunti, la sintassi
del nome per i due casi è mutuamente esclusiva. Il percorso è utilizzato
per effettuare tale distinzione. Dato che gli Stuff e gli Avatar non possono
contenere nessuna altra entità, quando vengono indicati, diventano necessariamente
elementi terminali del nome. Opzionalmente ogni entità può essere
specificata con la relativa estensione: .avt per gli Avatar, .grp per i Group,
.stf per gli Stuff e .wrl per i World.
Nel caso particolare degli Stuff, che nel modello CISA si specializzano in
documenti D3IM, il nome può essere seguito da un ulteriore identificativo.
198

Il servizio di risoluzione dei nomi PRI: gli identificatori persistenti
Alcuni esempi di LRI ben formati sono:
lri://world1.wrl/world2.wrl lri://world1.wrl/stuff1.stf
lri://group1.grp/avtar2.grp lri://group1.grp/group2.grp
lri://world1/world2/wolrd3/stuff2.stf
Eventualmente il client (Application Layer) può applicare delle semplificazioni
con la finalità di rendere i nomi ancora più amichevoli: potrebbero
essere previsti il completamento automatico ed i suggerimenti in linea quando
una parte del nome non è coerente con la sintassi.
Per l’assegnazione dei nomi è necessario un Authority, che eventualmente
può coincidere con l’utente stesso.
8.3 PRI: gli identificatori persistenti
Ogni entità è globalmente unica nel sistema da punto di vista concettuale,
è replicata varie volte (repliche fisiche, a basso livello) ed identificata dagli
utenti tramite l’assegnazione di un numero arbitrario di LRI (alias, ad alto
livello). Ogni entità dovrà avere quindi un identificativo unico (URN) e persistente,
assegnato nell’intero universo. L’assegnazione deve essere autonoma
rispetto alla struttura organizzativa che ne detiene la responsabilità.
Tali URN associati all’entità vengono pertanto chiamati identificatori
persistenti della risorsa (PRI, Persistent Resource Identifier).
In figura 8.2 è presente una definizione dei PRI per l’architettura CISA
espressa con il formalismo delle espressioni regolari 1 [Goy06].
urn:pri:(0\.|([1-9][0-9]*)\.)*(0|([1-9][0-9]*))
/[0-9a-zA-Z\-_.,();:=+$!~*’]+
Figura 8.2: Espressione regolare che definisce i PRI in CISA.
In figura 8.3 è riportata una definizione equivalente con notazione BNF.
Si osservi che la definizione prevede l’uso di un set di caratteri derivato
da quello ammesso per gli URI [BLFIM98]. Questo però non esclude la
1 La stringa che la rappresenta è stata suddivisa in due righe per motivi tipografici.
199

Il servizio di risoluzione dei nomi PRI: gli identificatori persistenti
possibilità che, in sviluppi futuri, la classe di stringhe valide per la descrizione
dei PRI venga estesa.
::= "urn:"":"
::= "pri"
::= "/"
::= (dot-number)+
::= (characters)+
::= "."
::= "0" | (+)
::= "1" | "2" | "3" | "4" | "5" |
"6" | "7" | "8" | "9"
::= "0" | "1" | "2" | "3" | "4" |
"5" | "6" | "7" | "8" | "9"
::=
::= ";" | ":" | "=" | "+" | "$" | "," | "-" |
"_" | "." | "!" | "~" | "*" | "’" | "(" |
")" | "a" | "b" | "c" | "d" | "e" | "f" |
"g" | "h" | "i" | "j" | "k" | "l" | "m" |
"n" | "o" | "p" | "q" | "r" | "s" | "t" |
"u" | "v" | "w" | "x" | "y" | "z" | "A" |
"B" | "C" | "D" | "E" | "F" | "G" | "H" |
"I" | "J" | "K" | "L" | "M" | "N" | "O" |
"P" | "Q" | "R" | "S" | "T" | "U" | "V" |
"W" | "X" | "Y" | "Z" | "0" | "1" | "2" |
"3" | "4" | "5" | "6" | "7" | "8" | "9"
Figura 8.3: Sintassi dei PRI in CISA espressa tramite BNF.
La parte ha un formato simile a quello delle net-loc
degli URL, con la differenza che, nel caso in esame, si utilizzano nomi di tipo
numerico separati dal punto. La sequenza di numeri non indica il server in
cui viene prodotta l’informazione, ma il server autoritativo per la risoluzione
da PRI ad URL, di cui sarà affrontata la discussione più avanti nel capitolo.
Ogni volta che nel sistema viene creata un’entità, oltre al nome logico,
viene associato anche un nome di portata locale anch’esso numerico. Il valore
viene assegnato automaticamente dal sistema della risoluzione dei nomi.
Avendo definito quattro tipologie di entità, è possibile sfruttarle per creare
altrettanti sotto-spazi di nomi locali. Ciò consente l’eventuale possibilità di
riutilizzare una parte dell’identificativo locale per entità di tipo diverso.
200

Il servizio di risoluzione dei nomi Logical DNS
Dalla definizione si può notare che effettivamente il PRI è completamente
indipendente dal LRI e dall’URL. Inoltre non è presente nessun riferimento
alla locazione fisica, in quanto si assume che in generale il sistema di
produzione ed il servizio di risoluzione siano mantenuti distinti.
Alcuni esempi di PRI ben formati sono:
urn:pri:1/10 urn:pri:0.0.3/10.2
urn:pri:2.0/qwerty-123 urn:pri:1.1.2/3\(12x)zxcvb
urn:pri:4.7.0.0/4e1243bd22c66e76c2ba9eddc1f91394e57f9f83
8.4 Logical DNS
Gli LRI sono stati introdotti per identificare all’interno dell’ambiente
virtuale le entità logiche Stuff, World, Group e Avatar. Tali identificativi
consentono di indicare le entità presenti all’interno dell’ambiente virtuale
(Virtual Repository di CISA). Il formato degli LRI è definito in modo tale
da essere mnemonico, facilmente usabile dall’utente, riconducibile ad certo
contesto e completamente indipendente dalla locazione fisica delle risorse.
Come mostrato in figura 8.4 è possibile associare più LRI ad uno stesso
PRI. Il PRI è un identificativo univoco utilizzato per riferirsi ad un nodo
della struttura dell’albero del documento.
LRI LRI
PRI
URL URL URL
Figura 8.4: Associazione tra LRI, PRI ed URL.
Una volta che il PRI è stato creato, rimane associato alla risorsa indipendentemente
dal suo tempo di vita: al momento in cui la risorsa abbandona
definitivamente il sistema, il PRI viene comunque mantenuto e non è più
riutilizzabile per nessun altro scopo.
201

Il servizio di risoluzione dei nomi Logical DNS
In analogia al DNS viene introdotto il servizio di risoluzione di un LRI
in PRI: il Logical Domain Name System (LDNS). L’insieme di tutti gli LRI
prende il nome di Logical Name Space (LNSP). L’insieme di nomi è costituito
da due alberi distinti: uno per World e Stuff e l’altro per Group e Avatar.
Dal punto di vista del meccanismo di risoluzione le due strutture sono
trattate in modo equivalente: ciò che è definito per una è facilmente estendibile
all’altra. Viene considerato quindi l’albero costituito dai soli World e
Stuff.
Un esempio dell’organizzazione dello spazio dei nomi è riportato in figura
8.5. Ogni nodo dell’albero rappresenta un World. All’interno di ogni nodo
possono essere contenuti uno o più Stuff. Il numero di nodi, così come il
numero di Stuff in ogni nodo non è prefissato in quanto la creazione dei nomi
dipende dall’attività degli utenti. Rispetto al DNS, dove i nodi di primo
livello risultano predeterminati e di numero molto inferiore rispetto ai nodi
degli altri livelli, si ha la possibilità di creare una struttura arbitraria.
lri://world1.wrl
lri://world1.wrl/ci10.stf
lri://world1.wrl/ci11.stf
lri://
lri://worldZ.wrl
lri://worldZ.wrl/pa3.stf
lri://worldZ/worldA.wrl
lri://worldZ/worldA.wrl/es2.stf
Figura 8.5: Esempio di Logical Name Space.
Il LDNS organizza l’albero rappresentante il LNSP in zone. Si definisce
zona un sotto albero del LNSP contenente almeno un World e tale che per
ogni World contenuto comprenda anche i relativi Stuff. In figura 8.6 è evidenziato
un esempio con una possibile suddivisione in cinque zone. In figura 8.7
202

Il servizio di risoluzione dei nomi Logical DNS
è rappresentato lo stesso albero collassato in zone. Per motivi grafici non
sono riportati gli eventuali Stuff contenuti nei World.
Si definisce albero di zone, quell’albero ottenuto dall’albero del Logical
Name Space attraverso la sostituzione del sotto albero della zona con un
unico nodo, chiamato nodo di zona. Al nuovo albero si applicano tutte le
definizioni di un qualsiasi altro albero, sostituendo la parola nodo con zona.
Ad esempio le definizioni di zona padre e zona figlio sono analoghe a quelle
di nodo padre e nodo figlio. La radice è detta zona top.
La definizione di zona estende quella fornita dalle specifiche del DNS: in
questo caso è necessario associare ai nodi dell’albero anche gli Stuff che questi
contengono, in modo che anch’essi risultino appartenenti alla zona. World e
domini possono essere considerati equivalenti così come i sotto-domini possono
essere paragonati ai sotto-mondi. Infatti è sempre possibile definire un
dominio (World) che sia contenuto all’interno di un altro dominio (World),
mentre gli Stuff possono solamente essere contenuti. Separare uno Stuff
dal proprio World non fornisce nessun vantaggio, anzi si perde il contesto
e l’organizzazione logica dello spazio dei nomi.
Il LDNS è costituito da un vasto database di nomi distribuito su un insieme
di server. In analogia al DNS i server contenenti gli LRI, con i relativi
PRI, sono chiamati Logical Name Server (LNS). Ciascun LNS è responsabile
(autoritativo) di almeno una zona ovvero di un nodo dell’albero delle zone.
Si assume quindi che esista un algoritmo capace di distribuire le zone sull’insieme
dei server ed assegnare ad un Logical Name Server più di una zona da
gestire.
Il LDNS è un servizio distribuito e come tale utilizza, quando necessario,
uno o più LNS per la risoluzione di un LRI. Il sistema è provvisto di un meccanismo
in grado di assicurare la risoluzione di un LRI, qualunque sia il LRI
in oggetto e qualunque sia il LNS utilizzato (si osservi che l’indirizzo di almeno
un LNS deve essere noto al client). Il funzionamento è analogo a quello
del DNS dove ogni computer connesso ad Internet utilizza i DNS assegnati
dal proprio fornitore di accesso, ma potrebbe (autorizzazioni permettendo)
utilizzare uno qualunque dei server DNS presenti in rete.
Consideriamo una generica richiesta verso uno dei LNS. Si possono verificare
i seguenti casi:
1. il server contattato è in grado di risolvere direttamente il nome;
2. il server contattato non è in grado di risolvere direttamente il nome.
203

Il servizio di risoluzione dei nomi Logical DNS
zona 1
W1
W3 W2
W3
W4
W3 W5 W6
W7 W8
W3 W9
zona 3
W10
zona 2
zona top
zona 4 zona 5
Figura 8.6: Esempio di suddivisione in zone del LNSP.
W3
zona top
zona 1 zona 4 zona 5
zona 3 zona 2
Figura 8.7: Esempio di albero delle zone.
204

Il servizio di risoluzione dei nomi Logical DNS
Il primo caso si verifica quando il LRI appartiene alla zona gestita dal
LNS a cui è stata inviata la richiesta, mentre nel secondo caso la risoluzione
necessita di un’ulteriore richiesta, a partire dal LNS in questione, verso il
server LNS autoritativo sul nome. La richiesta viene sottoposta ad alcuni
LNS finché non viene trovato il server autoritativo. Il risultato viene fatto
pervenire al LNS di partenza, il quale si occuperà di rispondere.
Affinché il procedimento illustrato sia fattibile occorre che ogni LNS sia
dotato di una lista di riferimenti verso altri LNS. La lista manterrà le informazioni
sulle zone gestite, cioè su una porzione del Logical Name Space.
Ogni LNS per ogni zona gestita deve mantenere i seguenti riferimenti:
• riferimento al LNS autoritativo per la zona top (radice);
• riferimento al LNS autoritativo della zona padre del LNS corrente;
• riferimenti ai LNS autoritativi delle zone figlio del LNS corrente.
L’algoritmo per la risoluzione di un nome è il seguente:
1. si elimina il nome dell’ultima entità presente in del LRI:
partendo dalla fine del nome si eliminano verso sinistra tutti i caratteri
fino ad incontrare il carattere “/” (compreso);
2. si effettua la nuova ricerca nella lista dei riferimenti:
(a) se esiste un riferimento ad un LNS autoritativo per il LRI, viene
effettuata una richiesta di risoluzione del nome di partenza (quello
completo) verso tale LNS;
(b) se non esiste nessun riferimento si ritorna al passo 1.
Si può notare che nella iterazione al punto 1 è possibile incorrere in lri://
che rappresenta l’Universe del Logical Name Space. Ogni Logical Name Server
contiene nella propria lista un riferimento relativo al server autoritativo
alla zona top.
In conformità allo standard XDI/XRI [Fra05], il meccanismo di risoluzione
prevede due modalità operative: con e senza Look-Ahead. Tali modalità
differiscono nel metodo col il quale viene portato a termine il punto 2.a:
• senza Look-Ahead ogni LNS interpellato propaga la richiesta verso il
server seguente mettendosi in attesa della risposta. In questo modo la
richiesta si propaga attraverso una sequenza di LNS e la risposta segue
il cammino inverso, come mostrato in figura 8.8;
205

Il servizio di risoluzione dei nomi Logical DNS
Figura 8.8: Risoluzione senza Look-Ahead.
• con Look-Ahead ogni LNS interpellato, anziché inoltrare direttamente
la richiesta al server seguente, invia all’elemento che lo precede l’indirizzo
di tale server. In questo modo esiste un elemento centrale che
effettua le richieste ai server di interesse, come mostrato in figura 8.9.
Figura 8.9: Risoluzione con Look-Ahead.
Per comprendere come sono strutturate le liste e l’algoritmo di risoluzio-
206

Il servizio di risoluzione dei nomi Logical DNS
ne è utile considerare la figura 8.7 e procedere con un esempio. Prima di
tutto devono essere definite le liste in accordo alle regole precedentemente
enunciate. Inoltre si supponga che:
• la zona top, la zona 1, la zona 4 e la zona 5 siano gestite da Logical
Name Server distinti a cui, rispettivamente, siano assegnati i nomi di
LNS-top, LNS-1, LNS-4, LNS-5;
• la zona 2 e la zona 3 siano gestite da un unico LNS (LNS-2,3).
Per cui le liste assumono la seguente forma:
1. LNS-top.
2. LNS-1.
3. LNS-4.
4. LNS-5.
• Riferimenti ai LNS autoritativi per le zone figlio:
– riferimento a LNS-1;
– riferimento a LNS-4;
– riferimento a LNS-5.
• Riferimenti ai LNS autoritativi per le zone figlio:
– riferimento al LNS-2,3.
• Riferimento al LNS autoritativo per la zona padre:
– riferimento al LNS-top.
• Riferimento al LNS autoritativo per la zona top:
– riferimento al LNS-top.
• Riferimento al LNS autoritativo per la zona padre:
– riferimento al LNS-top.
• Riferimento al LNS autoritativo per la zona top:
– riferimento al LNS-top.
• Riferimento al LNS autoritativo per la zona padre:
207

Il servizio di risoluzione dei nomi Logical DNS
– riferimento al LNS-top;
• Riferimento al LNS autoritativo per la zona top:
5. LNS-2,3.
– riferimento al LNS-top;
• Riferimento al LNS autoritativo per la zona padre:
– riferimento al LNS-1.
• Riferimento al LNS autoritativo per la zona top:
– riferimento al LNS-top.
Si supponga che il LRI da risolvere sia:
lri://world1/world4/world8.wrl
e che la richiesta venga rivolta a LNS-2,3. LNS-2,3 è autoritativo delle zone 2
e 3, che ovviamente riguardano World diversi da quelli espressi nel LRI preso
in esempio.
Sotto queste ipotesi, LNS-2,3 verifica che lri://world1/world4 non è di
sua competenza, per cui viene inviata una richiesta verso LNS-1 per risolvere
lri://world1/world4/world8.
Da questo punto in poi le modalità con e senza Look-Ahead procedono
in modo diverso:
• Senza Look-Ahead. LNS-1 non è autoritativo, quindi inoltra la richiesta
a LNS-top. Analogamente LNS-top richiede la risoluzione a LNS-5.
LNS-5 è autoritativo sul LRI, per cui la risoluzione avviene e la risposta
ripercorre il cammino inverso:
LNS-5 → LNS-top → LNS-1 → LNS-2,3 → Client.
• Con Look-Ahead: LNS-1 non è autoritativo quindi invia a LNS-2,3
l’indirizzo di LNS-top. LNS-2,3 inoltra la richiesta completa a LNS-top.
LNS-top non è autoritativo quindi invia a LNS-2,3 l’indirizzo di LNS-5.
LNS-2,3 inoltra la richiesta completa a LNS-5 il quale è autoritativo sul
LRI e fornisce a LNS-2,3 la risoluzione.
In figura 8.10 sono riportati i cammini ordinati delle richieste e delle
risposte nei due casi.
208

Il servizio di risoluzione dei nomi Logical DNS
Senza Look-Ahead
Richiesta
Risposta
Con Look-Ahead
Richiesta
Risposta
2 3
1
1
5
2
6
LNS -top
LNS -1 LNS -5
3
4
LNS -2,3
Figura 8.10: Richieste ricorsive per la risoluzione.
4
5
6
209

Il servizio di risoluzione dei nomi Logical DNS
8.4.1 Supporto alla navigazione
Il meccanismo di risoluzione è efficace nell’ipotesi in cui l’utente conosca
esattamente il nome della risorsa alla quale intende accedere. Questo scenario
si presenta in varie circostanze considerando che è l’utente ad assegnare
i nomi e che può farlo seguendo delle proprie convenzioni che possono essere
applicate in qualunque momento anche per risalire al nome della risorsa voluta.
Allo stesso modo niente vieta di ipotizzare che l’utente salvi (ad esempio
in un documento D3IM di sua proprietà) i nomi delle risorse di interesse. Affidare
all’utente l’onere della completa gestione dei nomi però può risultare
un’operazione complessa e oltretutto non permette di sfruttare al meglio le
capacità del sistema gerarchico dei nomi logici.
Per supportare l’utente nella navigazione dello spazio dei nomi il sistema
fornisce la possibilità di effettuare una richiesta di “appartenenza a” su un
world che, come risultato, fornisce la lista degli indirizzi di tutti gli elementi
in esso contenuti. Con questo meccanismo la navigazione nello spazio dei
nomi logici risulta del tutto equivalente a quella su file system.
Si osservi che la complessità di questo tipo di richiesta è poco superiore a
quella di una richiesta di risoluzione. Una volta effettuata la richiesta ad un
server qualunque l’algoritmo di ricerca del server autoritativo sul word è lo
stesso rispetto al caso della risoluzione. Tale server memorizza per ipotesi la
lista degli indirizzi relativi a tutti gli elementi contenuti nel world in esame
e può fornirla al richiedente come avviene per la risposta ad una generica
richiesta di risoluzione.
La complessità può essere superiore in quanto a priori non sono state fatte
ipotesi sul numero di elementi che possono essere contenuti in un world, ma
possono essere previsti dei meccanismi finalizzati a limitare la dimensione
della lista che i vari server devono manipolare.
8.4.2 Espansione del Logical Name Space
Il sistema è composto da un certo numero di server per la risoluzione,
ciascuno dei quali ha in carico un certo numero di zone. Il punto critico del
servizio di risoluzione è la creazione di nuove entità World e Group in quanto
tale operazione determina l’espansione e la gerarchia del Name Space.
A sua volta la suddivisione in zone del Name Space consente di assegnare
l’autorità sui sotto alberi ad opportuni server LNS. Essendo gli Stuff e gli
210

Il servizio di risoluzione dei nomi Logical DNS
Avatar fortemente legati al World ed al Group a cui appartengono, dovranno
essere gestiti dal LNS autoritativo su quel World e Group.
Il procedimento che verrà illustrato per i World è facilmente estendibile
ai Group, ed ulteriormente semplificato nel caso della creazione di Stuff e
Avatar, grazie alle precedenti considerazioni.
È importante premettere che solo l’Avatar con gli opportuni permessi
potrà creare un nuovo World all’interno di uno già esistente. Ovviamente si
assume che l’Universe (la radice del Name Space) esista ed abbia già un LNS
che la risolve.
Per semplicità si consideri nuovamente la figura 8.6 e si supponga che esista
lri://W1/W4/W8 entro cui si vuole creare il World lri://W1/W4/W8/W11.
Affinché l’operazione abbia successo deve:
• essere creata e memorizzata l’entità;
• essere aggiornato il database dei nomi.
Una volta che l’entità lri://W1/W4/W8/W11 è stata creata, deve essere resa
indirizzabile, così che la sua esistenza risulti effettiva (solo successivamente è
individuabile e quindi da ritenersi esistente), chiedendo al sistema LDNS la
gestione del nome.
Le conseguenze possibili, relative alla gestione della porzione di LNSP che
inizia da lri://W1/W4/W8/W11, sono le seguenti:
• estensione di una zona: lri://W1/W4/W8/W11 entra nella zona 5, per
cui sarà gestito da LNS-5;
• partizione di una zona esistente: si crea la zona 6 con la relativa
assegnazione ad un LNS.
Si può osservare che, dal punto di vista dell’Avatar creatore, tutto dovrebbe
semplicemente ridursi ad una richiesta al servizio LDNS:
Add-New-World(lri://W1/W4/W8/W11)
con risposta positiva o di errore.
Nel caso in cui debba essere creata una nuova zona, tra i vari meccanismi
mascherati all’Avatar, interni al sistema LDNS, vi sarà quello che stabilisce
quale server LNS gestirà la nuova zona. Il principale server candidato per
l’autorità è quello, tra i disponibili, che risulterà più “vicino” alla sorgente di
informazione in oggetto.
211

Il servizio di risoluzione dei nomi Logical DNS
La disponibilità di un server può essere stabilita impostando soglie sul
carico di lavoro sopportato: un compromesso tra numero di accessi consentiti
per unità di tempo e massimo numero di entità risolvibili. Il concetto di
vicinanza non è tanto riferito alla distanza geografica, quanto alla capacità
dei collegamenti. In un sistema di comunicazione la banda disponibile e il
tempo di round-trip [KR03] giocano un ruolo non indifferente nell’usabilità
delle applicazioni di rete.
Aggiornamento del database
Ogni server LNS ha nella sua configurazione i riferimenti ai server figlio,
e questi conoscono almeno l’indirizzo del LNS server autoritativo sulla radice
dell’albero del Logical Name Space; a partire da queste informazioni è possibile,
man mano che l’albero dei LRI si espande, coprirlo con un processo di
auto-configurazione.
Volendo menzionare un esempio, nel momento in cui un Avatar richiede
Add-New-World(lri://W1/W4/W8/W11), interagendo con un LDNS, dà inizio
ad una catena di richieste che, in un numero finito di passi, incorre nel server
autoritativo di lri://W1/W4/W8 (in questo caso LNS-5). LNS-5 può accollarsi
la gestione del nuovo World oppure delegarla ad un server di più basso livello
nella gerarchia.
All’inizio lo spazio dei nomi è vuoto ovvero il LNSP è costituito dalla
sola radice ed esiste un solo server LNS capace di risolvere in PRI gli LRI
del tipo lri://something.ext. Complessivamente nel sistema sono già stati
installati altri server LNS, che però non hanno ancora in carico nessuna zona.
Quando un Avatar desidera creare un nuovo World (W_new), deve indicare
il World (W_parent) destinato a contenerlo e richiedere la registrazione ad
uno dei server LNS. Una volta identificato ricorsivamente il LNS che ha il
compito di risolverlo, questo deve:
• mantenere il PRI per la risoluzione;
• comunicare al LNS autoritativo su W_parent che lui è autoritativo per
il nuovo World (W_new);
• rispondere alla richiesta di creazione.
Procedendo di questo passo, si popola l’albero dei nomi e vengono configurati
automaticamente tutti i server. Il procedimento garantisce la distribuzione
del database dei nomi e la consistenza della risoluzione.
212

Il servizio di risoluzione dei nomi Localization Service
8.4.3 Proprietà
Il Logical Domain Name System, per come è stato definito e per la forte
analogia con il DNS, può vantare le seguenti proprietà:
• garantisce la risoluzione di tutto il Logical Name Space;
• è facilmente estendibile;
• è scalabile;
• è facilmente aggiornabile;
• è rapido nelle modifiche al LNSP.
Alle precedenti proprietà si può aggiungere la tolleranza ai guasti ridondando
gli apparati costituenti il sistema. Si possono introdurre, così come
avviene per il DNS, dei server LNS secondari. In questo modo i server si
classificano non solo in base al livello a cui appartengono, ma anche alla
distinzione tra server primari e secondari.
È importante osservare che la scalabilità di LDNS è di minore portata
rispetto a quella del DNS, in quanto il primo permette una totale libertà
nella creazione dei nodi già a partire dal primo livello. Si ricorda che nel
DNS i nodi di primo livello sono prefissati e limitati nel numero. Tale libertà
potrebbe portare ad una crescita non efficiente dell’albero, ma d’altra parte
è un eventuale rischio che vale la pena correre per consentire una gestione
più rapida nella creazione e nella modifica del LNSP.
8.5 Localization Service
Nel precedente paragrafo è stato affrontato il problema della risoluzione di
un LRI in PRI. Ora è necessario definire un servizio che consenta la risoluzione
di PRI in URL: tale servizio prende il nome di Localization Service (LS).
Al fine di introdurre l’architettura di LS, è conveniente fare riferimento
al formato dei PRI definito in figura 8.3. La parte è
simile a quella delle net-loc degli URL, con la differenza che i nomi sono
stringhe di numeri separate da un punto.
La scelta del formato consente di organizzare il servizio LS attraverso una
struttura ad albero come quella mostrata nell’esempio di figura 8.11. Ciò è
efficace per ottenere la massima espandibilità, scalabilità e garanzia di una
213

Il servizio di risoluzione dei nomi Localization Service
risoluzione distribuita di tutti gli identificativi in URL, in modo del tutto
analogo al DNS.
0
0.0 1.0
0.0.0
0.1.0
1
0.1
Figura 8.11: Esempio di LS.
Ogni server LS è autoritativo per tutti i PRI che hanno come parte
il nome del server stesso. La prima cifra a partire
da destra rappresenta la radice (server top) della gerarchia dei server LS. Le
cifre successive, da destra verso sinistra, indicano i server di livello inferiore.
Analogamente al LDNS, anche per il Localization Service le richieste possono
essere effettuate ad un qualsiasi server. Affinché il processo di risoluzione
dei PRI vada a buon fine ogni server LS top deve mantenere una lista di
riferimento verso gli altri server top.
Analogamente a LDNS devono essere definite delle liste di riferimenti
contenenti:
• il riferimento al server padre;
• i riferimenti ai server figlio;
• il riferimento al server top.
Nel caso in cui il server LS interrogato non sia autoritativo sui PRI richiesti
è possibile, grazie ai riferimenti nelle liste, raggiungere il server LS
autoritativo. La catena della risoluzione è simile a quella presentata per il
LDNS in figura 8.10, dove però i server in gioco sono LS.
Le considerazioni ed il confronto tra LS e DNS sono quasi equivalenti a
quelle già esposte riguardo a LDNS e DNS. Nel caso LS la scalabilità del
sistema è esattamente paragonabile a quella del DNS, visto che è possibile
214

Il servizio di risoluzione dei nomi Risoluzione inversa
affidare allo stesso sistema la decisione su quanti nuovi server radice creare
e quando crearli. Inoltre la procedura di aggiornamento risulta semplificata,
dato che non esiste il concetto di zona. La distribuzione può essere calcolata
per ottimizzare la ricerca e l’aggiornamento.
8.6 Risoluzione inversa
La risoluzione inversa deve essere tale da consentire la risalita da un URL
ai corretti LRI.
Anche in questo caso il meccanismo deve essere suddiviso in due stadi
(figura 8.12):
1. risoluzione inversa da URL a PRI;
2. risoluzione inversa da PRI a LRI.
LRI LRI
PRI
URL URL URL
Figura 8.12: Schema per la risoluzione inversa.
Riferendosi allo spazio dei nomi in generale, al fine di effettuare la risoluzione
inversa, può risultare conveniente adottare lo stesso principio del
reverse lookup del DNS, in quanto tale tecnica:
• è efficace;
• sfrutta l’infrastruttura utilizzata per la risoluzione diretta.
Nel DNS gli IP sono riformulati a livello logico sotto uno speciale dominio,
chiamato in-addr.arpa. Il reverse lookup viene visto come una risoluzione
215

Il servizio di risoluzione dei nomi Risoluzione inversa
diretta. Supponendo che un client voglia conoscere un hostname associato a
192.0.2.25 formula una richiesta di risoluzione diretta di 25.2.0.192.inaddr.arpa.
Il meccanismo, riferito all’esempio di conversione IP in hostname, è il
seguente:
• il resolver DNS inverte la notazione decimale dell’IP e l’aggiunge a
.in-addr.arpa: 25.2.0.192.in-addr.arpa;
• il resolver cerca il record per 25.2.0.192.in-addr.arpa;
– il resolver DNS chiede la risoluzione di 25.2.0.192.in-addr.arpa
al server radice;
– il server radice formula la richiesta al server autoritativo sulla
classe A, la quale copre gli IP che iniziano per 192 (192.inaddr.arpa);
– la catena di richieste prosegue fino a quando non viene raggiunto
il server autoritativo su 25.0.2.192.in-addr.arpa;
– il server autoritativo risponde con l’hostname.
Per quanto concerne la risoluzione da URL a PRI questo metodo non è
direttamente attuabile a causa del formato dei nomi in esame, ma, relativamente
all’architettura CISA, esiste un altro metodo molto efficiente che
permette di ottenere il PRI richiesto senza chiamare in causa i server di risoluzione.
Noto l’URL è infatti sufficiente accedere alla replica dell’informazione
che, se è un elemento definito nello spazio delle informazioni D3IM ha,
al proprio interno memorizzato per ipotesi, l’indirizzo PRI che la identifica
univocamente.
Noto l’URL è quindi sufficiente accedere alla replica ed estrarre l’indirizzo
richiesto.
Una volta ottenuto il PRI deve avvenire il secondo passo della risoluzione
inversa per determinare gli LRI. Le associazioni “” vengono
memorizzate nel server LS autoritativo sul PRI in modo equivalente alle associazioni
“” utilizzate per la risoluzione diretta. In questo modo
l’algoritmo di risoluzione inversa da PRI in LRI è equivalente a quello descritto
per la risoluzione diretta; l’unica differenza consiste nel fatto che il server
autoritativo sul PRI reperisce una tipologia di associazioni anziché l’altra.
216

Il servizio di risoluzione dei nomi Risoluzione inversa
Un problema di cui occorre prendere atto è che deve essere garantita la
consistenza fra le associazioni “”, presenti nei vari server LDNS
autoritativi sugli LRI associati al PRI, e quelle “” presenti sul
server LS autoritativo sul PRI.
Questa osservazione è utile per introdurre un secondo problema che deve
essere affrontato e risolto. Gli spazi dei nomi sono stati definiti in modo
da garantire la scalabilità del sistema al crescere del numero degli stessi. In
particolare possono essere associati un numero arbitrario di LRI ad un PRI
in quanto è possibile ripartire l’onere della loro risoluzione su di un numero
alto a piacere di server LDSN. Anche il numero di PRI esistenti nel sistema
può crescere, a patto di far crescere in modo equivalente il numero di server
LS per la relativa risoluzione in URL.
Si osservi che il numero di URL associato ad un determinato PRI non
può crescere a piacere in quanto tali URL, per le ipotesi operative fatte,
sono tutti memorizzati nel server LS autoritativo sul PRI. La capacità di
memorizzazione, la potenza computazionale e la velocità di connessione alla
rete di un unico sistema non possono essere rese grandi a piacere a causa
dei limiti tecnologici esistenti. Nel caso specifico questo non rappresenta un
problema in quanto il numero di URL associate ad un PRI equivale al numero
di repliche dell’informazione identificata da tale PRI e pertanto, anche se non
è corretto stabilire un valore massimo ammissibile a priori, questa grandezza
può essere tenuta sotto controllo.
Viceversa il numero di LRI associati ad un PRI è una grandezza sulla
quale non può essere fatta alcuna ipotesi e che può essere quindi arbitrariamente
grande. In riferimento al problema introdotto in precedenza il numero
di associazioni “” presenti nel server LS autoritativo sul PRI può
essere quindi arbitrariamente grande vanificando tutte le ipotesi di scalabilità
dello spazio dei nomi.
Per minimizzare l’impatto di questo inconveniente sono state individuate
due strade alternative che eventualmente possono essere percorse entrambe:
• suddivisione degli LRI in due categorie:
– LRI risolvibili inversamente partendo dal PRI associato;
– LRI non risolvibili inversamente partendo dal PRI associato;
• risoluzione inversa iterativa.
217

Il servizio di risoluzione dei nomi Risoluzione inversa
La prima soluzione prevede la definizione di due tipologie di nomi logici
in modo da poter escludere tutti quei nomi per i quali non c’è interesse ad
effettuare la risoluzione inversa. In questo modo si riduce il numero assoluto
di elementi da trattare, ma non è comunque possibile dare delle garanzie sul
numero di elementi per i quali la risoluzione inversa è necessaria, pertanto il
problema non può considerarsi risolto.
La seconda soluzione permette di introdurre un limite superiore al numero
di coppie “” presenti in ogni server LS. Il nome “risoluzione
inversa iterativa” deriva dal fatto che per portare a termine l’operazione il
client deve effettuare iterativamente un certo numero di richieste. Per ogni
richiesta il server LS autoritativo sul PRI da risolvere è diverso. In questo
modo il carico di lavoro e la capacità di memorizzazione possono essere distribuiti
su un numero di server sufficientemente elevato al fine di garantire
l’efficacia e l’efficienza dell’operazione.
Vista delle righe di interesse
della tabella con le associazioni
“” nel server LS
autoritativo su “0”
PRI LRI o Partizioni
urn:pri:0/da_risolvere
lri://1
urn:pri:0/da_risolvere lri://2
urn:pri:0/da_risolvere lri://3
urn:pri:0/da_risolvere urn:pri:1/partizione2
Vista delle righe di interesse
della tabella con le associazioni
“” nel server LS
autoritativo su “1”
PRI LRI o Partizioni
urn:pri:1/partizione2
lri://4
urn:pri:1/partizione2 lri://5
urn:pri:1/partizione2 urn:pri:2/partizione3
urn:pri:1/partizione2 urn:pri:3/partizione4
Figura 8.13: Tabelle necessarie per la risoluzione inversa iterativa.
Il meccanismo sul quale si basa la risoluzione inversa iterativa è molto
semplice. L’insieme di LRI associati al PRI di interesse viene partizionato in
un numero sufficientemente grande di sottoinsiemi i quali vengono distribuiti
su server LS distinti. Il client effettua un richiesta di risoluzione inversa per
ogni partizione. Ad ogni sottoinsieme viene assegnato un indirizzo PRI che
218

Il servizio di risoluzione dei nomi Risoluzione inversa
per il primo sottoinsieme coincide con il PRI di cui è richiesta la risoluzione
inversa.
Quest’ultima ipotesi, se il numero di associazioni “” è sufficientemente
basso, permette di ricondurre il caso della risoluzione inversa
iterativa al caso più semplice introdotto all’inizio di questo paragrafo.
In quest’ultimo caso la risoluzione avviene nel modo convenzionale: il
client effettua la richiesta sul PRI di interesse e si vede recapitare l’insieme
completo di LRI associati.
Supponendo invece di superare il numero massimo di coppie gestibili da
un unico server LS, entra in gioco il meccanismo di partizionamento. Viene
generato un nuovo PRI e viene associato ad esso il gruppo di LRI in eccesso.
In riferimento alla figura 8.13 il PRI di cui è richiesta la risoluzione inversa
è urn:pri:0/da_risolvere. Il client effettua la richiesta di risoluzione che,
tramite i medesimi meccanismi descritti per la risoluzione diretta, giunge
al server LS autoritativo sul PRI. Il server restituisce la lista di elementi
associati al PRI (nello specifico sono tre LRI: lri://1, lri://2 e lri://3)
e l’insieme di PRI che identificano le partizioni note al server LS (in questo
caso urn:pri:1/partizione2).
Il client procede iterativamente con la risoluzione dei PRI che identificano
le varie partizioni e, nell’esempio, richiede la risoluzione dell’indirizzo ricevuto
con la risposta al passo precedente: urn:pri:1/partizione2. Siccome il
server autoritativo in questo caso è 1, l’algoritmo è effettivamente distribuito.
La risposta a questa richiesta di risoluzione contiene altri due indirizzi LRI
da associare al PRI iniziale (lri://4 e lri://5) e gli indirizzi di altre due
partizioni.
Si osservi che tramite una scelta oculata dei PRI delle partizioni è possibile
realizzare un albero. Partendo da uno specifico PRI questo aspetto
mette il client nelle condizioni di individuare, se esiste, un particolare indirizzo
LRI associato a tale PRI con un numero di iterazioni che cresce in
modo logaritmico rispetto al numero complessivo di LRI associati al PRI di
partenza.
Questo è possibile assegnando i nomi alle partizioni in modo coerente
al loro contenuto. Per esempio si può pensare di creare un primo livello
di partizioni costituito da due sottoinsiemi identificati rispettivamente dai
seguenti PRI:
• urn:pri:1/partizione_0-9A-M;
219

Il servizio di risoluzione dei nomi Risoluzione inversa
• urn:pri:1/partizione_N-Z;
contenenti tutti gli LRI il cui inizia con un carattere nell’intervallo
A-M e numeri o N-Z rispettivamente. In questo esempio gli
LRI:
• lri://dati/...;
• lri://ANNI/...;
• lri://123/...;
appartengono alla prima partizione, mentre:
• lri://Utenti/...;
• lri://zn5n2f20th1/...)
appartengono alla seconda.
Procedendo ricorsivamente è possibile suddividere ulteriormente le partizioni
in sotto partizioni, per la prima ad esempio:
• urn:pri:1/sottopartizione_0-9;
• urn:pri:1/sottopartizione_A;
• urn:pri:1/sottopartizione_B;
• urn:pri:1/sottopartizione_...;
• urn:pri:1/sottopartizione_M)
e così via.
Si noti che il server autoritativo relativo ad ogni partizione è sempre
1. Questo perché, se il carico lo permette, non è necessario suddividere le
partizioni fra server LS distinti. Nell’esempio i primi due livelli dell’albero
delle partizioni sono mantenuti sullo stesso server LS mentre i sotto livelli
successivi potrebbero essere inseriti in server diversi.
La verifica dell’esistenza di LRI associati ad uno specifico PRI può risultare
particolarmente utile in un’ottica di salvaguardia della privacy e dell’equo
trattamento dei dati personali in quanto è uno strumento che permette all’entità,
a cui i dati sensibili sono riferiti, di controllare chi li gestisce (operazione
che avviene indirettamente conoscendo i nomi logici) ed eventualmente
di individuare se una particolare organizzazione li sta gestendo.
220

Il servizio di risoluzione dei nomi Ottimizzare le prestazioni
8.7 Ottimizzare le prestazioni
Il caching del DNS è ampiamente utilizzato per migliorare le prestazioni
rispetto al ritardo e per ridurre il numero di messaggi DNS nella rete. L’idea
è molto semplice: quando un server dei nomi riceve una correlazione per
qualche hostname, esso la deposita nella sua memoria locale (di massa o
volatile), mentre il messaggio attraversa la catena dei server di nomi.
Data una correlazione hostname/IP, memorizzata in cache, se al server
dei nomi arriva una successiva richiesta per lo stesso hostname, esso può
fornire l’IP desiderato anche se non è autoritativo. Questi dati solitamente
vengono cancellati dopo un certo tempo (dell’ordine di giorni).
Per entrambi i servizi di risoluzione può essere utile dotare ogni server
(LDNS e LS) di una cache del tutto simile a quella del DNS. Però se le
modifiche allo spazio dei nomi logici risultano molto frequenti, la cache può
causare problemi nel raggiungere le risorse desiderate.
Consideriamo la seguente condizione critica:
• nel sistema viene cancellata un’entità nell’ambiente virtuale. In realtà
l’entità continua a sopravvivere, si ricordi che il suo PRI è persistente.
La cancellazione opera solo a livello logico;
• un qualche LNS non autoritativo ha in cache i valori necessari per la
risoluzione dell’entità cancellata;
• in un secondo tempo viene creata una nuova entità con lo stesso nome
logico.
Sotto queste ipotesi una richiesta di risoluzione, che si imbatte nel LNS in
oggetto, ha associata una risposta che indica una risorsa non più valida.
Per risolvere il problema possono essere trascurate, sotto opportune ipotesi,
le informazioni presenti in cache, ad esempio introducendo un tipo di
richiesta specifico per lo scopo. È ipotizzabile l’uso di un opportuno dimensionamento
dei tempi di permanenza in cache oppure potrebbero essere
previsti protocolli per il mantenimento della coerenza, ad esempio basati su
un catalogo. Le varie alternative dovranno essere oggetto di studio in sviluppi
futuri.
221

Capitolo
9
Protocolli di comunicazione e
architettura di rete in CISA
9.1 Interfacce e protocolli
CISA è un’architettura implementata tramite una griglia di calcolatori
che ospitano processi, è un sistema distribuito il cui stato evolve nel tempo.
L’evoluzione temporale è guidata dal fatto che si verificano eventi (come ad
esempio azioni dell’utente o richieste di servizio provenienti dalla rete) che
determinano l’attivazione dei processi che la costituiscono. Come evidenziato
in precedenza, nel momento in cui un processo sta operando, ha la necessità
di comunicare con altri processi, per richiedere servizi, necessari per portare
a termine la propria mansione.
L’interazione fra i processi in gioco, entità di livello applicativo della pila
ISO/OSI, avviene tramite scambio di messaggi spediti attraverso la rete
sfruttando i servizi messi a disposizione dal livello OSI sottostante.
Affinché tale interazione risulti possibile occorre comunque definire specifici
protocolli di comunicazione di livello applicativo che permettono la
comunicazione end-to-end fra i processi in gioco.
A tal proposito si consideri la seguente definizione, riportata in [KR03]:
“Un protocollo definisce il formato e l’ordine dei messaggi

Protocolli di comunicazione e architettura di rete in CISA Interfacce e protocolli
scambiati tra due o più entità comunicanti, così come le azioni
che hanno luogo a seguito della trasmissione e/o ricezione di
un messaggio o di altri eventi”.
Questa definizione evidenzia quindi una duplice natura del protocollo: da
un lato è necessario definire sintatticamente i messaggi scambiati fra le entità
che comunicano (natura statica); dall’altro occorre definire come tali entità
debbano comportarsi a seguito dei messaggi che vengono scambiati (natura
dinamica).
Processo X
Logica di
controllo del
servizio A
Gestione del
protocollo di
livello
applicativo
Comunicazione
end-to-end
Rete
Interfaccia Trasporto
(Socket)
Processo Y
Logica di
controllo del
servizio B
Gestione del
protocollo di
livello
applicativo
Figura 9.1: Bidimensionalità dell’interfaccia fra processi.
In CISA sono state definite varie tipologie di servizio ed è necessario
introdurre dei protocolli finalizzati a regolare l’interazione fra i client e i
processi server che li forniscono. La tipologia di servizio e il tipo di protocollo
associato sono, ovviamente, entità correlate. Il protocollo, in altre parole,
permette la comunicazione fra client e server attraverso un’interfaccia ben
definita e specificata per lo scopo.
L’interazione fra i vari sistemi che costituiscono CISA è tendenzialmente
client/server e basata su un approccio REST-like: i protocolli definiti per la
gestione di questo tipo di paradigma di comunicazione sono, come HTTP,
request/response.
223

Protocolli di comunicazione e architettura di rete in CISA Interfacce e protocolli
In riferimento alla figura 9.1 il processo può essere visto come entità
stratificata:
• Logica di controllo del servizio. Si tratta dello strato superiore e si occupa
di gestire il funzionamento del processo (finalizzandone lo scopo
all’espletamento di un particolare servizio). Prescindendo dagli aspetti
implementativi del trasporto e della sintassi dei messaggi, si occupa
esclusivamente del loro aspetto semantico.
• Gestione del protocollo di livello applicativo. Si tratta dello strato inferiore
e si occupa della gestione dei messaggi a più basso livello (sintassi).
Inoltre si occupa di interfacciarsi alla rete e gestire la comunicazione
con gli altri processi.
Un primo vantaggio che deriva da questo approccio è che risulta possibile
definire ed implementare la logica di controllo indipendentemente dalla
strategia utilizzata per il trasporto dei messaggi in rete. Questo permette di
prevedere algoritmi di gestione del processo di trasporto operanti in modo
diverso ed interscambiabili. Ad esempio uno di essi potrebbe utilizzare un
socket TCP ed inoltrare i messaggi byte per byte; un altro li potrebbe incapsulare
nella loro interezza in un messaggio HTTP; un altro ancora potrebbe
utilizzare SMTP 1 e così via (HTTPS, FTP, etc.).
Risulta possibile inoltre implementare la logica di controllo anche prescindendo
dal sistema operativo in uso e conseguentemente questa, fissato un
particolare linguaggio di programmazione, è platform-indipendent.
Il sottosistema dedicato alla gestione del protocollo di livello applicativo
deve interfacciarsi con il sistema operativo (del calcolatore che ospita il
processo) per l’accesso alla rete. Questa operazione avviene ricorrendo a specifiche
librerie, dipendenti dal linguaggio di programmazione e in alcuni casi
dalla piattaforma, che mettono a disposizione del programmatore predeterminate
interfacce software (API) finalizzate ad utilizzare i servizi messi a
disposizione dal layer OSI sottostante.
Con le premesse di cui sopra l’eventuale indipendenza delle librerie dalla
piattaforma è una caratteristica che permette di assicurare, fissato il linguaggio,
l’indipendenza dalla piattaforma del codice sorgente relativo a tutto il
1 La scelta di SMTP non è stata casuale (è possibile ricorrere anche ad altri protocolli)
in quanto si può ipotizzare l’esistenza di particolari messaggi di importanza rilevante che
potrebbero essere inoltrati per posta elettronica certificata e che avrebbero quindi anche
valenza giuridica.
224

Protocolli di comunicazione e architettura di rete in CISA Interfacce e protocolli
processo. In riferimento alla pila Internet, considerando la semplicità dell’interfaccia
che questa mette a disposizione al livello applicativo (socket),
è comunque prevedibile che il porting [Por06] da una piattaforma all’altra
sia un’operazione poco costosa, a patto di ricorrere ad una programmazione
oculata (in implementazioni object-oriented sfruttando alcuni dei Pattern di
programmazione più noti in letteratura [GHJV95]).
I processi che costituiscono CISA sono interconnessi tramite rete pertanto
ognuno di essi, sia che appartenga a servizi diversi oppure allo stesso servizio,
può essere implementato secondo strategie differenti a patto di rispettare le
specifiche del protocollo di intercomunicazione. Tali strategie forniscono la
possibilità di scegliere il linguaggio e lo stile di programmazione, il sistema
operativo e la piattaforma hardware dell’host.
Modifiche più sostanziali che influenzano il funzionamento della logica di
controllo sono altresì possibili, anche se risultano operazioni più complesse.
In questo caso occorre aggiornare il protocollo in esame in modo da rendere
esplicite all’esterno le modifiche comportamentali dell’entità.
Una fase iniziale di handshaking (esplicita o implicita) permette ai due
processi interessati alla comunicazione di stabilire con quale versione del protocollo
dialogare. Se la scelta ricade sulla versione precedente è perché uno
dei due processi non è aggiornato e l’altro, affinché la comunicazione sia possibile,
può adeguarsi comportandosi secondo le modalità operative precedenti.
Viceversa, se la scelta ricade sull’ultima versione, entrambi i processi sono
aggiornati e pertanto possono utilizzare il nuovo protocollo e comportarsi
secondo le nuove modalità.
9.1.1 Interfaccia bidimensionale
Come già anticipato, all’interno del processo sono stati individuati due
sottosistemi distinti: una logica di controllo, che si occupa di implementare
le funzionalità richieste dall’applicazione, ed un sistema dedicato alla gestione
della comunicazione.
Tale sistema si inquadra come sotto-livello di applicazione della pila OSI
posizionato a contatto con l’interfaccia inferiore del livello. In realtà alcune
delle funzioni espletate sono individuabili all’interno del livello presentazione
di OSI, ma dettagliare la descrizione a tal punto non è vantaggioso. Conviene
considerare il sistema dedicato alla gestione della comunicazione come
unica entità appartenente al livello applicativo di OSI e non suddividerlo ul-
225

Protocolli di comunicazione e architettura di rete in CISA Interfacce e protocolli
teriormente in due sottosistemi uno di livello applicativo e l’altro di livello
presentazione.
L’acronimo IACS, Inter-Application Communication System è stato ideato
per riferirsi al sistema dedicato alla gestione della comunicazione fra i
processi (ovvero le applicazioni).
Quindi all’interno di un processo è possibile individuare due interfacce distinte
(si faccia riferimento alla figura 9.2, nella quale sono state “localizzate”
anche le rispettive API):
• Interfaccia (inferiore) fra processo (in particolare IACS) e sistema operativo:
questa interfaccia permette l’invio e la ricezione dei dati ed è
utilizzabile ricorrendo alla specifica API messa a disposizione tramite
opportune librerie (normalmente fornite dal sistema operativo stesso).
• Interfaccia (superiore) fra logica di controllo e IACS: questa interfaccia,
ragionando in modo equivalente al caso precedente, permette alla logica
di controllo di scambiare messaggi, entità più astratta rispetto all’invio
e alla ricezione dei dati discussi al punto precedente, ricorrendo alla
specifica API messa a disposizione da IACS.
In questi termini è opportuno pensare di implementare sotto forma di libreria
gli IACS relativi ai vari protocolli. Questa soluzione è quella più logica
e più efficiente, ma non è l’unica. In particolare, qualora il numero di sistemi
operativi e di linguaggi di programmazione si frammentasse eccessivamente,
dando vita ad un numero di varianti elevato per le quali mantenere separate
le implementazioni delle varie librerie dovesse diventare un’operazione troppo
costosa, è possibile realizzare un’implementazione stand-alone di IACS raggiungibile
via rete tramite RPC (Remote Call Procedure). In questo modo,
a patto di ricorrere ad un meccanismo per RPC standardizzato ed aperto,
il sistema IACS risulta del tutto svincolato dalla logica di controllo e quindi
i due sistemi, adesso considerati strettamente correlati, diventerebbero
indipendenti e implementabili in modo autonomo.
Prendendo come esempio il caso riportato in figura 9.2 è possibile entrare
più nel dettaglio della descrizione dell’interfaccia fra logica di controllo ed
IACS e della descrizione di tale dispositivo.
L’API fornita da IACS mostra alla logica di controllo le primitive del
protocollo sotto forma di interfaccia software: nell’esempio get(lri); e
put(doc);. Invocando tali primitive la logica di controllo effettua delle
operazioni che, a livello concettuale, sono request.
226

Protocolli di comunicazione e architettura di rete in CISA Interfacce e protocolli
Logica di Controllo
del servizio
Politiche di gestione del protocollo
IACS
response(msg);
Response
Processo X
Request
get(lri); put(doc);
Politiche di gestione del protocollo
Generazione, ricezione e gestione
messagggio serializzato
Gestione del trasporto a
basso livello (gestione
socket, incapsulamento
su HTTP, etc.)
Client
Request
Rete
Server
Figura 9.2: Inter-Application Communication System.
IACS dispone di una logica interna che gli fornisce la facoltà di interpretare
le richieste ed operare di conseguenza. Il caso più semplice è quello nel
quale il processo client dispone soltanto del socket Client (in basso a destra
nella figura) aperta all’avvio del sistema che interconnette in modo persistente
tale processo con il processo server relativo al servizio che intende
richiedere. Il processo server, dualmente, dispone soltanto del socket Server.
Il meccanismo di funzionamento, a seguito di una richiesta proveniente dalla
logica di controllo, è il seguente:
• la politica di gestione del protocollo permette di creare il messaggio da
inviare al server;
Socket
Socket
API
API
227

Protocolli di comunicazione e architettura di rete in CISA Interfacce e protocolli
• il messaggio viene convertito in forma serializzata, eventualmente ricorrendo
alla firma digitale e/o alla crittografia per un invio sicuro;
• il sistema è in grado di effettuare l’invio sulla rete, byte per byte,
incapsulando il messaggio ad esempio in HTTP, etc. come esposto
precedentemente;
• l’altro processo riceve dalla rete le informazioni inviate ed effettua
le operazioni descritte in senso opposto fino ad invocare la primitiva
richiesta sulla logica di controllo;
• viene generata la response la quale ritorna al mittente seguendo il
percorso inverso.
All’atto pratico la logica di controllo client invoca il metodo remoto corrispondente
alla primitiva del protocollo che intende chiamare sulla logica di
controllo server. Questo meccanismo è del tutto equivalente a quello che si
verifica richiamando, attraverso il browser web, una pagina residente su un
server web tramite il protocollo HTTP. Supponendo che la richiesta sia una
GET tutto succede come se il server web, al momento della ricezione del messaggio
inviato dal client, invocasse un metodo interno GET(parametri); dove
i parametri sono rappresentati da tutte le opzioni previste ed inviate nella
richiesta tramite HTTP. Il risultato della chiamata è esattamente la pagina
richiesta che viene spedita al client, operazione associabile a sua volta ad una
RPC nella quale il server invoca sul client il metodo response(pagina);. Il
corpo di questa funzione definita nel client provvede ad avviare la procedura
di visualizzazione della pagina all’utente.
Si osservi che ogni server deve essere in grado di gestire richieste provenienti
da più di un client (in generale da un qualunque altro processo presente
in rete). Questo aspetto viene tenuto in considerazione durante la progettazione
del IACS. Il sistema resta in ascolto in rete ed applica il multiplexing
delle richieste in arrivo per processarle sequenzialmente (eventualmente applicando
opportune politiche di gestione quali code con priorità); dualmente
effettua un demultiplexing delle risposte per inoltrarle al corretto destinatario.
In contrapposizione è possibile implementare il sistema affinché questo
utilizzi un thread diverso per ogni client che richiede il servizio, ottenendo un
avanzamento parallelo dell’elaborazione: questo è il caso in cui sono presenti
più serventi. Nella pratica verrà utilizzata una strategia mista limitando, con
opportune politiche, il numero massimo di thread utilizzabili: se le richieste
228

Protocolli di comunicazione e architettura di rete in CISA L’architettura di rete
contemporanee sono in un numero inferiore a quello massimo prestabilito
vengono elaborate in parallelo, altrimenti attendono in coda. Infine, se il
carico è ritenuto eccessivamente alto, potrebbero essere addirittura rifiutate.
Nel paragrafo successivo verrà descritto un esempio di IACS più articolato
che permette di evidenziare ulteriormente la flessibilità di questa soluzione.
9.2 L’architettura di rete
Lo scenario presentato nei paragrafi precedenti evidenzia come CISA sia
un’architettura totalmente distribuita e realizzata tramite l’interconnessione
di processi in rete. Un’organizzazione che intende utilizzare CISA deve
disporre di un’adeguata infrastruttura hardware/software la quale, oltre a
permettere l’accesso alle risorse fornite da altre organizzazioni, permette di
fornire essa stessa risorse all’esterno secondo lo stesso principio utilizzato
nelle reti peer-to-peer. Il principio è il medesimo, ma all’atto pratico non è
corretto parlare di CISA come rete peer-to-peer in quando l’infrastruttura
è comunque orientata ai servizi fruibili tramite il paradigma client/server.
L’associazione con le reti peer-to-peer è valida da un punto di vista logico in
quanto l’aggiunta di middelware nella rete permette di estenderne le potenzialità
e i nuovi dispositivi avranno gli stessi “diritti e doveri” degli apparati
equivalenti già presenti. Per completare la similitudine si può pensare ad un
“macro-client”, il cui utente è un’organizzazione, che espleti tutte le funzioni
di CISA: quando l’organizzazione“apre”il proprio macro-client (attiva quindi
tutti i servizi CISA) si proietta in rete ed acquisisce la possibilità di accedere
alle informazioni messe a disposizione da altri utenti (organizzazioni) e di
fornire e rendere disponibili a questi ultimi le proprie, così come avviene con
i client peer-to-peer utilizzati per il file sharing.
Lo scenario tipico, mostrato in figura 9.3, permette di evidenziare queste
caratteristiche di particolare importanza.
Senza escludere altre possibilità il modo più diretto per organizzare gli
apparati di CISA è quello di predisporre uno o più server hardware (rappresentati
in figura dal case di un calcolatore), vari personal computer per i client
utente (rappresentati in figura da un monitor e da una tastiera) interconnessi
alla rete 2 .
2 Si parla di rete e non di Internet in quanto si intende un’interconnessione fra i processi
di CISA che, in via di principio, può avvenire sia tramite la rete pubblica, che attraverso
una o più reti private oppure su un insieme eterogeneo di soluzioni.
229

Protocolli di comunicazione e architettura di rete in CISA L’architettura di rete
V.R.,
State
Organizzazione A
App.
LS,
LDNS
R.M,M.D.
Lan1
Lan2
App.
Router
Control
Struct.
Rete
Organizzazione B
Router
V.R.,
State,
LDNS,
LS
App.
Lan
Figura 9.3: Esempio di scenario di utilizzo di CISA.
Control
Struct.,
R.M.,
M.D.
Ogni organizzazione ha, oltre alla propria connessione alla rete, alcuni
server sui quali far operare uno o più processi CISA. Niente vieta di ipotizzare
l’esistenza di service provider i quali forniscono alle organizzazioni
l’infrastruttura per l’accesso a CISA (accollandosi l’onere di amministrare i
server) così come avviene attualmente, ad esempio, per i fornitori dell’accesso
ad Internet e per i servizi di web hosting.
Lo scenario prospettato presuppone che, per quanto possibile, ogni organizzazione
utilizzi i servizi CISA internamente messi in opera. I motivi che
spingono a formulare questa ipotesi sono vari, ad esempio vincolare l’interazione
fra i server presenti all’interno della propria rete privata, semplifica
l’amministrazione del sistema all’organizzazione e le permette di controllare
in modo molto più diretto ed efficace tutti gli aspetti legati a questioni di
sicurezza.
In questo scenario quindi, partendo dal livello applicativo, l’organizzazione
usufruisce dei propri server 3 fino a livello Replica Management. Tale
3 Per quanto riguarda il meccanismo di risoluzione si intende che la richiesta debba
essere tendenzialmente effettuata al proprio server (LS o LDNS), ovviamente, a causa
dell’accoppiamento presente fra i processi in gioco, tali server dovranno poter comunicare
con quelli di pari livello delle altre organizzazioni.
230

Protocolli di comunicazione e architettura di rete in CISA L’architettura di rete
processo interpella trasversalmente quello autoritativo sulla risorsa di interesse,
effettuando una sorta di routing delle richieste. Infine, seguendo la
stessa logica utilizzata per i livelli superiori, quest’ultimo processo (Replica
Management) accede ai dati riferendosi ad un numero limitato e stabilito a
priori di Medium Dependent.
9.2.1 Routing delle richieste
Durante lo sviluppo dei vari servizi costituenti l’architettura e in una
prima fase della vita utile in produzione, ipotizzare che ogni processo conosca
a priori ed in modo vincolante quali altri processi interpellare per richiedere
servizi potrebbe essere l’unica strada percorribile.
Questo scenario può essere implementato ricorrendo all’uso degli IACS
descritti nel paragrafo 9.1.1: ogni processo è connesso permanentemente con
altri processi, noti a priori, che forniscono i servizi ad esso necessari.
La questione sollevata in questo paragrafo è che tale soluzione potrebbe
non essere quella ottimale. Verrano quindi introdotte strategie alternative
evidenziando quali modifiche architetturali richiedano per essere implementate.
L’ipotesi che viene mantenuta è che ogni processo che fornisce uno specifico
servizio sia del tutto equivalente ad un qualunque altro processo che
fornisce lo stesso servizio (per ogni possibile richiesta effettuata al processo,
il comportamento percepito dal richiedente deve essere equivalente). La rimozione
di questa ipotesi porterebbe ad una completa ri-progettazione del
sistema orientata verso un paradigma Web Services like.
Il discorso è diverso per quanto riguarda l’efficienza: prendendo per esempio
il caso della risoluzione dei nomi, effettuare la richiesta ad un server che
conosce direttamente la risposta è certamente più efficiente rispetto ad effettuare
la medesima richiesta ad un qualsiasi altro server che non la conosce e
che deve, a sua volta, richiederla ad altri processi omologhi.
Invece di vincolare il processo client ad usufruire di un servizio tramite
un predeterminato processo server, si può ipotizzare che esista un algoritmo
capace di selezionare il server che dovrebbe potenzialmente rispondere in
modo più efficiente rispetto a tutti gli altri processi che erogano lo stesso
tipo di servizio.
Il fatto che l’algoritmo sia stocastico non va ad inficiare l’efficacia del
sistema in quanto, come è stato precedentemente evidenziato, la scelta di un
231

Protocolli di comunicazione e architettura di rete in CISA L’architettura di rete
processo, anziché di un altro omologo, non comporta differenze per quanto
riguarda l’efficacia sull’espletamento del servizio complessivamente erogato.
In questo scenario si evidenzia la natura“intelligente”del IACS. La gestione
del routing delle richieste può essere delegata a tale sistema mascherandola,
parzialmente o completamente, alla logica di controllo. Questo perché
il dispositivo fornisce un’interfaccia software per l’accesso alle primitive del
protocollo e quindi possono esistere implementazioni in grado di interpretare
e prendere decisioni (ovvero applicare l’algoritmo) sulla base delle specifiche
richieste (contingenti o cablate).
Nell’ipotesi, peraltro realistica, in cui tale mascheramento sia completo è
logico supporre che in una prima fase dello sviluppo si proceda verso una soluzione
priva di tale funzionalità con la consapevolezza che, qualora risultasse
importante per l’efficienza globale del sistema, tale funzionalità interna può
essere aggiunta successivamente con costi ridotti (in quanto non è necessario
intervenire sul funzionamento dei servizi, ma solo sugli IACS).
Volendo escludere l’esistenza di un algoritmo efficace ed efficiente per la
scelta del processo migliore con una qualsiasi soglia di approssimazione, i
ragionamenti riportati in questo paragrafo continuano ad avere rilevanza.
Infatti, per migliorare ulteriormente la scalabilità e l’affidabilità locale
del sistema, è comunque possibile introdurre un dispatcher all’interno del
IACS che applichi politiche di bilanciamento di carico (ad esempio roundrobin)
al susseguirsi delle richieste generate dal client in modo che queste si
distribuiscano e vadano a caricare più di un server.
9.2.2 Protocollo con delega
Questo scenario si presenta nel caso in cui si introduca la modalità di
interazione con delega che risulta diversa da quella tipica client/server.
In riferimento alla figura 9.4.a è possibile descrivere brevemente la classica
interazione basata sul paradigma client/server. Nell’esempio si ipotizza che
S0, S1 e S2 siano server tali che il primo di essi è di livello di CISA superiore
mentre gli altri sono di livello inferiore. Il server S0 deve effettuare una
richiesta di servizio e si rivolge ad S1 che però non è in grado di soddisfare
tale richiesta. Conseguentemente S1 inoltra la richiesta a S2 il quale è in
grado di fornire la risposta. A questo punto S1 è in grado di rispondere a S0.
In questo tipo di interazione si ha una catena costituita da una successione
232

Protocolli di comunicazione e architettura di rete in CISA L’architettura di rete
a) Paradigma
client/server
IACS
b) Protocollo
con delega
Client
Logica di controllo
IACS
Server S2
Client
4
Server
Server
Logica di controllo
Server S2
Server S0
Logica di controllo
IACS
4
Response
3
Request
Client
Server S0
Logica di controllo
IACS
5
Response
6
Server
3
Request
1
Client
1
IACS
Client
2
Server
Logica di controllo
IACS
Server S1
Client
5
2
Server
Logica di controllo
Server S1
Figura 9.4: Esempio di interazione con protocollo con delega.
233

Protocolli di comunicazione e architettura di rete in CISA L’architettura di rete
di request ed una successione di response che percorre lo stesso cammino in
senso inverso.
In figura 9.4.b è schematizzato il comportamento del protocollo con delega
di fronte allo stesso tipo di problema appena analizzato ed affrontato con il
paradigma client/server. La comunicazione si sviluppa come segue:
1. la logica di controllo del server S0 deve effettuare una richiesta di
servizio (request) e la inoltra al proprio IACS;
2. IACS sceglie S1 come server a cui rivolgersi;
3. S1 non è in possesso delle informazioni necessarie per espletare il servizio
richiesto da S0 oppure (pur essendo in possesso delle informazioni
necessarie) conosce un server omologo S2 anch’esso in grado di fornire
la risposta (e valuta che, in quel momento, S2 possa rispondere in
modo più efficiente). Inoltra quindi la richiesta ad S2 a nome di S0
(on behalf of S0 );
4. S2 è in grado di fornire la risposta e, agendo da client, contatta l’IACS
di S0;
5. IACS di S0 è in grado di riconoscere questo messaggio come la response
relativa alla request iniziale e la fornisce alla logica di controllo.
Il meccanismo di delega viene implementato integralmente a livello di
IACS e come conseguenza la logica di controllo del client non percepisce nessuna
differenza fra le due modalità operative vedendosi recapitare le response
allo stesso modo.
234

Conclusioni
L’obiettivo del presente lavoro tesi è stato quello di progettare un modello
dell’informazione ed un’architettura distribuita finalizzati al lavoro collaborativo.
In questo contesto il versioning assume un’importanza di rilievo infatti
permette, ad esempio, di tracciare le azioni degli utenti incrementandone
l’awareness e di annullare operazioni non soddisfacenti.
Le varie tappe del lavoro hanno richiesto l’analisi di problematiche presenti
in contesti diversi che partono dal Document e Content Management
all’Enterprise Content Management, dai sistemi di controllo delle versioni per
lo sviluppo del software agli ambienti groupware generici, dalla modellizzazione
dell’informazione al calcolo distribuito, fino all’analisi di standard per
la trasmissione dei dati ed alla progettazione di protocolli di comunicazione
di livello applicativo ISO/OSI.
Nella prima fase del presente lavoro di tesi, relativa all’analisi dell’informazione,
sono stati sintetizzati i requisiti che il modello del documento progettato,
denominato “Distributed Delocalized Document Information Model”
(D3IM), soddisfa.
In dettaglio è stato messo in evidenza che:
• L’informazione è strutturata e la descrizione effettuata tramite l’espressività
degli alberi, è stata ritenuta non sufficiente per coprire tutte le
casistiche; per tale motivo si è scelto di modellare i legami fra gli elementi
che costituiscono il contenuto dei documenti attraverso i DAG
(Directed Acyclic Graph) rispetto ai quali gli alberi rappresentano un
caso particolare. Un documento D3IM è quindi un DAG i cui nodi, denominati
informazioni primitive, incapsulano i dati veri e propri sotto
forma di coppie “”, denominate informazioni atomiche.

Conclusioni
Le relazioni fra nodi permettono di descrivere gli aspetti strutturali
del documento che è stato definito come entità organizzata in modo
gerarchico.
• L’informazione primitiva ha un responsabile che è colui il quale ha la
consapevolezza di dover rispondere degli effetti che possono scaturire a
seguito della divulgazione dell’informazione. Il responsabile può essere
una persona fisica o giuridica che, per alcune categorie di informazioni,
è stabilita dalla legge.
• L’informazione è versionata e D3IM applica nativamente un proprio
modello di versioning progettato, nel presente lavoro di tesi, sulla base
di UEVM. Ogni documento D3IM incapsula quindi tutte le varie forme
che l’informazione ha assunto nell’intero ciclo evolutivo del documento
stesso.
• L’informazione è delocalizzata, distribuita e replicata. Ogni documento
è costituito da informazioni primitive, distribuite nello spazio, ed
eventualmente replicate per la tolleranza ai guasti e il bilanciamento
del carico; inoltre il fruitore del documento non può inquadrarle nel
contesto di una specifica localizzazione fisica.
Per perseguire queste finalità sono stati definiti tre spazi di nomi, su tre
livelli diversi, relativi alle risorse. I nomi logici (Logical Resource Identifier,
LRI) vengono assegnati alle informazioni primitive dall’utente e sono
facilmente trattabili dall’uomo; ogni informazione primitiva può essere identificata
da un numero arbitrario di LRI (alias). I nomi persistenti ed univoci
(Persistent Resource Identifier, PRI) vengono assegnati dal sistema per l’identificazione
non ambigua di ogni informazione primitiva. Infine gli Uniform
Resource Locator (URL) servono per identificare e permettere l’accesso alle
singole repliche.
Sulla base dei principi di funzionamento del DNS (Domain Name System)
sono stati introdotti i sistemi per la risoluzione, diretta ed inversa, da LRI
a PRI e da PRI ad URL chiamati rispettivamente “Logical Domain Name
System” (LDNS) e “Localization Service” (LS).
Sulla base del modello D3IM, nel presente lavoro di tesi, è stata progettata
anche un’infrastruttura chiamata “Collaborative Information System
Architecture” (CISA).
236

Conclusioni
Il progetto è stato eseguito secondo un approccio stratificato e sono stati
individuati i seguenti livelli:
• Application Layer, si occupa di fornire l’interfaccia all’utilizzatore del sistema
e di implementare le strategie operative finalizzate al trattamento
dei dati nel particolare contesto applicativo;
• Virtual Repository Layer, si occupa della gestione delle identità degli
utenti, della ricostruzione (aggregando informazioni primitive) e decomposizione
(scomponendo informazioni primitive) dei documenti e
della risoluzione dei nomi logici in persistenti tramite LDNS;
• Structure Layer, si occupa della gestione delle versioni dell’informazione
utilizzando il modello di versioning estensionale definito in D3IM;
• Replica Management, si occupa della gestione delle repliche e dell’accesso
fisico all’informazione utilizzando la risoluzione da PRI in URL
fornita da LS;
• Medium Dependent Layer, fornisce il servizio di memorizzazione e di
accesso alle repliche.
La stratificazione ha dimostrato, anche in questo caso, di fornire un’elevata
modularità all’architettura, come è avvenuto nel contesto dell’internetworking;
inoltre ha semplificato la progettazione ed ha fornito garanzie di
scalabilità. Questi ultimi aspetti sono stati ulteriormente enfatizzati dal paradigma,
basato sul web (REST), a cui è stato fatto riferimento per progettare
l’interazione fra i vari layer.
In analogia allo stack TCP/IP, nelle specifiche di CISA, non sono stati
posti vincoli relativamente ai livelli Application e Medium Dependent, situati
alle estremità della pila. Questo permetterà al sistema di evolvere nel
tempo tramite l’introduzione di specifiche implementazioni interne al layer
Application equivalentemente a ciò che è stato fatto per i protocolli di livello
applicativo di Internet; inoltre, tramite l’implementazione di opportuni
adattatori interni al layer Medium Dependent, consente l’utilizzo di sistemi di
storage diversificati fornendo la stessa flessibilità attualmente presente nella
scelta del mezzo fisico di trasporto dei link di rete.
È importante sottolineare che ogni fase della progettazione è stata preceduta
da un’accurata analisi dello stato dell’arte del settore relativo all’argomento
in esame, al fine di ricercare modelli e/o sistemi a cui fare riferimento.
237

Conclusioni
Come già osservato è stato fatto uso dell’approccio stratificato, tipico delle
telecomunicazioni, utilizzato per la definizione dello scheletro dell’architettura;
dell’approccio REST per il paradigma di interazione; dei principi operativi
del DNS (Domain Name System) per la progettazione dei sistemi di
risoluzione; di standard quali XML per la definizione dei modelli dei dati.
Nel presente lavoro di tesi, per progettare il versioning in D3IM, si è fatto
riferimento al modello UEVM che si è dimostrato il più efficiente, efficace
ed evoluto relativamente a questo ambito. Ciò ha permesso la realizzazione
di un modello di versioning estensionale che ha il vantaggio di consentire il
recupero, in ogni momento, della versione corretta dell’informazione strutturata,
definita in D3IM, esattamente come è stata creata. Si osservi come il
paradigma non estensionale, utilizzato per la sua semplicità in altri sistemi
presenti sul mercato, dimostri alcuni limiti proprio nella gestione degli aspetti
strutturali dell’informazione. Inoltre il versioning estensionale dei documenti
risulta di più facile comprensione per l’utente.
D3IM eredita da UEVM i vantaggi relativi al problema, noto agli esperti
del settore, della gestione dell’esplosione combinatoria delle versioni, fornendo
notevoli garanzie, in termini di scalabilità, al crescere della complessità del
documento e del relativo storico.
Attualmente è in atto un’implementazione di una versione prototipale
dell’architettura, limitata alle funzionalità principali, basata sul framework
progettato in questo lavoro di tesi. A tal riguardo è opportuno segnalare che
già esistono implementazioni preliminari funzionanti dei server LDNS ed LS.
Si rimanda agli sviluppi futuri il completamento di tale implementazione
e la successiva evoluzione destinata agli utilizzatori finali.
In questa seconda fase occorrerà definire meccanismi maggiormente evoluti
atti a migliorare l’architettura da un punto di vista della sicurezza operativa
che attualmente risulta essere sufficiente per l’implementazione prototipale.
In questo contesto è necessario realizzare anche i sistemi finalizzati al
debugging ed al monitoraggio dell’architettura.
Ulteriori ambiti di indagine riguardano studi finalizzati ad evidenziare le
similitudini fra l’architettura CISA e quella DataGrid ([Dat06]) dato che condividono
vari obiettivi e principi operativi. Tali similitudini sono particolarmente
evidenti per quanto riguarda la gestione distribuita delle informazioni
e, nello specifico, i livelli più bassi di CISA.
Risulta di notevole interesse lo sviluppo dei layer Application e Medium
Dependent in contesti applicativi concreti. Nella tesi di laurea dal tito-
238

Conclusioni
lo “Analisi progettuale per la realizzazione di un sistema fiduciario in rete”([Olm05]),
viene analizzato, con questa prospettiva, il problema del profilo
degli utenti in un particolare contesto relativo al turismo.
Riprendendo ed estendendo il lavoro effettuato in [Inn04], altri ambiti di
interesse riguardano specifiche problematiche inerenti alle Pubbliche Amministrazioni
come, per esempio, la gestione documentale e metadocumentale
degli atti amministrativi.
In generale si possono progettare software di livello Application di CISA
che implementano le varie funzionalità svolte dai sistemi presenti sul mercato
per l’Enterprise Content Management e/o il Software Configuration
Management.
L’ultimo esempio menzionato riguarda la progettazione e l’implementazione
di una piattaforma per l’e-learning: i Learning Objects ([Bia03]) ed i
documenti D3IM infatti condividono svariate caratteristiche quali i concetti
di struttura, di aggregazione, di riuso dell’informazione, eccetera.
I campi di applicazione sono innumerevoli; nel presente lavoro ne sono
stati indicati solo alcuni: altri, sulla base di interessi contingenti, possono
essere oggetto di ulteriori indagini ed approfondimenti.
239

Bibliografia
[ABC + 04] Vidur Apparao, Steve Byrne, Mike Champion, Scott Isaacs, Ian Jacobs, Arnaud
Le Hors, Gavin Nicol, Jonathan Robie, Robert Sutorand, Chris Wilson,
Lauren Wood, and Philippe Le Hégaret. DOM: Document Object Model Level
1,2,3. http://www.w3c.org/DOM, 2000-2004.
[ABCM99] Ulf Asklund, Lars Bendix, Henrik B. Christensen, and Boris Magnusson. The
Unified Extensional Versioning Model. Settembre 1999.
[App05] Brad Appleton. SCM Definitions.
http://www.cmcrossroads.com/bradapp/acme/scm-defs.html,
Novembre 2005.
[Ask02] Ulf Asklund. Configuration Management for distribuited development in an
integrated envirnoment. 2002. Tesi di Dottorato di Ricerca. Department of
Computer Science, Lund Institute of Technology, Lund University.
[Bia03] Federica Bianchi. Che cosa sono i Learning Object – Articolo tratto dalla tesi
di laurea, A.A. 2001/2002. Maggio 2003.
[Bit05] Inc. BitMover. BitKeeper - The Scalable Distributed Software Configuration
Management System. http://www.bitkeeper.com/, Novembre 2005.
[BLFIM98] T. Berners-Lee, R. Fielding, U.C. Irvine, and L. Masinter. RFC 2396.
Uniform Resource Identifiers (URI): Generic Syntax. IETF, Agosto 1998.
[BLMM94] T. Berners-Lee, L. Masinter, and M. McCahill. RFC 1738. Uniform Resource
Locators (URL). IETF, Dicembre 1994.
[Bul05] Diamond Bullet. Usability First: Groupware.
http://www.usabilityfirst.com/groupware, 2005.
[Cle95] Gary Cleveland. Overview of Document Management Technology. National
Library of Canada, Giugno 1995.
[CM03] Luca Cappelli and Massimiliano Morbidi. Tesi di laurea – Progetto di una
architettura distribuita orientata alla collaborazione. A.A. 2002/2003.

BIBLIOGRAFIA BIBLIOGRAFIA
[Coa06] The Workflow Management Coalition. The Workflow Management Coalition.
http://www,wfmc.org, Marzo 2006.
[Col05a] Inc CollabNet. CollabNet, Inc. http://www.collab.net, Novembre 2005.
[Col05b] Inc. CollabNet. Subversion Home Page.
http://subversion.tigris.org/, Novembre 2005.
[Com05] Compaq. Vesta. http://www.vestasys.org/, Novembre 2005.
[CSFP04] Ben Collins-Sussman, Brian W. Fitzpatrick, and C. Michael Pilato. Version
Control with Subversion, For Subversion 1.1. O’Reilly, Giugno 2004. È stato
rilasciato con licenza “Creative Commons” ed è disponibile all’indirizzo:
http://svnbook.red-bean.com/en/1.1/svn-book.pdf.
[Dan97] R. Daniel. RFC 2169. A Trivial Convention for using HTTP in URN
Resolution. IETF, Giugno 1997.
[Dat06] Wikipedia DataGrid. DataGrid.
http://en.wikipedia.org/wiki/Data grid, Marzo 2006.
[dedF06] Ministero dell’Economia e delle Finanze. Agenzia delle Entrate: home page.
http://www.agenziaentrate.it, Marzo 2006.
[DvGIF99] L. Daigle, D. van Gulik, R. Iannella, and P. Faltstrom. RFC 2611. URN
Namespace Definition Mechanisms. IETF, Giugno 1999.
[DWSC05] M. Duerst, W3C, M. Suignard, and Microsoft Corporation. RFC 3987.
Internationalized Resource Identifiers (IRIs). IETF, Gennaio 2005.
[ESG91] C.A. Ellis and G.L. Rein S.J. Gibbs. Groupware: some issues and experiences.
ACM, Gennaio 1991.
[FB03] Karl Fogel and Moshe Bar. Open Source Development with CVS,
3rd Edition. O’Reilly, Luglio 2003. È stato rilasciato con licenza
“Creative Commons” ed è disponibile all’indirizzo: http://cvsbook.redbean.com/OSDevWithCVS
3E.pdf.
[Fei91] Peter H. Feiler. Configuration Management Models in Commercial Environments.
Software Engineering Institute. Carnegie Mellon University.
Pittsburgh, Pennsylvania 15213, Marzo 1991.
[Fie00] Roy Thomas Fielding. Representational State Transfer (REST).
http://www.ics.uci.edu/ fielding/pubs/dissertation/rest arch style.htm, Luglio
2000.
[FIG + 99] R. Fielding, UC Irvine, J. Gettys, Compaq/W3C, J. Mogul, Compaq, H. Frystyk,
W3C/MIT, L. Masinter, Xerox, P. Leach, Microsoft, T. Berners-Lee,
and W3C/MIT. RFC 2119. Hypertext Transfer Protocol – HTTP/1.1. Giugno
1999.
[Fou04] International DOI Foundation. The DOI Handbook. http://www.doi.org,
2004.
241

BIBLIOGRAFIA BIBLIOGRAFIA
[Fou05a] Eclipse Foundation. Eclipse Home page. http://www.eclipse.org, Novembre
2005.
[Fou05b] The Apache Software Foundation. Apache Portable Runtime Project.
http://apr.apache.org/, Novembre 2005.
[Fou05c] The Apache Software Foundation. The Apache Software Foundation.
http://www.apache.org/, Novembre 2005.
[Fra05] Niccolò Francini. Tesi di laurea – Progettazione e sviluppo di un sistema
distribuito di risoluzione di nomi logici. A.A. 2004/2005.
[GHJV95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design
Patterns: elements of reusable object-oriented software. Addison-Wesley,
Massachusetts, USA, 1995.
[Gnu93] Gnu. Gnu man pages “rcsintro”. Novembre 1993.
[Gnu03] Gnu. RCS. http://www.gnu.org/software/rcs/rcs.html, Febbraio 2003.
[Gnu05] Gnu. GNU Arch. http://www.gnu.org/software/gnu-arch/, Novembre 2005.
[Goy06] Jan Goyvaerts. Regular-Expressions.info - Regex Tutorial, Examples and Reference
- Regexp Patterns. http://www.regular-expressions.info/, Febbraio
2006.
[HM02] J. Hodges and R. Morgan. RFC 3377. Lightweight Directory Access Protocol
(v3): Technical Specification. IETF, Settembre 2002.
[IDE05] Wikipedia IDE. IDE, Integrated development environment.
http://en.wikipedia.org/wiki/Integrated development environment, Novembre
2005.
[Inc05] Perforce Software Inc. Perforce. http://www.perforce.com/, Novembre 2005.
[Inn04] Samuele Innocenti. Tesi di laurea – Modello dell’informazione per documenti
distribuiti e delocalizzati a supporto della cooperazione applicativa nelle
Pubbliche Amministrazioni. A.A. 2003/2004.
[Ita96] Parlamento Italiano. Legge 31 dicembre 1996, n. 675. Tutela delle persone e
di altri soggetti rispetto al trattamento dei dati personali. Dicembre 1996.
[Ita03] Governo Italiano. Decreto legislativo 30 giugno 2003, n. 196 - Codice in
materia di protezione dei dati personali. Giugno 2003.
[Kap97] Simon Kaplan. The CSCW: The Quadrant Model of Groupware.
ACM, Agosto 1997.
[Kat90] Randy H. Katz. Toward a Unified Framework for Versioning Modeling in
Engineering Databases. ACM Computing Surveys, Dicembre 1990.
[Kie94] Robert Kiesling. The RCS MINI-HOWTO (ver. 1.4).
http://it.tldp.org/HOWTO/RCS.html, Agosto 1994. Traduzione a cura di
Fabrizio Stefani, luglio 1999.
242

BIBLIOGRAFIA BIBLIOGRAFIA
[KR03] James F. Kurose and Keith W. Ross. Internet e reti di calcolatori.
McGraw-Hill, 2003.
[Lin05] Redazione LinuxPro. Tutorial Subversion. LinuxPro, n.31,32,33, Settembre,
Ottobre, Novembre 2005.
[lK05] Chia liang Kao. Svk. http://svk.elixus.org/, Novembre 2005.
[LPD98] C. Lynch, C. Preston, and R. Daniel. RFC 2288. Using Existing Bibliographic
Identifiers as Uniform Resource Names. IETF, Febbraio 1998.
[Ltd05a] Canonical Ltd. Bazaar-NG: next-generation distributed version control.
http://www.bazaar-ng.org/, Novembre 2005.
[Ltd05b] PureCM.com Ltd. PureCM. http://www.purecm.com/, Novembre 2005.
[MD00] Sergey Melnik and Stefan Decker. A Layered Approach to Information
Modeling and Interoperability on the Web. Settembre 2000.
[Mic05] Microsoft. Visual SourceSafe.
http://msdn.microsoft.com/vstudio/previous/ssafe/, Novembre 2005.
[Mil05] Peter Miller. Aegis. http://aegis.sourceforge.net/, Novembre 2005.
[MO94] Munir Mandvwalla and Lorne Olfman. What Do Groups Need? A Proposed
Set of Generic Groupware Requirements. ACM, Settembre 1994.
[Moa97] R. Moats. RFC 2141. URN syntax. IETF, Maggio 1997.
[Moc87a] P. Mockapetris. RFC 1034. Domain Names - Concepts and Facilities.
IETF, Novembre 1987.
[Moc87b] P. Mockapetris. RFC 1035. Domain Names - Implementation and
specification. IETF, Novembre 1987.
[Mon05] Team Monotone. Monotone. http://venge.net/monotone/, Novembre 2005.
[Olm05] Riccardo Olmi. Tesi di laurea – Analisi progettuale per la realizzazione di un
sistema fiduciario in rete. A.A. 2004/2005.
[Ope05] Team OpenBSD. OpenSSH.
http://www.openssh.com/it/index.html, Novembre 2005.
[Por06] Wikipedia Portabilità. Portabilità.
http://it.wikipedia.org/wiki/Porting, Febbraio 2006.
[Pra03] A. Prass. RFC3444. On the Difference between Information Models and Data
Models. IETF, Gennaio 2003.
[Rei05] Stefan Reich. Sperversion. http://www.superversion.org/, Novembre 2005.
[Res05] Wikipedia Rest. Representational State Transfer (REST).
http://en.wikipedia.org/wiki/REST, Luglio 2005.
[RJB99] James Rumbaugh, Ivar Jacobson, and Grady Booch. The Unified Modeling
Language Reference Manual. Addison-Wesley, 1999.
243

BIBLIOGRAFIA BIBLIOGRAFIA
[Rob06] James Robertson. Is it document management or content management?
Step Two Design, Febbraio 2006.
[Rou05] David Roundy. Darcs. http://abridgegame.org/darcs/, Novembre 2005.
[RS05] IBM Rational Software. Rational ClearCase.
http://www-306.ibm.com/software/awdtools/clearcase/, Novembre 2005.
[SM94] K. Sollins and L. Masinter. RFC 1737. Functional Requirements for Uniform
Resource Names. IETF, Dicembre 1994.
[Sof05] Reliable Software. Code Co-op Distributed Version Control System.
http://www.relisoft.com/, Novembre 2005.
[Sol98] K. Sollins. RFC 2276. Architectural Principles of Uniform Resource Name
Resolution. IETF, Gennaio 1998.
[SVLF05] Jonathan S. Shapiro, John Vanderburgh, Jack Lloyd, and Todd Fries.
OpenCM. http://www.opencm.org/, Novembre 2005.
[TS06] Marco Trevisan and Roberto Scano. Web accessibile e accessibilità dei siti
internet - Webaccessibile.org. http://www.webaccessibile.org/, Marzo 2006.
[TW97] Andrew S. Tanenbaum and Albert S. Woodhull. Operating Systems. Design
and Implementation. Second Edition. Prentice Hall, Gennaio 1997.
[WCJRg03] J. Whitehead, U.C. Santa Cruz, Ed. J. Reschke, and greenbytes. RFC 3648.
Web Distributed Authoring and Versioning (WebDAV). Ordered Collections
Protocol. Dicembre 2003.
[Whe05] David Wheeler. Comments on Open Source Software / Free Software
(OSS/FS) Software Configuration Management (SCM) Systems.
http://www.dwheeler.com/essays/scm.html, Maggio 2005.
244

Accurate, 98, 100
Albero, 82
Albero di zone, 203
Allowable, 98, 99
Ambiente di sviluppo integrato,
vedi IDE
anatomico, Modello, 16
Application Layer, 108
architetturale, Modello, 16
Authoring, 3
Avatar, 65, 67
Awareness, 7
B LAST, 156
B ROOT, 154
BitKeeper, 59
Blocco, vedi Lock
BRANCH, 163
Branch, 25
Change set, 28
Changing, 91
Checkout/Checkin, 26
CISA, Collaborative Information System
Architecture, 104
CM, Configuration Management, 19
CM, Content Management, 4
CMS, Content Management Systems, 4
COMMIT, 161
Commit, 50
Composizione, 26
Configuration, 18
Indice analitico
Configuration Management Systems, 20
Configurazione, 18
Conflitto, 50
conservativa, Strategia, 17
conservativo, Lock, 18
Consistency, 100
Consumer, 65
Convergenza, vedi Merge
COOP/Orm, 56
copy-merge, Modello, 17
CREATE, 162, 168
CSCW, Computer-Supported Cooperative
Work, 6
CVS, 49
D3IM, Distributed Delocalized Document
Information Model, 78
DAG, 40
Data model, 77
Delivery dell’informazione, 73
Diramazione, 25
DM, Document Management, 3
DMS, Document Management Systems, 4
DNS, Domain Name System, 194
Documento, 77
Documento strutturato, 80
Draft, 98, 99
ECM, Enterprise Content Management, 5
estensionale, Modello di versioning, 32
Foresta, 82
Frozen, 91
245

INDICE ANALITICO INDICE ANALITICO
Gestione dello storico, 128
GET, 159, 165
Git, 60
Good enough, 104
Group, 66, 68
Groupware, 6
groupware, Progettazione di, 10
groupware, Requisiti per sistemi, 13
H GRAPH, 156
H ROOT, 154
HFN, Human Friendly Name, 86
HFN, Requisiti di, 195
IACS, Inter-Application Communication
System, 226
IDE, Integrated Development
Environments, 57
Information hiding, 104
Information Model, 77
Informazione atomica, 81, 86
Informazione primitiva, 81, 88
informazione, Delivery, 73
intensionale, Modello di versioning, 30
Interazione:
asincrona, 7
molti a molti, 70
molti a uno, 70
sincrona, 7
uno a molti, 70
uno a uno, 70
Interdataworking, 104
Interfaccia bidimensionale, vedi IACS
Lavoro collaborativo, 6
Lavoro:
in gruppi localizzati, 9
a distanza, 8
in appalto, 9
in gruppi distribuiti, 9
Layer, 105
Layer:
Application, 108
Medium Dependent, 115
Replica Management, 112
Structure, 112
Virtual Repository , 108
LDNS, Logical Domain Name System, 202
Link:
di composizione, 90
di propagazione, 131
di riferimento, 90
di versione, 132
Livello, 105
LNS, Logical Name Server, 203
LNSP, Logical Name Space, 202
LOCK, 166
Lock:
conservativo, 18
ottimistico, 18
pessimistico, 18
LOCKED SOFT, 164
LOCKED STRONG, 164
look-ahead, Risoluzione con, 206
look-ahead, Risoluzione senza, 205
LRI, Logical Resource Identifier, 86, 197
LS, Localization Service, 213
Management, 65
MARK, 163
Medium Dependent Layer, 115
MERGE, 164
Merge, 25
Metadati, 18
Modello:
anatomico, 16
architetturale, 16
copy-merge, 17
del documento di UEVM, 34
split-combine, 17
turn-taking, 17
versioning estensionale, 32
versioning intensionale, 30
Navigazione, 151
Navigazione nello storico, 128
notifica, Meccanismo di, 107
NULL, 164
OBSERVED, 164
246

INDICE ANALITICO INDICE ANALITICO
ottimistica, Strategia, 17
ottimistico, Lock, 18
Parametro di versione, 152
pessimistico, Lock, 18
Polytree, 82
PRI, Persistent Resource Identifier, 84, 199
Processo, 118
Producer, 65
Propagazione, 133
propagazione, Link di, 131
Protocollo con delega, 232
PUT, 167
R PREV, 154
RCS, 45
RELAXED, 164
relaxed, Politica, 96
Replica Management Layer, 112
Repository, 46
Responsabile, 81
REST, Representational State Transfer, 106
Revisione, 24, 92
Risoluzione inversa, 215
Routing delle richieste, 231
SCM, Software Configuration Management,
vedi CM
Separation of concern, 104
Servizio, 118
Sistemi basati su:
stato, 33
variazioni, 32
soft, Politica, 96
split-combine, Modello, 17
stato, Sistemi basati su, 33
Storico, 91
Strategia:
conservativa, 17
ottimistica, 17
strong, Politica, 95
Structure Layer, 112
Stuff, 66, 69
Subversion, 53
Svk, 61
T ABSLAST, 154
T RELATLAST, 154
Tagging, 26
Tipologia di documento, 18
Transazioni estese nel tempo, 27
turn-taking, Modello, 17
UEVM, 33
UNLOCK, 168
Update, 91
URI, Uniform Resource Identifiers, 83
URL, Uniform Resource Locator, 83
URN, Requisiti di, 195
URN, Uniform Resource Name, 84
Variante, 25
variazioni, Sistemi basati su, 32
Versione, 91
versione, Link di, 132
Virtual Repository Layer, 108
WebDAV, 44
Workflow, 3
World, 65, 68
Zona, 202
247