Progetto di un modello dell informazione versionata e di un architettura di rete finalizzati al lavoro collaborativo

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Progetto di un modello dell informazione versionata e di un architettura di rete finalizzati al lavoro collaborativo"

Transcript

1 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 Tesi di Laurea di Davide Chini Relatori Prof. Franco Pirri Correlatori Ing. Samuele Innocenti Prof. Dino Giuli Ing. Maria Chiara Pettenati Anno Accademico 2004/2005

2 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

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

4 Ai miei genitori

5 Indice Introduzione xiii I Analisi del versioning in ambienti collaborativi 1 1 Cooperazione e collaborazione nelle organizzazioni La gestione dei documenti Il lavoro collaborativo Progettazione di groupware I gruppi e la collaborazione Requisiti generali per sistemi groupware Modelli di lavoro Il concetto di configurazione Versioning a supporto della collaborazione Il controllo delle versioni Modelli di sincronizzazione Checkout/Checkin Composizione Transazioni estese nel tempo Change set Modelli di versioning Modello intensionale Modello estensionale Valutazione dei modelli

6 Indice Una nuova alternativa: UEVM Unified Extensional Versioning Model Il modello Il modello del documento Esempio di documento strutturato Versioning Versioning di un singolo documento Versioning di più documenti legati fra loro Conclusioni UEVM dal punto di vista dell utente Gestione dell esplosione combinatoria WebDAV Revision Control System (RCS) Concurrent Versions System (CVS) CVS, evoluzione di RCS Concetti di base Revisioni, branch e configurazioni Subversion Concetti di base Numerazione esplicita delle configurazioni L ambiente integrato COOP/Orm Ambienti di sviluppo integrati Da Orm a COOP/Orm Sistemi di versioning peer-to-peer Valutazioni comparative II Ambiente virtuale e modello dell informazione 63 3 Modello dell ambiente virtuale Rappresentazione dell ambiente Le entità Avatar Group World Stuff Il modello delle interazioni v

7 Indice Prima fase dell interazione Seconda fase dell interazione Il delivery dell informazione Modello dell informazione versionata D3IM Principi di strutturazione Il concetto di responsabilità I nodi informativi del documento Identificazione dei nodi e relativo accesso Informazioni atomiche Informazioni primitive Relazioni fra i nodi informativi Storico dei documenti La propagazione delle modifiche Authoring concorrente Controllo delle sessioni Lo stato di un documento Lo stato delle informazioni Lo stato delle informazioni atomiche Lo stato delle informazioni primitive III Dai modelli teorici all architettura concreta Architettura CISA Visione stratificata di CISA Application Layer Virtual Repository Layer Operazioni di base sulle entità Structure Layer Replica Management Layer Medium Dependent Layer CISA, sistema distribuito Control Plane Definizione di livelli, servizi e processi vi

8 Indice 6 Versioning in CISA Da D3IM al versioning in CISA Lo storico in CISA La struttura dello storico D3IM nel layer Structure Relazioni fra nodi di livello Structure Gestione delle revisioni: la propagazione Propagazione push e propagazione pull Branching e merging Richiami di branching e merging in Subversion Branching da D3IM a CISA Merging da D3IM a CISA Gestione degli aspetti strutturali del documento La navigazione nello storico I parametri di versione Il servizio fornito dal layer Structure Interfacce Interfaccia mostrata a Virtual Repository Interfaccia fornita da Replica Management La struttura dati interna a Structure XML Schema Descrizione dello XML Schema Introduzione agli algoritmi Accesso ai documenti Uso del parametro di versione Accesso alla versione Modifica di documenti Il concetto di sessione Servizi di branching e di merging Il servizio di risoluzione dei nomi Requisiti dei nomi Requisiti per gli HFN Requisiti per gli URN Requisiti non funzionali Requisiti sulla codifica vii

9 Indice 8.2 LRI: gli identificatori logici delle risorse PRI: gli identificatori persistenti Logical DNS Supporto alla navigazione Espansione del Logical Name Space Aggiornamento del database Proprietà Localization Service Risoluzione inversa Ottimizzare le prestazioni Protocolli di comunicazione e architettura di rete in CISA Interfacce e protocolli Interfaccia bidimensionale L architettura di rete Routing delle richieste Protocollo con delega Conclusioni 235 Bibliografia 240 Indice analitico 245 viii

10 Elenco delle figure 1.1 Gli strati di supporto alla collaborazione Albero ottenibile dalla definizione ricorsiva di configurazione Rappresentazione della storia delle versioni Paradigma di interazione Esempi di applicazione della grammatica Esempi di documento Altri esempi di documenti strutturati: un libro e del codice Java Alcuni cambiamenti all interno della stessa sessione La modifica di un link genera la nascita di una nuova versione del documento Gestione delle configurazioni in RCS Evoluzione delle versioni in Subversion Topologie a stella ed albero Ruoli degli attori dell ambiente virtuale Il modello di interazione La notifica delle modifiche Documento D3IM: DAG ed albero associato Nomi di risorse replicate Stato Update delle informazioni Generazione delle revisioni Casi di authoring concorrente Stati di un informazione atomica

11 Elenco delle figure 4.7 Stati di un informazione primitiva Livelli dell architettura CISA Paradigma di interazione request/response La pila CISA più nel dettaglio Livelli, servizi e processi Nodi di livello Structure Gestione dei link di propagazione Concessione dei diritti di modifica a tutti i responsabili nella gerarchia di successori Organizzazione tipica di un progetto gestito con Subversion Risultato della copia di un file in Subversion: branch in D3IM Risultato della copia di una directory in Subversion Branch in D3IM con un figlio condiviso Propagazione in presenza di un figlio condiviso Merge di due nodi Propagazione a seguito di un merge Gestione di due rami di sviluppo concorrente Branch di un intero documento Sintassi degli indirizzi di livello Structure Esempio di elemento più recente relativamente al nodo di partenza Esempi di last relativi al branch Casi d uso relativi all interfaccia mostrata da Structure a Virtual Repository Casi d uso relativi all interfaccia mostrata a Structure da Repository Management Albero del XML Schema: visione globale Albero del XML Schema: particolare dei link di versione XML Schema che rappresenta gli indirizzi PRI Espressione regolare che definisce gli identificativi di versione Convenzione sui nomi dei nodi relativi allo storico Accesso al nodo last in tempo costante Diagramma di sequenza relativo all accesso ad un documento Diagramma di sequenza relativo alla prenotazione per la modifica di un documento x

