Prova Finale di Ingegneria del Software

PROVA FINALE (INGEGNERIA DEL SOFTWARE)

Davide Mazza

davide.mazza@polimi.it

http://home.dei.polimi.it/mazza

Configuration Management

Prova Finale di Ingegneria del Software

Gestione delle configurazioniConfiguration 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

Prodotto A

A B C

D

A B C

D

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

Prodotto B

Prova Finale di Ingegneria del Software

Prodotto 1

A B C

D1

A B C1

D

Prodotto 2

Modifica di D

Modifica di C

Doppia manutenzione: problema

Mancato aggiornamento di una (o più) delle copie esistenti

Prova Finale di Ingegneria del Software

Come evitare i disallineamenti?

Usare un "magazzino" (repository) condivisoFare 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

A B C

FA

Check out Check out

A1

Commit

C C1

Commitrepository

spazio di lavoro privato

Repository comune e spazio di lavoro privato

Prova Finale di Ingegneria del Software

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.

A B C

FB CA B

A1 BX BY C1

Check out Check out

CommitCommit

conflitto

Prova Finale di Ingegneria del Software

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 B C

Fusa

Prova Finale di Ingegneria del Software

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

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

13

Prova Finale di Ingegneria del Software

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)

14

Subversion

Prova Finale di Ingegneria del Software

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/

16

Prova Finale di Ingegneria del Software

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

17

Prova Finale di Ingegneria del Software

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

18

Prova Finale di Ingegneria del Software

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

19

Prova Finale di Ingegneria del Software

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”

20

Prova Finale di Ingegneria del Software

Checkout21

Prova Finale di Ingegneria del Software

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

22

Prova Finale di Ingegneria del Software

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

23

Prova Finale di Ingegneria del Software

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

25

Prova Finale di Ingegneria del Software

Numeri di Revisione26

Revisione: 0

Revisione: 1

Revisione: 2

Revisione: 3

Test.java

Test.java Rubrica.java

Repository vuoto

Contatto.java Rubrica.java

Cerchio.java

Cerchio.java

Prova Finale di Ingegneria del Software

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

27

Prova Finale di Ingegneria del Software

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)

Comportamento diverso per i file di testo e per i file binari

28

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”);}

Prova Finale di Ingegneria del Software

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?

29

Prova Finale di Ingegneria del Software

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

30

Prova Finale di Ingegneria del Software

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

31

Prova Finale di Ingegneria del Software

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!

32

Prova Finale di Ingegneria del Software

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?

33

Prova Finale di Ingegneria del Software

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

34

Prova Finale di Ingegneria del Software

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-sviluppo-subversion-svn/

36