UML e git

Nei diagrammi di tipo strutturale abbiamo il diagramma

delle classi che è quello più vicino alla realtà perchè

quando modelliamo la realtà lo facciamo mediante le

classi, il diagrmama delle classi è quello che ci permette di

rappresentare graficamente le classi che compongono la

nostra soluzione e definirne l'interazione.

comportamentali permettono di descrivere quali sono le

· funzionalità offerte dal sistema.

Abbiamo poi il diagramma dei componenti e di

Deployment, anche questi ci fanno vedere quali sono i

componenti del sistema ma un componente può avere da 1

a n classi, abbiamo poi il diagramma degli Object, il

diagramma dei Package per rappresentare

schematicamente quali sono i package della soluzione e

infine il diagramma che fa vedere la struttura, quindi il

composite structure.

Diagramma delle classi

· Descrive i tipi di oggetti (concetti o entità) di un sistema e

· le varie relazioni statiche che li collegano

Mostra le caratteristiche (proprietà e operazioni) dei vari

· oggetti e i vincoli che devono essere soddisfatti nel

collegarli fra loro

Può essere definito in fasi diverse (analisi, dettaglio) ed

· avere varie finalità (interfaccia, implementazione, dati,

etc...).

Diviso in 3 aree:

· Nome della classe

· Area degli attributi

· Area dei metodi

·

Visibilità:

· Public:+

· Package: ondina

· Protected: #

· Private: -

·

Molteplicità:

· 1: uno e uno solo

· 0…1: 0 o 1 istanza

· 1…*: almeno 1 ma anche di più

· *: da 0 a tanti

·

Relazioni tra classi

· · Aggregazione:

· modellizza il costrutto part-of

E’ una relazione non forte, cioè La classe parte ha

senso anche senza la classe tutto

Composizione

· è una relazione forte, cioè le classi parte hanno un

reale significato solo se legare alla classe tutto

Dipendenza

· E’ la forma di relazione tra classi più debole, cioè la

classe A dipende da un’altra classe B perché la

utilizza in qualche punto

Di solito la classe B è parametro formale di un

metodo di A oppure una variabile locale di un metodo

di A

E' diversa dall'associazione perchè nell'associazione

la classe B diventerebbe un attributo della classe A,

quindi A è associata a B perché la contiene come

attributo mentre nella dipendenza significa che lo

usa nel suo behaviour ma non deve esserne

necessariamente composta

Generalizzazione

· rappresentazione semantica di una relazione del tipo

is-a

Distingue sottoclasse e sottotipo

Dà origine a ereditarietà, overriding

GIT L'obiettivo è tenere traccia dello sviluppo software, infatti ci

· possono essere più persone che collaborano per un progetto, è

anche responsabilità di tutto il team di fare una sorta di code

review di quello che viene scritto dagli altri, per avere accesso

contemporaneo a questi sorgenti e allo stesso risolvere i conflitti

nel caso di modifiche contemporanee da diversi sviluppatori

Version Control System (VCS) è un sistema software che gestisce

· i cambiamenti nei progetti

Gestisco:

· Xocumenti

· Programmi

· Sitiweb

·

A volte i VCS sono integrati in altri software

· Originariamente i VCS erano locali, l'idea era quella di avere un

· database detto repository che ha lo scopo di tenere traccia di

tutte le evoluzioni dello sviluppo di un software. Erano già inclusi

all'epoca i comandi check in e check out che sono i comandi per

entrare nel database e allineare il proprio sistema con quanto c'è

nel database

Da una configurazione locale si passa a una versione

· centralizzata in cui c'è un server remoto o di azienda e tanti

computer locali che fanno il checkout del contenuto del server e

poi fanno update e commit, l'update è l'idea di aggioranre

informazioni sul repository locale mentre commit è il file storage,

quindi la conferma delle modifiche, il commit è il momento in cui

si vanno a guardare eventuali conflitti tra la versione localee la

versione del DB

Modifiche parallele al progetto richiedono dei meccanismi di

· risoluzione dei conflitti

Il problema principale sorge quando un utente vuole modificare

un file che è già in corso di modifica da parte di un altro utente.

Due possibili soluzioni:

Meccanismo di lock per bloccare i file in corso di modifica

· Merge delle modifiche: entrambi lavorano sulle due

· versioni e poi si fa una fusione che prevede la risoluzione

dei conflitti manuale, si va a scegliere quindi insieme quale

codice mantenere

quando delle modifiche che stiamo apportando impattano

· fortemente sul progetto, invece che lavorare tutti sullo

stesso ramo, cioè sulla stessa versione del software, si

possono staccare dei branch che sono come altri percorsi

di evoluzione del software, quindi piuttosto che avere un

unico software che evolve verticalmente, può esserci un

altro ramo che evolve in maniera indipendente.

Sistemi distribuiti:

· Questo meccanismo è un ibrido, quindi anche se è presente un