12 Elenco delle figure 7.11 Diagramma di sequenza relativo alla richiesta di salvataggio di un documento Sintassi dei Logical Name Espressione regolare che definisce i PRI in CISA Sintassi dei PRI in CISA espressa tramite BNF Associazione tra LRI, PRI ed URL Esempio di Logical Name Space Esempio di suddivisione in zone del LNSP Esempio di albero delle zone Risoluzione senza Look-Ahead Risoluzione con Look-Ahead Richieste ricorsive per la risoluzione Esempio di LS Schema per la risoluzione inversa Tabelle necessarie per la risoluzione inversa iterativa Bidimensionalità dell interfaccia fra processi Inter-Application Communication System Esempio di scenario di utilizzo di CISA Esempio di interazione con protocollo con delega xi

13 Elenco delle tabelle 1.1 Modello Johansen Requisiti per sistemi groupware Struttura e dati di un documento Approcci di versioning adottati dai CM sui vari tipi di entità Grammatica che definisce la struttura del documento Mappa per la determinazione degli stati Decomposizione dei ruoli degli utenti

14 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).

15 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 documenxiv

16 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

17 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

18 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

19 Parte I Analisi del versioning in ambienti collaborativi

20 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.

21 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

22 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

23 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

24 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

25 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: , 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. Tempo Spazio Stesso luogo Luoghi diversi Stesso intervallo temporale Interazione faccia a faccia Interazione sincrona distribuita Intervalli temporali disgiunti Interazione asincrona Interazione asincrona distribuita Tabella 1.1: Modello Johansen. Gli utenti che si trovano a collaborare all interno dello stesso ambiente 7

26 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

27 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

28 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) 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

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

30 Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo Incontro di corridoio Lavoro individuale Riunione Tempo Interazione in corso Collaborazione Nelle Organizzazioni Riunione successiva Condivisione dei documenti Individuo Nel gruppo Il gruppo come un tutt'uno Tra gruppi Substrato Sociale Nella stessa organizzazione Fra organizzazioni diverse Risorse umane Attività di prassi Procedimenti Ambiente fisico Risorse temporali Substrato Economico Information Communication Technologies Figura 1.1: Gli strati di supporto alla collaborazione. 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

31 Cooperazione e collaborazione nelle organizzazioni Il lavoro collaborativo 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

32 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

33 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

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

35 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

36 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

37 Cooperazione e collaborazione nelle organizzazioni Il concetto di configurazione Tipo di dato Valore Nome Mario Cognome Data e Luogo di Nascita Etc. Rossi 20/10/1971 Firenze (FI) 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 t 0. Con istantanea si intendono tutte le informazioni necessarie per poter ricreare il sistema (documento o prodotto) esattamente come si presenta al tempo t 0, nello stesso o in un altro luogo, in un momento t 1 t 0. 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

38 Cooperazione e collaborazione nelle organizzazioni Il concetto di configurazione Passo 1 Passo 2 Passo 3 Configurazione iniziale C1 C2 C3 Entità atomiche 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. 20

39 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

40 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

41 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

42 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

43 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 Revisione Diramazione Variante 3 Diramazione 5 Convergenza 6 Convergenza Revisione Revisione A B C 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

44 Versioning a supporto della collaborazione Modelli di sincronizzazione 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) 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

45 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 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 Area di lavoro personale A Area di lavoro personale B Figura 2.2: Paradigma di interazione. 27

46 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 Change set Questo modello permette di gestire i cambiamenti logici del documento. Ad esempio, nello sviluppo di software, un cambiamento logico potrebbe es- 28

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

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

49 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

50 Versioning a supporto della collaborazione Modelli di versioning 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 V j, effettua le modifiche e condivide con gli altri la nuova versione V j+1. Tra V j e V j+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) 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

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

52 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] 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. È il simbolo iniziale della grammatica (assioma). A: albero. È un simbolo astratto, non terminale, che quindi non compare nella stringa dei terminali che rappresenta il documento. Il nome del 34

53 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

54 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

55 Versioning a supporto della collaborazione Unified Extensional Versioning Model D D A D A C D A [data] A A D A A [data] A C N D A [data] D [data] A A N [data] A L N A N [data] L 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. 37

56 Versioning a supporto della collaborazione Unified Extensional Versioning Model C C C N C L C L N N N N N N C C N N N L N N Figura 2.4: Esempi di documento. Esempio di documento strutturato 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

57 Versioning a supporto della collaborazione Unified Extensional Versioning Model Applicazione Libro Import Classe 1 Import Cap.1 Cap.2 Cap.3 Membro 1 Membro 2 Par.1 Par.2 Par.1 Par.2 Classe B Super C. Classe A Membro 1 Membro 2 Membro 1 Membro 2 Membro 3 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

58 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

59 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 C C N C C N C C 2 N C N N N N N N 3.1 N N N N N N a) Struttura iniziale del documento b) Il nodo 3.1 è stato modificato 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

60 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 C L C L L C L L C L N N N N N N D2 C D2 C D2 C L N N L N N L N N D3 C D3 C D3 C N N N N N N N N N Figura 2.7: La modifica di un link genera la nascita di una nuova versione del documento. 42

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

62 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

63 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 <nome,valore>. 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

64 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

