Tecnologie e progettazione - 4AI A4. Gestione e documentazione del codice (pag 78 e succ.)

Presentazione sul tema: "Tecnologie e progettazione - 4AI A4. Gestione e documentazione del codice (pag 78 e succ.)"— Transcript della presentazione:

1 Tecnologie e progettazione - 4AI A4. Gestione e documentazione del codice (pag 78 e succ.)

2 Regole e convenzioni di codifica (pag 80-83) Tutti i progettisti di software adottano convenzioni di stile o linee guida per la scrittura del codice sorgente dei programmi. Lo scopo è quello di massimizzare la leggibilità e la comprensibilità del codice sorgente sia per gli sviluppatori stessi che per gli altri. Inoltre in questo modo è più facile prevenire errori comuni. Le convenzioni di codifica non vanno confuse con le regole di sintassi del linguaggio usato.  Le regole di sintassi vengono controllate dal compilatore e non possono essere violate altrimenti non verrà nemmeno generato il codice eseguibile.  Le convenzioni di codifica invece sono stabilite e controllate dai programmatori. Il loro mancato rispetto di per sè non compromette la funzionalità o l'efficienza del codice generato, ma rende più difficile la lettura del codice da parte degli umani. Sarà quindi più difficile la manutenzione, la ricerca di errori, l'aggiornamento del codice, ecc.

3 Esempi float pippo; int pluto pippo = 0,3 ; In queste righe di codice c++ sono violate due regole di sintassi int dividendo; int Divisore, RESTO, xzy; … if (RESTO == 0) cout (“divisione senza resto”); In queste righe non ci sono errori di sintassi ma sono violate diverse convenzioni di codifica comuni: 1)i nomi delle variabili dovrebbero essere tutti minuscoli 2)le variabili dovrebbero avere nomi significativi (non xzy) 3)non è rispettato l'allineamento corretto (sia sulle prime due che sulle ultime due righe) 4)le variabili dovrebbero essere dichiarate una per riga

4 Esempi di convenzioni comuni di codifica per C++ (ved. pag. 81) Regole di denominazione generali Convenzioni per nomi di file, tipi, varabili, costanti, funzioni Indentazione del codice Evitare uso di istruzioni goto ecc.

5 Le convenzioni di codifica aiutano anche a prevenire errori comuni Esempi: if (x=0) y = 0; else y = x+1; La prima riga del codice contiene un errore comune. Il confronto corretto è: x == 0. Ma il compilatore C++ accetta l'istruzione che interpreta come una assegnazione (assegna 0 ad x) Per evitare qiuesto tipo di errore alcuni adottano la convenzione di scrivetre l'istruzione di confronto tra una variabile e una costante nel modo seguente: if (0 == x) Così, se per errore si scrive 0=x invece di 0==x, si ha un vero e proprio errore sintattico, che sarà quindi segnalato dal compilatore. Un altro esempio: scrivendo i nomi delle variabili sempre in minuscolo e senza abbreviazioni si riduce il verificarsi di errori dovuti al fatto che in alcuni punti la variabile abbia un nome diverso rispetto a quello stabilito nella dichiarazione. int eta_media;.... Eta_media = totale/numero; Errore: unknown identifier

6 Documentazione del codice sorgente con Doxygen (pag.87 e seg.) Per facilitare la manutenzione del codice, oltre al rispetto delle convenzioni di codifica del sorgente, è importante avere una buona documentazione tecnica del codice. Attenzione: la documentazione tecnica serve agli sviluppatori, non agli utenti finali del software. Non ha dunque niente a che vedere con l'eventuale Manuale d'uso, che è destinato invece agli utenti. Una delle difficoltà principali della documentazione è data dalla necessità di mantenere l'allineamento con il codice prodotto. In altre parole quando si fanno delle modifiche al codice bisognerebbe anche ricordarsi di aggiornare la corrispondente documentazione.