server che fa da collettore, git prevede delle copie locali, quindi

lo sviluppo che facciamo è comunque uno sviluppo locale, non è

totalmente centralizzato ma è ibrido perchè da una parte

abbiamo lo sviluppo sulla nostra macchina e, quando vogliamo,

possiamo allineare la copia locale con una copia remota, è

questo il momeno in cui si abilita la cooperation. Localmente

abbiamo la stessa struttura che c'è sul server. Avere una copia

locale permette di fare dei tentativi.

Vantaggi dei sistemi distribuiti tra copie locali e server centrale:

Separazione tra archiviazione e condivizione

· Possibilità di meccanismi di collaborazione complessi (ad

· esempio repository organizzati gerarchicamente)

Affidabilità garantita dalla presenza di copie multiple

· resilienza: se fosse tutto su un unico server e questoo

server dovesse avere problemi, andrebbe tutto perso,

l'idea di avere copie multiple permette di avere ridondanza

e il prodotto è resiliente

Git:

· Creato nel 2005 per supportare lo sviluppo del kernerl linux

· Design semplice

· Efficiente

· Completamente distribuito

· Capace di gestire progetti di grandi dimensioni, È stato

· pensato perché doveva supportare lo sviluppo di sistema

operativo

Supporto per sviluppo non lineare (molti branch paralleli)

· Efficiente: non ha latenze dovute a vari gestori di gentione

· quando si parla di repository git si parla di questa versione

· del database che è unico a in realtà ce ene sono tante

copie che poi in qualche modo devono tenersi

sincronizzate.

Ogni volta che qualcuno fa un commit produce una nuova

copia del software

Se qualcuno fa una modifica del file e poi fa il commit non

sovrascrive il progetto ma ne aggiunge una copia per poi

eventualmente tornare a ripristinare la versione

precedente

la maggior parte delle operazioni avviene localmente

· Quando facciamo il checkout per la prima volta stiamo

· creando la cartella con cui lavoreremo, la nostra working

directory di eclipse ad esempio, con il checkout lo

associamo al repository precedentemente creato, ora il

nostro sistema di versioning sa che quello è lo spazio di

lavoro e i file interni sono i candidati per poter diventare gli

elementi su cui si focalizzerà il versioning, fin quando non

indichiamo che vogliamo che i file facciano parte della

repository, questi sono presenti nella working directory, ci

verrà indicato che ci sono questi file ma non verranno

conteggiati nel versioning, quindi dobbiamo fare una prima

fase in un sottomettiamo i file all'area di stage, ora il

sistema guarda qui e guarda nel repository, deve esistere

già qualcosa, se non esiste niente allora sono file da

aggiungere , se esiste qualcosa che ha certe caratteristiche

ad esempio il nome del file uguale, ci segnalerà ipotetici

conflitti, dicendo che c'è già un file, quindi ci propone

alcune soluzioni come sovrascrivere o tenere il nuovo file.

Dopo aver risolto queste strategia possiamo fare il commit

che prende i file dalla stging area e li mette nel repository

Si parte quindi da un repository, copiamo i dati, oppure se

· questo è vuoto, partiamo dal repository creato, lo

associamo alla working directory e questa è la prima fase o

fase di checout, poi lavoriamo localmente nel workspace,

tutte le modifiche fatte sono nel nostro workspace, non nel

repository, ogni ora ad esempio si procede con

sincronizzazione con il repository locale, facciamo

l'aggiunta dei file modificati alla staging area che è gestita

autonomamente da git, quindi quando noi indichiamo quali

file della working directory sono oggetto del versioning,

cioè solo la prima volta, dopo ciò questa staging area viene

sempre gestita da git, è lui che confronta la working

directory e il repository, vedendo ad esempio che

localmente abbiamo alcune versioni nuove di file che nel

server sono ancora vecchie, quindi avvisa quelle che

saranno le potenziali azioni, è come se fosse un'antepria di

quello che succederebbe se dovessimo fare il commit,

questo è importante perchè magari ho fatto una modifica

del file che non voglio salvare, magari era solo una prova,

quindi il fatto di avere quest'area di stage mi tutela dal fare

sovrascritture impattanti. Quindi l'area di stage cerca di

minimizzare gli errori. Una volta verificato ciò che è

riportato nell'area di stage si procede con il commit, questo

va a salvare su un repository locale le modifiche fatte

Tramite il push e il pull possiamo interagire con un'altra

· entità che è l'entità remota, è uguale alla nostra

architettura, non cambia nulla, solo che questo funge da

server, cioè ci sono altri utenti ciasucno con la sua

directory locale, il suo git e il repository, anche loro

possono fare push e pull sul server, questo fa da collettore

centralizzato

Git pull: aggiorna la repository locale

Git push: pubblica in remoto ciò che è stato modificato

nella repository locale

L’intergazione con git può avvenire tramite riga di