65 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. File1 File2 File3 Fase 1 r1.1 r1.1 r1.1 Fase 2 Fase 3 Fase 4 r1.2 r1.2 Fase 5 Configurazione con etichetta: beta1 r1.3 Configurazione con etichetta: stabile1.0 Figura 2.8: Gestione delle configurazioni in RCS. 47

66 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

67 Versioning a supporto della collaborazione Concurrent Versions System (CVS) messo in evidenza descrivendo il modello basato su composizione, descritto nel sotto paragrafo 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 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 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

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

69 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

70 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

71 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

72 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

73 Versioning a supporto della collaborazione Subversion 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 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

74 Versioning a supporto della collaborazione L ambiente integrato COOP/Orm 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 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

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

76 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

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

78 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. Repository del responsabile della partizione Padre Padre Figli Figli Figura 2.10: Topologie a stella ed albero. 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

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

80 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

81 Parte II Ambiente virtuale e modello dell informazione

82 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.

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

84 Modello dell ambiente virtuale Rappresentazione dell ambiente Real Environment Resource / Entities Virtual Environment 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

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

86 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

87 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

88 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

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

90 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 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) 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

91 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 ( -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

92 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

93 Modello dell ambiente virtuale Il delivery dell informazione event User A User B Notify changes World Stuff C modify Avatar A Avatar B push operation pull + metadata Notification Service X Notification Service X unmarshalling marshalling Transport Transport Transport Transport Figura 3.3: La notifica delle modifiche. 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

Estratto dell'agenda dell'innovazione Smau Milano 2011. Speciale: I casi. Introduzione dell'area tematica. Il caso INCA CGIL

Estratto dell'agenda dell'innovazione Smau Milano 2011. Speciale: I casi. Introduzione dell'area tematica. Il caso INCA CGIL Estratto dell'agenda dell'innovazione Smau Milano 2011 Speciale: I casi Introduzione dell'area tematica Il caso INCA CGIL Innovare e competere con le ICT - PARTE I Cap.1 L innovazione nella gestione dei

Dettagli

Processi di Business e Sistemi di Gestione di Workflow: concetti di base. Prof. Giancarlo Fortino g.fortino@unical.it

Processi di Business e Sistemi di Gestione di Workflow: concetti di base. Prof. Giancarlo Fortino g.fortino@unical.it Processi di Business e Sistemi di Gestione di Workflow: concetti di base Prof. Giancarlo Fortino g.fortino@unical.it Introduzione Le aziende devono modificare la loro organizzazione per cogliere le nuove

Dettagli

Il linguaggio per la moderna progettazione dei processi aziendali

Il linguaggio per la moderna progettazione dei processi aziendali Il linguaggio per la moderna progettazione dei processi aziendali Organizzare un azienda sotto il profilo dei processi è oramai diventata una disciplina a cavallo tra la competenza aziendalistica ed informatica.

Dettagli

Introduzione. Laurea magistrale in ingegneria informatica A.A. 2011-2012. Leonardo Querzoni. Versioni al tratto. Versione 3D

Introduzione. Laurea magistrale in ingegneria informatica A.A. 2011-2012. Leonardo Querzoni. Versioni al tratto. Versione 3D Introduzione Versioni al tratto Versione 3D Sistemi La versione negativa Distribuiti 3D prevede l utilizzo dell ombra esclusivamente sul fondo colore Rosso Sapienza. Laurea magistrale in ingegneria informatica

Dettagli

Descrizione generale. Architettura del sistema

Descrizione generale. Architettura del sistema Descrizione generale Sister.Net nasce dall esigenza di avere un sistema generale di Cooperazione Applicativa tra Enti nel settore dell Informazione Geografica che consenta la realizzazione progressiva

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

Ingegneria del Software - Il Ciclo Lungo

Ingegneria del Software - Il Ciclo Lungo Ingegneria del Software - Il Ciclo Lungo Alessandro Martinelli alessandro.martinelli@unipv.it 10 Marzo 2014 Il Ciclo Lungo Il Versioning e la Condivisione di Codice Organizzazione dei Pacchetti La Modellazione

Dettagli

Centro Nazionale per l Informatica nella Pubblica Amministrazione. Gara a procedura aperta n. 1/2007. per l appalto dei

Centro Nazionale per l Informatica nella Pubblica Amministrazione. Gara a procedura aperta n. 1/2007. per l appalto dei Centro Nazionale per l Informatica nella Pubblica Amministrazione Gara a procedura aperta n. 1/2007 per l appalto dei Servizi di rilevazione e valutazione sullo stato di attuazione della normativa vigente

Dettagli

Groupware e workflow

Groupware e workflow Groupware e workflow Cesare Iacobelli Introduzione Groupware e workflow sono due parole molto usate ultimamente, che, a torto o a ragione, vengono quasi sempre associate. Si moltiplicano i convegni e le

Dettagli

TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE

TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE INDUSTRIA E ARTIGIANATO TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE DELLA

Dettagli

La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento Indice

La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento Indice Indice 1. Definizioni essenziali 2. Modelli di rete 3. Reti fisiche 4. Protocolli di rete 5. Modelli di riferimento 6. Raffronto tra modelli Architettura degli Elaboratori 2 - T. Vardanega Pagina 275 Definizioni

Dettagli

Indice generale VIII

Indice generale VIII Indice generale Indice dei box di approfondimento X Prefazione XII Ringraziamenti dell Editore XIV Guida alla lettura XV Capitolo 1 Introduzione 1 1 1 Trattamento dell informazione e strumenti per il trattamento

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

Dettagli

Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro.

Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro. Esercizio di GRUPPO: PROTOCOLLO INFORMATICO Mappa concettuale TECNOLOGIE DISPONIBILI Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro.

Dettagli

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4 Obiettivi Principali di un S.D. - 7 Tipi di Sistemi

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Giampiero Allamprese 0000260193 PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Reti di Calcolatori LS prof. Antonio Corradi A.A. 2007/2008 ABSTRACT L obiettivo di questo progetto è la realizzazione

Dettagli

ARCHIVI E LORO ORGANIZZAZIONI

ARCHIVI E LORO ORGANIZZAZIONI ARCHIVI E LORO ORGANIZZAZIONI Archivio: - insieme di registrazioni (record), ciascuna costituita da un insieme prefissato di informazioni elementari dette attributi (campi) - insieme di informazioni relative

Dettagli

Table of Contents. Definizione di Sistema Distribuito 15/03/2013

Table of Contents. Definizione di Sistema Distribuito 15/03/2013 Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4-7 - 13 Definizioni e Principali Caratteristiche

Dettagli

Lezione 1. Introduzione e Modellazione Concettuale

Lezione 1. Introduzione e Modellazione Concettuale Lezione 1 Introduzione e Modellazione Concettuale 1 Tipi di Database ed Applicazioni Database Numerici e Testuali Database Multimediali Geographic Information Systems (GIS) Data Warehouses Real-time and

Dettagli

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Introduzione ai Database! Tipologie di DB (gerarchici, reticolari, relazionali, oodb) Introduzione ai database Cos è un Database Cos e un Data Base Management System (DBMS)

Dettagli

Sistemi Distribuiti. Informatica B. Informatica B

Sistemi Distribuiti. Informatica B. Informatica B Sistemi Distribuiti Introduzione Che cos è un sistema distribuito? Un sistema distribuito è una collezione di computer indipendenti che appare all utente come un solo sistema coerente Da notare: le macchine

Dettagli

STANDARD A AFFRONTA GLI STRUMENTI INFORMATICI E DI COMUNICAZIONE NEL LORO USO

STANDARD A AFFRONTA GLI STRUMENTI INFORMATICI E DI COMUNICAZIONE NEL LORO USO 3.5 Area Tecnologica STANDARD A AFFRONTA GLI STRUMENTI INFORMATICI E DI COMUNICAZIONE NEL LORO USO E NELLA LORO FUNZIONE. Livello 1 1.1 Esplicita i propri bisogni di comunicazione e di organizzazione di

Dettagli

Titolo Perché scegliere Alfresco. Titolo1 ECM Alfresco

Titolo Perché scegliere Alfresco. Titolo1 ECM Alfresco Titolo Perché scegliere Alfresco Titolo1 ECM Alfresco 1 «1» Agenda Presentazione ECM Alfresco; Gli Strumenti di Alfresco; Le funzionalità messe a disposizione; Le caratteristiche Tecniche. 2 «2» ECM Alfresco

Dettagli

Gestione della supply chain e commercio collaborativo

Gestione della supply chain e commercio collaborativo Gestione della supply chain e commercio collaborativo Dr. Stefano Burigat Dipartimento di Matematica e Informatica Università di Udine www.dimi.uniud.it/burigat stefano.burigat@uniud.it La supply chain

Dettagli

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale 1. Livello infrastrutturale Il Cloud, inteso come un ampio insieme di risorse e servizi fruibili da Internet che possono essere dinamicamente

Dettagli

Simulazione prova scritta di sistemi Abacus per l Esame di Stato. Traccia n 1

Simulazione prova scritta di sistemi Abacus per l Esame di Stato. Traccia n 1 Simulazione prova scritta di sistemi Abacus per l Esame di Stato Traccia n 1 La condivisione delle informazioni e lo sviluppo delle risorse informatiche tramite cui esse possono venire memorizzate e scambiate

Dettagli

Ingegneria del Software UML - Unified Modeling Language

Ingegneria del Software UML - Unified Modeling Language Ingegneria del Software UML - Unified Modeling Language Obiettivi. Presentare un approccio visuale alla progettazione. Illustrare i vantaggi dell utilizzo di diagrammi nella fase di progettazione. Rispondere

Dettagli

CARATTERISTICA / MODULO

CARATTERISTICA / MODULO NextWare Doc è il prodotto che consente di amministrare semplicemente tutte le p roblematiche inerenti la gestione dei documenti; è rivolto sia la settore privato che alla Pubblica Amministrazione, e copre

Dettagli

Sistemi informatici in ambito radiologico

Sistemi informatici in ambito radiologico Sistemi informatici in ambito radiologico Dott. Ing. Andrea Badaloni A.A. 2015 2016 Reti di elaboratori, il modello a strati e i protocolli di comunicazione e di servizio Reti di elaboratori Definizioni

Dettagli

Indice. settembre 2008 Il File System 2

Indice. settembre 2008 Il File System 2 Il File System Indice 4. Il File System 5. Vantaggi del FS 6. Protezione 7. Condivisione 8. I file - 1 9. I file - 2 10. Attributi dei file 11. Directory 12. Livelli di astrazione - 1 13. Livelli di astrazione

Dettagli

Corso di Progettazione di sistemi multimediali

Corso di Progettazione di sistemi multimediali Corso di Progettazione di sistemi multimediali prof. Pierluigi Feliciati a.a.2012/13 Modulo 0 Progettare, sistemi, multimedialità: Definizioni, strumenti, ciclo di vita dei progetti, figure professionali

Dettagli

7. Architetture Software

7. Architetture Software 7. Architetture Software progettare la struttura Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 7. Architetture Software 1 / 20 Scopo della fase di design

Dettagli

uomo Software (sistema operativo) hardware

uomo Software (sistema operativo) hardware uomo Software (sistema operativo) hardware 1 Sistema operativo Insieme di programmi che svolgono funzioni essenziali per l uso del sistema di elaborazione Questi programmi sono i primi ad essere eseguiti

Dettagli

SDD System design document

SDD System design document UNIVERSITA DEGLI STUDI DI PALERMO FACOLTA DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA TESINA DI INGEGNERIA DEL SOFTWARE Progetto DocS (Documents Sharing) http://www.magsoft.it/progettodocs

Dettagli

La rete ci cambia la vita. Le persone sono interconnesse. Nessun luogo è remoto. Reti di computer ed Internet

La rete ci cambia la vita. Le persone sono interconnesse. Nessun luogo è remoto. Reti di computer ed Internet La rete ci cambia la vita Lo sviluppo delle comunicazioni in rete ha prodotto profondi cambiamenti: Reti di computer ed Internet nessun luogo è remoto le persone sono interconnesse le relazioni sociali

Dettagli

Reti di computer ed Internet

Reti di computer ed Internet Reti di computer ed Internet La rete ci cambia la vita Lo sviluppo delle comunicazioni in rete ha prodotto profondi cambiamenti: nessun luogo è remoto le persone sono interconnesse le relazioni sociali

Dettagli

PROGRAMMAZIONE ANUALE DEL DIPARTIMENTO DI INFORMATICA E TELECOMUNICAZIONI ISTITUTO TECNICO a.s. 2015-16

PROGRAMMAZIONE ANUALE DEL DIPARTIMENTO DI INFORMATICA E TELECOMUNICAZIONI ISTITUTO TECNICO a.s. 2015-16 PROGRAMMAZIONE ANUALE DEL DIPARTIMENTO DI INFORMATICA E TELECOMUNICAZIONI ISTITUTO TECNICO a.s. 2015-16 SECONDO BIENNIO Disciplina: INFORMATICA La disciplina Informatica concorre a far conseguire allo

Dettagli

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali CL AS SE INFORMATICA 6(3) 6(4) - 6(4) SISTEMI E RETI 4(2) 4(2) 4(2) TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI COMPETENZE 3 Essere in grado di sviluppare semplici applicazioni

Dettagli

UN SISTEMA DI ARCHIVI AUDIOVISIVI. Accesso on line ai metadati e ai dati

UN SISTEMA DI ARCHIVI AUDIOVISIVI. Accesso on line ai metadati e ai dati scaletta per seminario 14-12-05 UN SISTEMA DI ARCHIVI AUDIOVISIVI sul tema Accesso on line ai metadati e ai dati a cura di Francesco Baldi Discoteca di Stato e Museo dell Audiovisivo novembre 2005 Quadro

Dettagli

Laboratorio di Informatica. Alfonso Miola. Reti di calcolatori. Dispensa C-01 Settembre 2005. Laboratorio di Informatica. C-01- Reti di Calcolatori

Laboratorio di Informatica. Alfonso Miola. Reti di calcolatori. Dispensa C-01 Settembre 2005. Laboratorio di Informatica. C-01- Reti di Calcolatori Alfonso Miola Reti di calcolatori Dispensa C-01 Settembre 2005 1 Nota bene Il presente materiale didattico è derivato dalla dispensa prodotta da Luca Cabibbo Dip. Informatica e Automazione Università degli

Dettagli

INDIRIZZO Informatica e Telecomunicazioni

INDIRIZZO Informatica e Telecomunicazioni ISTRUZIONE TECNICA INDIRIZZO Informatica e Telecomunicazioni L indirizzo Informatica e Telecomunicazioni ha lo scopo di far acquisire allo studente, al termine del percorso quinquennale, specifiche competenze

Dettagli

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI

Dettagli

Le reti di calcolatori

Le reti di calcolatori Le reti di calcolatori 1 La storia Computer grandi e costosi Gli utenti potevano accerdervi tramite telescriventi per i telex o i telegrammi usando le normali linee telefoniche Successivamente le macchine

Dettagli

PROGETTO - Ingegneria del Software. Università degli Studi di Milano Polo di Crema. Corso di laurea in Scienze Matematiche, Fisiche e Naturali

PROGETTO - Ingegneria del Software. Università degli Studi di Milano Polo di Crema. Corso di laurea in Scienze Matematiche, Fisiche e Naturali Università degli Studi di Milano Polo di Crema Corso di laurea in Scienze Matematiche, Fisiche e Naturali INFORMATICA Corso di Ingegneria del Software progetto IL SISTEMA CALENDAR Presentato al dott. Paolo

Dettagli

Linguaggi e Paradigmi di Programmazione

Linguaggi e Paradigmi di Programmazione Linguaggi e Paradigmi di Programmazione Cos è un linguaggio Definizione 1 Un linguaggio è un insieme di parole e di metodi di combinazione delle parole usati e compresi da una comunità di persone. È una

Dettagli

Elementi di Informatica

Elementi di Informatica Reti di calcolatori Febbraio 2007 1 Contenuti Accesso al World Wide Web Reti di calcolatori scambio di dati tra calcolatori connessione in rete di calcolatori reti di reti di calcolatori architettura a

Dettagli

INTRODUZIONE A RETI E PROTOCOLLI

INTRODUZIONE A RETI E PROTOCOLLI PARTE 1 INTRODUZIONE A RETI E PROTOCOLLI Parte 1 Modulo 1: Introduzione alle reti Perché le reti tra computer? Collegamenti remoti a mainframe (< anni 70) Informatica distribuita vs informatica monolitica

Dettagli

BOZZA DEL 06/09/2011

BOZZA DEL 06/09/2011 ARTICOLAZIONE: INFORMATICA Disciplina: COMPLEMENTI DI MATEMATICA (C4) Il docente di Complementi di matematica concorre a far conseguire allo studente, al termine del percorso quinquennale, i seguenti risultati

Dettagli

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE

Dettagli

PROGRAMMAZIONE INFORMATICA PRIMO BIENNIO. Opzione Scienze Applicate

PROGRAMMAZIONE INFORMATICA PRIMO BIENNIO. Opzione Scienze Applicate PROGRAMMAZIONE INFORMATICA PRIMO BIENNIO Opzione Scienze Applicate Anno scolastico 2015-2016 Programmazione di Informatica pag. 2 / 8 INFORMATICA - PRIMO BIENNIO OBIETTIVI SPECIFICI DI APPRENDIMENTO DELL

Dettagli

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File system verso DBSM Vantaggi di un DBMS Modelli dei dati Utenti

Dettagli

Programma ELISA - Proposta progettuale

Programma ELISA - Proposta progettuale Macro descrizione del progetto Il progetto intende fornire alle amministrazioni locali gli strumenti per un ottimale governo dell erogazione dei servizi sui diversi canali e per la definizione di concrete

Dettagli

Breve introduzione al Calcolo Evoluzionistico

Breve introduzione al Calcolo Evoluzionistico Breve introduzione al Calcolo Evoluzionistico Stefano Cagnoni Dipartimento di Ingegneria dell Informazione, Università di Parma cagnoni@ce.unipr.it 1 Introduzione Il mondo fisico ed i fenomeni naturali

Dettagli

SPECIFICHE TECNICO-FUNZIONALI FORNITURA SOFTWARE APPLICATIVO PROTOCOLLO ATTI E RILEVAZIONE PRESENZE

SPECIFICHE TECNICO-FUNZIONALI FORNITURA SOFTWARE APPLICATIVO PROTOCOLLO ATTI E RILEVAZIONE PRESENZE SPECIFICHE TECNICO-FUNZIONALI FORNITURA SOFTWARE APPLICATIVO PROTOCOLLO ATTI E RILEVAZIONE PRESENZE 1. IL SOFTWARE APPLICATIVO PROGETTOENTE 1.1 Linee guida generali: Un software aperto che Vi accompagna

Dettagli

1 MODULO: Visual basic.net Dati strutturati. Finalità: Gestione di dati strutturati

1 MODULO: Visual basic.net Dati strutturati. Finalità: Gestione di dati strutturati Istituto di Istruzione Superiore via Salvini 24 Roma Liceo M. Azzarita Liceo delle scienze applicate Materia:Informatica Programmazione a.s. 2015-2016 Classi 4 e Obiettivi disciplinari secondo biennio

Dettagli

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO ELEMENTI FONDAMENTALI PER LO SVILUPPO DI SISTEMI INFORMATIVI ELABORAZIONE DI

Dettagli

CONTENT MANAGEMENT SYSTEM

CONTENT MANAGEMENT SYSTEM CONTENT MANAGEMENT SYSTEM P-2 PARLARE IN MULTICANALE Creare un portale complesso e ricco di informazioni continuamente aggiornate, disponibile su più canali (web, mobile, iphone, ipad) richiede competenze

Dettagli

SIASFi: il sistema ed il suo sviluppo

SIASFi: il sistema ed il suo sviluppo SIASFI: IL SISTEMA ED IL SUO SVILUPPO 187 SIASFi: il sistema ed il suo sviluppo Antonio Ronca Il progetto SIASFi nasce dall esperienza maturata da parte dell Archivio di Stato di Firenze nella gestione

Dettagli

Introduzione ai sistemi di basi di dati

Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Alessandro.bardine@gmail.com alessandro.bardine@iet.unipi.it Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File

Dettagli

Carta dei Servizi per lo Studente. a.a. 2014/2015

Carta dei Servizi per lo Studente. a.a. 2014/2015 Carta dei Servizi per lo Studente a.a. 2014/2015 INDICE ART. 1 PRINCIPI GENERALI E FINALITÀ... 3 ART. 2 CONTRATTO CON GLI STUDENTI... 3 ART. 3 TUTELA DEI DATI PERSONALI... 3 ART. 4 MATERIALE DIDATTICO...

Dettagli

Reti di Telecomunicazione Lezione 6

Reti di Telecomunicazione Lezione 6 Reti di Telecomunicazione Lezione 6 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Lo strato di applicazione protocolli Programma della lezione Applicazioni di rete client - server

Dettagli

Istituti Tecnici - Settore tecnologico Indirizzo Informatica e telecomunicazioni Articolazione Informatica

Istituti Tecnici - Settore tecnologico Indirizzo Informatica e telecomunicazioni Articolazione Informatica Linee guida Secondo ciclo di istruzione Istituti Tecnici - Settore tecnologico Indirizzo Informatica e telecomunicazioni Quadro orario generale 1 biennio 2 biennio 5 anno 1^ 2^ 3^ 4^ 5^ Sistemi e reti**

Dettagli

WHIT E PAPER. skipper

WHIT E PAPER. skipper WHIT E PAPER skipper Giugno 2003 schedulatore a capacità finita Skipper è un programma di elevato contenuto tecnologico che non richiede particolari installazioni. Si interfaccia con la base dati (comune

Dettagli

2G, l evoluzione della piattaforma Team nel Web 2.0 Roma, 7 dicembre 2011. Andrea Carnevali R&D Director GESINF S.r.l.

2G, l evoluzione della piattaforma Team nel Web 2.0 Roma, 7 dicembre 2011. Andrea Carnevali R&D Director GESINF S.r.l. 2G, l evoluzione della piattaforma Team nel Web 2.0 Roma, 7 dicembre 2011 Andrea Carnevali R&D Director GESINF S.r.l. Il progetto 2G è il nome della piattaforma che consentirà l evoluzione tecnologica

Dettagli

Corso di Applicazioni Telematiche

Corso di Applicazioni Telematiche Corso di Applicazioni Telematiche Lezione n.1 Prof. Roberto Canonico Università degli Studi di Napoli Federico II Facoltà di Ingegneria Obiettivi del corso Supporti didattici Modalità d esame Panoramica

Dettagli

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014 Processi di business sovra-regionali relativi ai sistemi regionali di FSE Versione 1.0 24 Giugno 2014 1 Indice Indice... 2 Indice delle figure... 3 Indice delle tabelle... 4 Obiettivi del documento...

Dettagli

Indirizzi Internet e. I livelli di trasporto delle informazioni. Comunicazione e naming in Internet

Indirizzi Internet e. I livelli di trasporto delle informazioni. Comunicazione e naming in Internet Indirizzi Internet e Protocolli I livelli di trasporto delle informazioni Comunicazione e naming in Internet Tre nuovi standard Sistema di indirizzamento delle risorse (URL) Linguaggio HTML Protocollo

Dettagli

Concetti base. Impianti Informatici. Web application

Concetti base. Impianti Informatici. Web application Concetti base Web application La diffusione del World Wide Web 2 Supporto ai ricercatori Organizzazione documentazione Condivisione informazioni Scambio di informazioni di qualsiasi natura Chat Forum Intranet

Dettagli

Un approccio per sviluppare applicazioni di. E Democracy basato su ruoli per agenti mobili

Un approccio per sviluppare applicazioni di. E Democracy basato su ruoli per agenti mobili UNIVERSITÀ DEGLI STUDI DI MODENA E REGGIO EMILIA Facoltà di Ingegneria Sede di Modena Corso di Laurea in Ingegneria Informatica Un approccio per sviluppare applicazioni di E Democracy basato su ruoli per

Dettagli

Corso di Laurea in Ingegneria Informatica Algoritmi e basi di dati Modulo Basi di dati a.a. 2010-2011

Corso di Laurea in Ingegneria Informatica Algoritmi e basi di dati Modulo Basi di dati a.a. 2010-2011 Corso di Laurea in Ingegneria Informatica Algoritmi e basi di dati Modulo Basi di dati a.a. 2010-2011 2011 Docente: Gigliola Vaglini Docente laboratorio: Alessandro Lori 1 Obiettivi del corso Imparare

Dettagli

Small Software Factories

Small Software Factories NEWITS SERVIZI PER LE NUOVE TECNOLOGIE DELL INFORMAZIONE Small Software Factories Sviluppare software in piccole realtà per grandi clienti Software Configuration Management 1 Software Configuration Management

Dettagli

Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07

Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07 Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07 1. Introduzione...3 1.2. Application vs Tool... 3 2. Componenti logiche di un modello... 6 3. Ontologie e Semantic

Dettagli

The project. http://www.interdatanet.org

The project. http://www.interdatanet.org Università degli Studi di Firenze Facoltà di Ingegneria Dipartimento di Elettronica e Telecomunicazioni (DET) Laboratorio di Tecnologie della Telematica (LTT) The project http://www.interdatanet.org WORK

Dettagli

Realizzazione di un prototipo di un software web based per la gestione di un inventario comunale

Realizzazione di un prototipo di un software web based per la gestione di un inventario comunale tesi di laurea inventario comunale Anno Accademico 2009/2010 relatore Ch.mo prof. Porfirio Tramontana correlatore Ch.mo Ing. Luigi Pontillo candidato Michele Vitelli Matr. 534 2170 Redazione dell Inventario

Dettagli

La conservazione dei documenti in ambiente digitale: opportunità e criticità

La conservazione dei documenti in ambiente digitale: opportunità e criticità La conservazione dei documenti in ambiente digitale: opportunità e criticità di Guglielmo Longobardi Premessa Dopo un lungo periodo di immobilismo legislativo, che vedeva ancora in vigore il regio decreto

Dettagli

Gestione della conoscenza

Gestione della conoscenza Gestione della conoscenza Prof.ssa Enrica Gentile a.a. 2011-2012 Automazione del lavoro d ufficio Chiunque può avvalersi di un computer allo scopo di snellire ed ottimizzare il proprio lavoro Voler fare

Dettagli

INFIN OLTRE LA SEMPLICE ARCHIVIAZIONE

INFIN OLTRE LA SEMPLICE ARCHIVIAZIONE OLTRE LA SEMPLICE ARCHIVIAZIONE INFIN Ricezione, Acquisizione, Protocollazione, Classificazione, Condivisione, Distribuzione e Gestione dei processi documentali. I TUOI DOCUMENTI DIVENTANO INFORMAZIONI

Dettagli

Sogni, bisogni, aspettative di persone normalmente differenti. 25 anni di lavoro della cooperativa Dedalus, Gesco edizioni, Napoli, 2006

Sogni, bisogni, aspettative di persone normalmente differenti. 25 anni di lavoro della cooperativa Dedalus, Gesco edizioni, Napoli, 2006 Sogni, bisogni, aspettative di persone normalmente differenti. 25 anni di lavoro della cooperativa Dedalus, Gesco edizioni, Napoli, 2006 La Rete di Andrea Morniroli Premessa In questi ultimi anni è cresciuta

Dettagli

5 Gestione dei progetti software. 5.1 Attività gestionale. Sistemi Informativi I Lezioni di Ingegneria del Software

5 Gestione dei progetti software. 5.1 Attività gestionale. Sistemi Informativi I Lezioni di Ingegneria del Software 5 Gestione dei progetti software. Dopo aver completato lo studio del ciclo di vita del software, in questa parte vengono discussi gli aspetti gestionali della produzione del software. Vengono esaminate

Dettagli

LA PIATTAFORMA COMOL L E-LEARNING CENTER PER LE AZIENDE

LA PIATTAFORMA COMOL L E-LEARNING CENTER PER LE AZIENDE LA PIATTAFORMA COMOL L E-LEARNING CENTER PER LE AZIENDE Edutech Vi Offre Un Ambiente Dedicato Per La Formazione A Distanza Cosa vi offre EduTech EduTech, grazie alla collaborazione con il Dipartimento

Dettagli

CON LA CARTA DEI SERVIZI, I NOSTRI UTENTI SONO SEMPRE AL CENTRO DELLE NOSTRE ATTENZIONI.

CON LA CARTA DEI SERVIZI, I NOSTRI UTENTI SONO SEMPRE AL CENTRO DELLE NOSTRE ATTENZIONI. CARTA DEI SERVIZI La qualità del servizio nei confronti dell Utente e la soddisfazione per l utilizzo delle soluzioni sono obiettivi strategici per Sistemi. Le soluzioni software Sistemi, siano esse installate

Dettagli

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Relatore Chiarissimo

Dettagli

File System Distribuiti

File System Distribuiti File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema 20.1 Introduzione File System Distribuito

Dettagli

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema Introduzione File System Distribuito

Dettagli

Sistema Operativo Compilatore

Sistema Operativo Compilatore MASTER Information Technology Excellence Road (I.T.E.R.) Sistema Operativo Compilatore Maurizio Palesi Salvatore Serrano Master ITER Informatica di Base Maurizio Palesi, Salvatore Serrano 1 Il Sistema

Dettagli

CdL MAGISTRALE in INFORMATICA A.A. 2014-15 corso di Sistemi Distribuiti. 8. Le architetture (prima parte) Prof. S.Pizzutilo

CdL MAGISTRALE in INFORMATICA A.A. 2014-15 corso di Sistemi Distribuiti. 8. Le architetture (prima parte) Prof. S.Pizzutilo CdL MAGISTRALE in INFORMATICA A.A. 2014-15 corso di Sistemi Distribuiti 8. Le architetture (prima parte) Prof. S.Pizzutilo I Sistemi Distribuiti Un Sistema Distribuito è un insieme di processori indipendenti

Dettagli

LABORATORIO DI TELEMATICA

LABORATORIO DI TELEMATICA LABORATORIO DI TELEMATICA COGNOME: Ronchi NOME: Valerio NUMERO MATRICOLA: 41210 CORSO DI LAUREA: Ingegneria Informatica TEMA: Analisi del protocollo FTP File Transfer Protocol File Transfer Protocol (FTP)

Dettagli

Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci

Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci Corso di Laurea Magistrale in Ingegneria per l Ambiente e il Territorio A.A. 2014-2015 Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci Strutture di dati: DB e DBMS DATO E INFORMAZIONE Dato: insieme

Dettagli

SCADA: struttura modulare

SCADA: struttura modulare Sistemi per il controllo di supervisione e l acquisizione dati o (Supervisory Control And Data Acquisition) Sistema informatico di misura e controllo distribuito per il monitoraggio di processi fisici

Dettagli

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione Processi (di sviluppo del) software Fase di Analisi dei Requisiti Un processo software descrive le attività (o task) necessarie allo sviluppo di un prodotto software e come queste attività sono collegate

Dettagli

Sistemi di gestione delle basi di dati. T. Catarci, M. Scannapieco, Corso di Basi di Dati, A.A. 2008/2009, Sapienza Università di Roma

Sistemi di gestione delle basi di dati. T. Catarci, M. Scannapieco, Corso di Basi di Dati, A.A. 2008/2009, Sapienza Università di Roma Sistemi di gestione delle basi di dati 1 Cos è un DBMS? Una collezione integrata molto grande di dati Modella organizzazioni del mondo reale Entità (ad esempio studenti, corsi) Relazioni (ad esempio, Madonna

Dettagli

Evoluzione dell applicazione mobile Travel Intoscana e realizzazione del sistema delle applicazioni territoriali

Evoluzione dell applicazione mobile Travel Intoscana e realizzazione del sistema delle applicazioni territoriali Evoluzione dell applicazione mobile Travel Intoscana e realizzazione del sistema delle applicazioni territoriali CIG: 6261506635 Specifiche tecniche Pagina 1 Sommario 1. Oggetto del servizio... 3 1.1 Contesto

Dettagli

Sistemi Distribuiti. Libri di Testo

Sistemi Distribuiti. Libri di Testo Sistemi Distribuiti Rocco Aversa Tel. 0815010268 rocco.aversa@unina2.it it Ricevimento: Martedì 14:16 Giovedì 14:16 1 Libri di Testo Testo Principale A.S. Tanenbaum, M. van Steen, Distributed Systems (2

Dettagli

Reti combinatorie: Codificatori

Reti combinatorie: Codificatori Reti combinatorie: Codificatori P. Marincola (Rev..2) Come si ricorderà, i decodificatori hanno essenzialmente il compito di convertire un codice binario a n bit in un codice -su-m, dovem =2 n. In molte

Dettagli

SINPAWEB corso per Tecnico della programmazione e dello sviluppo di siti internet e pagine web co.reg 58036 matricola 2012LU1072

SINPAWEB corso per Tecnico della programmazione e dello sviluppo di siti internet e pagine web co.reg 58036 matricola 2012LU1072 Provincia di Lucca Servizio Istruzione, Formazione e Lavoro. Sviluppo Economico SINPAWEB corso per Tecnico della programmazione e dello sviluppo di siti internet e pagine web co.reg 58036 matricola 2012LU1072

Dettagli

IL CRM NELL ERA DEL CLIENTE. modi in cui un CRM moderno può aiutarti a deliziare i tuoi clienti e contribuire alla tua crescita.

IL CRM NELL ERA DEL CLIENTE. modi in cui un CRM moderno può aiutarti a deliziare i tuoi clienti e contribuire alla tua crescita. IL CRM NELL ERA DEL CLIENTE modi in cui un CRM moderno può aiutarti a deliziare i tuoi clienti e contribuire alla tua crescita ebook 1 SOMMARIO Introduzione Allineare meglio le vendite e il marketing Creare

Dettagli

PIANO DI LAVORO (a.s. 2015/2016)

PIANO DI LAVORO (a.s. 2015/2016) Istituto Tecnico Commerciale Statale e per Geometri E. Fermi Pontedera (PI) Via Firenze, 51 - Tel. 0587/213400 - Fax 0587/52742 http://www.itcgfermi.it E-mail: mail@itcgfermi.it PIANO DI LAVORO (a.s. 2015/2016)

Dettagli

Sistemi Distribuiti Introduzione al corso

Sistemi Distribuiti Introduzione al corso Altri testi di consultazione Sistemi Distribuiti Introduzione al corso Testo di riferimento G.Coulouris, J.Dollimore and T.Kindberg Distributed Systems: Concepts and Design IV Ed., Addison-Wesley 2005

Dettagli