Ingegneria del Software

Report
PROVA FINALE
(INGEGNERIA DEL SOFTWARE)
Davide Mazza
[email protected]
http://home.dei.polimi.it/mazza
Prova Finale di Ingegneria del Software
Configuration Management
Gestione delle configurazioni
Configuration management (CM)
• E` un processo che controlla le modifiche
fatte a un sistema e gestisce le diverse
versioni di un prodotto che può evolvere
• Nel nostro contesto: cambiamenti nel
software
– Software Configuration Management
(SCM)
Prova Finale di Ingegneria del Software
Sviluppo del Software
• I cambiamenti sono continui, e concorrenti
• I cambiamenti danno luogo a nuove versioni
– Con certi livelli di correttezza (es. Varie versioni di un
modulo mano a mano che vengono individuati e
eliminati i malfunzionamenti
– Per macchine e sistemi operativi diversi (una versione
per Unix e una per Windows)
– Con diverse funzionalità
– Per soddisfare diversi requisiti
Prova Finale di Ingegneria del Software
Doppia manutenzione
• In molte organizzazioni, il codice riutilizzabile
viene ricopiato, modificato e/o arricchito in modo
da costituire nuovi programmi.
– due (o più) prodotti condividono alcuni moduli e lo
fanno mantenendo una copia separate dei medesimi
A
B
C
D
A
B
C
D
Prodotto A
Prova Finale di Ingegneria del Software
Prodotto B
Doppia manutenzione: problema
Mancato aggiornamento di una (o più) delle copie esistenti
A
B
C
D1
A
B
C1
D
Prodotto 1
Modifica di D
Prova Finale di Ingegneria del Software
Prodotto 2
Modifica di C
Come evitare i disallineamenti?
Usare un "magazzino" (repository) condiviso
Fare copie locali ogni volta che serve un modulo
Prova Finale di Ingegneria del Software
Copie locali
 si usa uno schema di sviluppo a repository condiviso e
spazio di lavoro privato
• si impone che ciascun programmatore possa operare
solo su una copia di un modulo, ricavata da un
repository centralizzato e condiviso.
• Una volta che la correzione è stata completata e
certificata, si ricopia nel repository la versione
aggiornata del modulo in oggetto.
Prova Finale di Ingegneria del Software
Repository comune e spazio di lavoro privato
Check out
Check out
A
A
B
A1
C
C
F
Commit
repository
Commit
spazio di lavoro privato
Prova Finale di Ingegneria del Software
C1
Conflitti di aggiornamento
• In generale, nel caso di accesso in parallelo ad
uno stesso modulo da parte di diversi
programmatori attraverso il meccanismo delle
copie locali, può accadere che vengano perse
alcune delle modifiche apportate.
Check out
Check out
A
A
A1
B
B
C
F
BX
conflitto
Commit
Prova Finale di Ingegneria del Software
Commit
B
C
BY
C1
Modifiche simultanee di dati condivisi
• Diventa necessario coordinare la modifica
concorrente ai programmi in corso di sviluppo.
– In presenza di un’unica copia di tutti i moduli, se
diversi programmatori accedono alla stessa porzione
di codice per apportare le modifiche che ciascuno
ritiene necessarie …
– le modifiche introdotte da uno sviluppatore hanno un
impatto su moduli sviluppati da altri …
– possono gravemente interferire l'una con le altre
provocando malfunzionamenti del programma o gravi
errori.
A
F
B
usa
Prova Finale di Ingegneria del Software
C
Il problema dei conflitti di aggiornamento
 Con repository condiviso e aree di lavoro private…
 lo schema check-out, check-in con lock
• check-out in sola lettura
• check-out per modifica (lock)
• commit della nuova versione (revisione)
 Rami separati di sviluppo
Prova Finale di Ingegneria del Software
13
Gestione delle configurazioni
 Problematiche gestite:
• Modifiche concorrenti da parte di più utenti
• Storico delle modifiche
• Segnalazione e gestione dei conflitti
• Ripristino delle versioni precedenti
 Necessario quando gli sviluppatori di un software sono >1
 Molto utile anche per il programmatore singolo
Prova Finale di Ingegneria del Software
14
Strumenti per la gestione delle configurazioni
 Principali software per il controllo di versione in ambito
open source:
1. CVS: Cuncurrent Versions System (1985)
2. SVN: Subversion (2000)
3. GIT (2005)
Prova Finale di Ingegneria del Software
Subversion
16
Subversion
 Open source
 Architettura Client/Server
 Adatto per il controllo versione di codice sorgente (ma anche per
progetti diversi come documenti latex, pagine html, …)
 Nasce come alternativa a CVS (ormai obsoleto)
 Scaricabile da http://subversion.apache.org/
Prova Finale di Ingegneria del Software
17
Miglioramenti rispetto a CVS
 Versionamento delle directory:
• CVS considera solo i singoli file
• SVN controlla anche il contenuto delle directory e quindi
spostamento e copia dei file
 Commits atomici:
• Commit applicati in blocco
• Se ci sono conflitti l’intero commit è bloccato in modo da evitare
versioni incomplete
 Versionamento dei metadati:
• SVN mantiene lo storico delle modifiche alle proprietà di file e
cartelle
 Astrazione dal livello di rete:
• In questo modo possono essere usati diversi protocolli come per
esempio HTTP
Prova Finale di Ingegneria del Software
18
Repository
 Il repository è il deposito dove risiedono i nostri dati.
 E’ un server su cui gira il pacchetto server di Subversion
 È possibile creare diversi repository su ogni server Subversion:
• ciascuno di essi è accessibile con un URL specifico.
 Ad ogni repository viene associato un numero di revisione:
• E’ inizialmente zero
• Viene incrementato ad ogni modifica atomica
• Identificare univocamente tutte le versioni storiche del sistema
Prova Finale di Ingegneria del Software
19
Client
 Il Client si connette al server per:
• Scaricare la copia locale iniziale (checkout)
• Aggiornale la copia locale (update)
• Mandare le modifiche locali (commit)
 Software per il client:
• Quello ufficiale a riga di comando
• Software con GUI (tipo TortoiseSVN per Windows)
• Plugin integrati negli IDE più noti come Eclipse e VisualStudio
Prova Finale di Ingegneria del Software
20
Checkout
svn checkout http://www.servensvn.it/progetto/
[directory]
 Il checkout crea nel client la copia locale di lavoro
 Nella copia locale vengono copiati tutti i file dello copia più aggiornata
presente nel repository
 Viene indicato il numero di revisione corrente
 Se il repository è appena stato creato?
• Il primo checkout creerà un cartella “vuota”
• Il numero di visione iniziale è zero
• Vanno aggiunti i file che saranno sotto controllo di versione
− Copio il file nella cartella
− Eseguo “svn add nome_file”
Prova Finale di Ingegneria del Software
21
Checkout
Prova Finale di Ingegneria del Software
22
Commit e Update
svn commit [file/directory]
 Il comando commit esegue un upload sul repository di tutte le
modifiche locali:
• File modificati
• File/Cartelle aggiunti
• File/Cartelle rimossi
• File/Cartelle spostati o rinominati
svn update
 Il comando update aggiorna la copia locale con l’ultima versione
presente sul repository
• E’ buona norma fare un update prima di un commit
Prova Finale di Ingegneria del Software
23
Commentare i Commit
 E’ buona norma aggiungere un commento ad ogni commit
• In quali casi? Sempre!
 Guardando lo storico dei commenti è possibile capire quali aspetti del
progetto sono in corso si sviluppo
 Molto utile per coordinare il lavoro di più programmatori
 Utile anche per trovare bachi relativi ad una certa funzionalità
• Basta cercare il commit in cui è stata aggiornata quella particolare
funzionalità
 Sempre meglio mettere nello stesso commit modifiche correlate tra
loro (implementano o aggiornano una particolare funzionalità)
Prova Finale di Ingegneria del Software
25
Ulteriori comandi
 SVN tiene traccia dello spostamento, copia rimozione di file e cartelle
• Solo se vengono usati opportuni comandi
 svn add
 svn remove
 svn copy
 svn move
Prova Finale di Ingegneria del Software
26
Numeri di Revisione
Repository vuoto
Revisione: 0
Revisione: 1
Test.java
Revisione: 2
Test.java
Rubrica.java Cerchio.java
Revisione: 3
Contatto.java Rubrica.java
Cerchio.java
Prova Finale di Ingegneria del Software
27
Estrazione di una Revisione
 svn –r <numero revisione>
 svn –r HEAD
 svn –r PREV
 Perché tornare ad una versione precedente?
• Abbiamo combinato un casino e vogliamo fare un rollback (merge)
• Vogliamo capire le differenze che ci sono con una versione
precedente
• Ci serve distribuire una versione precedente
−
Per esempio, se è compatibile con librerie vecchie
Prova Finale di Ingegneria del Software
28
Memorizzazione delle versioni
 Approccio molto efficiente:
• Duplicazioni virtuali
• File di testo compressi
 Le modifiche sono memorizzate per differenze:
 Quando viene aggiunta una nuova versione del file:
• Non viene memorizzata una copia della nuova versione
• Solo le righe aggiunte rispetto alla versione precedente (delta)
int main (){
int a;
int b;
int somma;
somma=a+b;
}
int main (){
int a;
int b;
int somma;
somma=a+b;
printf(“somma: %d,somma”);
}
 Comportamento diverso per i file di testo e per i file binari
Prova Finale di Ingegneria del Software
29
Quali file mettere sotto il controllo di versione?
 Ora che sappiamo come funziona svn, quali file mettere sotto
controllo di versione? Perché?
 I file Java, C, C++ ?
 Gli eseguibili?
 Le immagini?
 I file Latex?
 I PDF?
Prova Finale di Ingegneria del Software
30
Memorizzazione nella copia locale
 Nella copia locale tutte le informazioni sul controllo di versione sono
contenute nelle cartelle nascoste “.snv”
• E’ presente una cartella “.svn” in ogni cartella sotto controllo di
versione
 Se i file di progetto vengono distribuiti è importante cancellare le
directory “.svn”
• commit accidentali da parte di altri utenti!
• Usare: svn export
Prova Finale di Ingegneria del Software
31
Gestione dei Conflitti
 Paradigma Lock-Modify-Merge:
• svn lock <target>
• svn unlock <target>
• --force (per forzare il comando)
 Scomodo!
• Bisogna lockare a priori tutti i file che forse verranno modificati
• Utile solo come meccanismo di segnalazione tra gli utenti
Prova Finale di Ingegneria del Software
32
Gestione dei Conflitti
 In generale si adotta un paradigma più libero:
• Ognuno utente può modificare qualsiasi file
• Se dopo un commit c’è un conflitto, lo risolvo!
 Ipotesi: generalmente i programmatori lavorano a parti diverse del
progetto. Il conflitto è un evento raro.
 Se si lavora a parti diverse dello stesso file (metodi di una Classe)
non vi è nessuno conflitto.
 Subversion segnala un conflitto solo quando le modifiche coinvolgono
le stesse righe di codice:
• Vengono mostrate le due versioni in conflitto
• Scelgo quale delle due versioni è quella corretta
• Oppure faccio il merge manuale!
Prova Finale di Ingegneria del Software
33
Branching
 Le Branch sono delle copie duplicate di un
progetto
• Per sviluppare versioni differenti di un
programma
• Per creare delle versioni safe da modificare
per testare funzionalità che non saranno
integrate nel programma finale
 Quale comando di Svn si può usare per creare
una Branch?
 La creazione di una Branch è un operazione
veloce?
Prova Finale di Ingegneria del Software
34
Etichette (Tag)
 Le etichette sono un modo per dare un nome esplicito ad una
particolare versione del progetto
 Per esempio: “Release 1.0”
 Anche in questo caso si usa un “svn copy”
 Nessuna duplicazione effettiva di dati (nel repository)
 Permette di trovare facilmente nel repository i file che fanno parte di
una versione taggata
 E’ un’alternativa più elegante dal segnarsi il numero di revisione di
una particolare release
Prova Finale di Ingegneria del Software
36
Riferimenti
 Guida HTML.it
http://programmazione.html.it/guide/leggi/147/guida-subversion/
 Guida Ufficiale
http://svnbook.red-bean.com/index.en.html
 Tutorial Introduttivo:
http://www.simonecarletti.it/blog/2007/03/strumenti-di-svilupposubversion-svn/
Prova Finale di Ingegneria del Software

similar documents