7 Ambienti di sviluppo integrati (pag. 83-84) (IDE = Integrated Development Environment) Anche se è possibile scrivere un programma utilizzando un comune editor di testo è sempre preferibile usare un IDE. Ciò facilita e rende più rapido lo sviluppo di codice. Un IDE di base comprende sempre: Un editor avanzato (evidenziazione mediante colori diversi delle parole chiave, identificatori, costanti, ecc.; suggerimenti per il completamento delle righe, ecc.) Un compilatore integrato con l’editor (per i linguaggi compilati è compreso anche il linker) Un debugger, che consente l’esecuzione controllata del codice. E’ infatti possibile inserire nel codice dei break-point. Quando si esegue il debug l’esecuzione si interrompe in corrispondenza del break-point, prima di eseguire l'istruzione. E' possibile a questo punto ispezionare il valore delle variabili.

8 Altri componenti che possono essere presenti in un IDE (per una breve descrizione della funzione svolta da ciascuno di questi strumenti vedere pag. 84) Un performance profiler Un analizzatore di code-coverage Un editor visuale Un editor UML Un sistema di controllo versioni (VCS) Alcuni di questi tool sono comunque disponibili anche come software gratuiti open source. Ad esempio abbiamo visto in laboratorio il software ArgoUML come editor UML e il Tortoise-SVN (Subversion) per il controllo versioni.

9 Diritto d'autore e licenze software (pag 84-87) Nella UE l'unico strumento giuridico di protezione del software è il copyright, cioè il diritto d'autore. Non è prevista la brevettabilità del software. Se chi realizza un software lo fa per conto di un'azienda il copyright di norma è dell'azienda, non dell'autore materiale del programma. Uno sviluppatore di software può avere due esigenze: definire le modalità con cui il software realizzato può essere usato dagli utenti / acquirenti conoscere le modalità con cui può utilizzare nel proprio programma parti di codice sviluppati da altri programmatori Il produttore di un software può concedere agli utenti / acquirenti l'uso del solo codice eseguibile oppure anche il codice sorgente. In quest'ultimo caso chi acquisisce il prodotto lo potrà modificare o usare per sviluppare altri prodotti.

10 Se si concede il solo codice eseguibile (gratuitamente o dietro compenso) si definisce un contratto d'uso, chiamato EULA (End User Licence Agreement), che l'utente deve accettare se vuole utilizzare il programma. Il contratto d'uso EULA prevede sempre alcuni diritti (es.: possibilità di eseguire il programma su almeno un computer, diritto di fare una copia di backup) ma anche alcune limitazioni (divieto di rivendere il software, di disassemblarlo, modificarlo, ecc.) La concessione del solo codice eseguibile è la modalità tradizionale e più diffusa di distribuzione dei programmi commerciali a pagamento. L'azienda o il programmatore non rende disponibile in questi casi il sorgente del proprio prodotto. Anche molti programmi freeware o shareware sono rilasciati solo come eseguibili. In alternativa esistono i cosiddetti programmi open source. In questi casi viene reso disponibile il codice sorgente del programma. Qualsiasi programmatore esperto potrà esaminare il codice o modificarlo a proprio piacere, ma se vorrà distribuire il prodotto ottenuto, dovrà rispettare alcune regole, stabilite dalla licenza open source.

11 Quando si fornisce il codice sorgente di un programma si parla di Open Source. Lo scopo è quello di favorire il riutilizzo del codice vincolandolo però al rispetto di alcune regole stabilite da un'apposita licenza d'uso. In generale una licenza open source cosa prevede? regole rigide sulla distribuzione di codice derivato: SI disponibilità del codice sorgente: SI divieto di produrre/vendere codice derivato: NO (purchè si rispettino i termini della licenza) possibilità di usare il codice in modo totalmente libero: NO obbligo di gratuità del programma: NO

12 I principali tipi di licenze open source sono due: GPL: General Public Licence (è la licenza open source più nota, tipica di Linux e di molti altri prodotti oggi molto diffusi) BSD: Berkeley Software Distribution (licenza utilizzata per la versione di UNIX creata all'università di Berkeley) Nessuna licenza open source impone che il software rilasciato debba essere gratuito, anche se di fatto molti prodotti con licenza open-source sono distribuiti gratuitamente.

13 Caratteristiche principali della licenza GPL: 1.possibilità di modificare il codice sorgente originale creando codice derivato (è possibile anche rivendere il nuovo prodotto, purché rispettando i vincoli successivi 2 e 3) 2.obbligo di rilascio del codice sorgente per ogni prodotto derivato 3.obbligo di rilasciare il codice derivato con la stessa licenza GPL In pratica è garantita a tutti la possibilità di utilizzare il codice sorgente originale, imponendo solo che eventuali modifiche debbano essere liberamente disponibili per tutti. Poiché questo è il contrario del tradizionale copyright, viene anche chiamato scherzosamente copyleft.

14 Caratteristiche principali della licenza BSD: 1.possibilità di modificare il codice sorgente originale creando codice derivato (come per la GPL) 2.obbligo di citare il copyright originale 3.obbligo di mantenere le clausole di non-garanzia originali Nota: BSD è una licenza più liberale della GPL, in quanto non si ha né l'obbligo di rilasciare il sorgente né di usare per il prodotto derivato la stessa licenza originale.

15 Per facilitare e velocizzare la produzione di documentazione standardizzata è conveniente utilizzare uno strumento automatico. Uno di questi è il Doxygen.  Doxygen è un software open-source, gratuito, disponibile con licenza GPL.  Doxygen permette di produrre la documentazione di applicazioni scritte in C++. Nota: per il software prodotto in linguaggio Java esiste un apposito tool che fa parte dell'ambiente di sviluppo: il javadoc. Doxygen, come gli altri tool di documentazione automatica, si basa sull'utilizzo di particolari tag che il programmatore deve inserire all'interno dei commenti al codice. Interpretando questi tag, il Doxygen genererà tutta la documentazione. Per i commenti Doxygen, bisogna inserire sempre come primo carattere un "!". Esempi: //! calcola la media dei voti /*! restituisce la differenza tra due date */

16 Alcuni dei tag utilizzati dal Doxygen sono i seguenti: TAGSCOPO \file definisce il nome del file sorgente \author specifica l'autore del codice \date specifica la data di creazione del codice \version specifica la vesrione \class definisce il nome di una classe \fn definisce il nome di una funzione o di un metodo di una classe \var definisce il nome di una variabile \brief fornisce una breve descrizione di una classe, funzione, variabile, ecc. \param fornisce il nome e la descrizione di un parametro di una funzione \retval fornisce il nome e il valore di ritorno di una funzione \return specifica il valore restituito da una funzione o metodo

17 /*! \file treno.ccp \author cicci0 \version 1.0 \date 20/08/08 */ /*! \class Vagone \brief la classe implementa un vagone */ class Vagone { protected: //! \var codice //! \brief codice univoco del vagone int codice; char costruttore[32];//!< nome dell'azienda che costruisce il vagone float peso_vuoto; //!< peso senza carico int anno;..... Esempi di commenti Doxygen /*! \fn calcolDistanza \brief calcola la distanza tra due punti \param p1 primo punto \param p2 secondo punto \return distanza tra il primo e il secondo punto */ double calcolaDistanza(Punto p1, Punto p2){..... return d; }

18 Gestione di versioni del codice sorgente: il software Subversion (pag. 93 e seg.) Per facilitare il controllo nello sviluppo di versioni successive di un programma è possibile utilizzare degli strumenti chiamati VCS (Version Control System). Uno di questi è Subversion (open source, gratuito, GPL). Ci sono diversi motivi per utilizzare uno strumento VCS: numerare automaticamente le versioni tenere traccia automaticamente delle versioni man mano sviluppate poter tornare a una versione precedente in caso di problemi gestire e controllare lo sviluppo di software su cui lavorano diversi programmatori in contemporanea: in questo caso potrebbero verificarsi problemi (es: le modifiche di uno vengono sovrascritte dalle modifiche di un altro) Le versioni successive di un software vengono da molte aziende indicate di con un Major number e un Minor number (es.: 3.5, 3.6, 4.0, ecc.). Il major number viene cambiato a seguito di importanti modifiche funzionali del codice. Il minor number viene cambiato in caso di manutenzione correttiva o semplici evoluzioni di funzionalità già presenti.

19 I VCS (es.: Subversion) usano un Repository (ad es. una speciale cartella condivisa in rete). Nel repository vengono conservate le diverse versioni del di codice sorgente di un programma. Gli sviluppatori lavorano estraendo dal repository i file da modificare (operazione di read o check-out) La copia del file sorgente su cui lavora il programmatore si chiama working copy Una volta terminata la modifica, la working copy viene trasferita nuovamente nel repository (operazione di write o commit) Come funziona un Version Control System? Nota: la versione con interfaccia visuale di Subversion si chiama tortoise-SVN.

20 In caso di modifiche apportate da due o più sviluppatori possono sorgere problemi (vedere fig. 8 pag. 96) Per evitare il problema i VCS possono utilizzare due tecniche: a)lock-modify-unlock b)copy-modify-merge Subversion usa di default la b) ma si può impostare anche la a).

21 LOCK-MODIFY-UNLOCK Quando il primo sviluppatore fa il check out, blocca il file sorgente. Il secondo sviluppatore non potrà prelevare il file finchè il primo non termina, rilasciando il blocco. Quando il primo programmatore termina le modifiche e fa il commit, l’altro programmatore può prelevare il file. La tecnica è sicura, ma poco efficiente, in quanto se uno sviluppatore preleva dal repository numerosi file da modificare, blocca tutti gli altri sviluppatori che potrebbero avere necessità di apportare modifiche.

22 COPY-MODIFY-MERGE Non si mette un blocco sui file prelevati. Se uno stesso file viene modificato da due programmatori viene generato un errore di conflitto in fase di commit. I programmatori esaminano le modifiche apportate da ciascuno e concordano la versione da registrare nel repository. Il ciclo di lavoro del programmatore è il seguente:  prelevare i file su cui lavorare (check out)  prima di operare su un file aggiornare la propria working-copy con quella del repository, nel caso sia stata nel frattempo modificata  lavorare con la propria working copy, apportando le modifiche necessarie  fare il commit controllando che non ci siano state modifiche da altri; in tal caso concordare il merge delle modifiche.

23 ESERCIZI su cap. A4 Rispondere ai quesiti da 1 a 11 di pag. 122.

24 Tecnologie e progettazione A5. Test del software (cenni) (pag. 126 e seg.)

25 Il test del software è una investigazione che ha lo scopo di ricercare eventuali malfunzionamenti (bug) del programma eseguibile e verificare la conformità del software ai requisiti stabiliti. Il testing è un’attività distinta dal debug. Il debug consiste nell’individuare e risolvere nel codice sorgente gli errori che provocano malfunzionamenti. La fase di test nel ciclo di sviluppo è molto importante in quanto il costo di risoluzione di un errore aumenta esponenzialmente con il tempo impiegato per la sua scoperta ed eliminazione. Ciò significa che individuare e correggere un errore può essere relativamente semplice e veloce se lo si fa subito dopo aver prodotto il software. Diventa invece molto più difficile e dispendioso se lo si fa dopo molto tempo. Come si eseguono i test? Vengono eseguiti una serie di casi di test (test case). Per ogni test case si specifica: Precondizioni per l’esecuzione Azioni da eseguire Risultati attesi e criteri per definire esito positivo o negativo

26 I test possono essere: Black box (o a scatola chiusa) White box (o a scatola aperta) Inoltre si possono avere test unitari (controllo su un singolo modulo) oppure test di integrazione (verifica del programma completo, da effettuare dopo aver verificato i singoli moduli).  I test black box sono scritti solo sulla base dei requisiti funzionali del modulo da testare. La struttura interna del modulo viene ignorata.  I test white box sono scritti in modo da provare tutte le diverse righe di codice. I test devono quindi essere predisposti tenendo conto della struttura interna del modulo. Per i test white box bisogna predisporre almeno un input per ogni possibile percorso di esecuzione. Ad esempio in corrispondenza di ogni if bisogna provare sia il ramo then che il ramo else. Un piano di test prevede l’esecuzione di uno o più casi di test. Se tutti i casi hanno esito positivo, il test si considera superato. Se fallisce anche un solo caso, il test non è superato. Bisognerà ricercare la causa dell’errore, correggerla e ripetere tutti i test case.