Tutorial Build Riepilogo dei principali argomenti presenti nel

Tutorial Build Riepilogo dei principali argomenti presenti nel modulo Build di EUCIP Core 1

B 3 programming 2

Object oriented Classi Metodi Attributi Inheritance Overriding (polimorfismo) Overloading (polimorfismo) Information hiding Abstraction 3

Java è un linguaggio IBRIDO Il programma Java, deve essere prima compilato (Otterremo così non un file eseguibile (ovvero la traduzione in linguaggio macchina del file sorgente che abbiamo scritto in Java), ma un file che contiene la traduzione del nostro listato in un linguaggio molto vicino al linguaggio macchina, detto "bytecode". Una volta ottenuto questo file dobbiamo interpretarlo. A questo punto la JVM interpreterà il bytecode ed il nostro programma andrà finalmente in esecuzione. Quindi, se una piattaforma qualsiasi possiede una Java Virtual Machine, ciò sarà sufficiente per renderla potenziale esecutrice di bytecode Ecco quindi svelato il segreto dell’indipendenza della piattaforma: se una macchina possiede una JVM, può eseguire codice Java. 4

Proprietà delle Classi e degli Oggetti in Java Definendo le caratteristiche e le operazioni di una classe si definiscono implicitamente comportamenti e operazioni degli oggetti che appartengono alla classe. n Quindi una classe Java è composta da un insieme di oggetti ed un insieme di metodi associati. n Una classe può essere composta da più sottoclassi n n Ad esempio, la classe dei triangoli è composta dalle sottoclassi dei triangoli equilateri, dei triangoli isosceli e dei triangoli scaleni. La classe dei negozi è composta dalle sottoclassi dei negozi alimentari, di abbigliamento, di elettrodomestici, di automobili ecc. 5

Proprietà delle Classi e degli Oggetti in Java Un oggetto è una istanza di una classe. Per effettuare operazioni su una classe è necessario creare un oggetto che è costituito da un insieme di ampio variabili d’istanza, a cui corrispondono locazioni di memoria, corrispondenti a quelli dichiarati nella classe. n Un metodo realizza un insieme di operazioni sugli oggetti di una classe. n Gli oggetti di una classe possono essere manipolati solo tramite i metodi della classe stessa. I metodi possono essere definiti con i modificatori public per indicare che sono visibili anche a metodi non dichiarati nella classe o private per indicare che sono visibili solo all’interno della classe o protected per indicare che sono visibili alla classe stessa e alle sue sottoclassi 6

Proprietà delle Classi e degli Oggetti in Java Analizziamo brevemente le quattro proprietà principali dei linguaggi objectoriented: n -Incapsulamento (incapsulation) n n n Il fatto di far operare sugli attributi di una classe solo tramite i suoi metodi pubblici genera l’information hiding -Ereditarietà (Inheritance) -Polimorfismo (Overloading e overriding) 7

Proprietà delle Classi e degli Oggetti in Java Incapsulamento: n n La proprietà di rendere invisibili i dati e di gestirli solo tramite metodi. In questo modo diversi programmi possono avere diverse visibilità dei dati e si costruiscono delle astrazioni funzionali. Questo accade nella vita reale quando usiamo oggetti e macchine senza conoscere il loro contenuto ed il loro funzionamento interno. Ha il grosso vantaggio di rendere una classe RIUSABILE: la posso usare in contesti diversi senza sapere come è realizzata dentro 8

Proprietà delle Classi e degli Oggetti in Java Ereditarietà: n n Le proprietà di una classe possono essere ereditate in tutto o in parte dalle sue sottoclassi che possono avere anche altre specifiche proprietà. La classe genitrice è detta superclasse, mentre la sottoclasse è detta classe derivata. Questo viene realizzato tramite la parola chiave extends. Un oggetto della sottoclasse incapsula tutti i dati della classe genitrice più i suoi dati e può usare tutti i metodi della superclasse risparmiando nella scrittura del codice. I metodi e i dati della superclasse non c’è bisogno di riscriverli. 9

Proprietà delle Classi e degli Oggetti in Java Polimorfismo (usa il concetto di overloading e overriding): n n Selezione di un metodo tra diversi metodi che hanno lo stesso nome in base al tipo ed al numero dei parametri. All’interno di una stessa classe o di una classe da essa derivata si possono avere più metodi con lo stesso nome ma con parametri diversi per tipo e/o per numero. Ad esempio, possiamo metodi diversi che effettuano operazioni matematiche su dati di tipo differente. L’insieme del nome e dei parametri di un metodo sono detti firma del metodo 10

Proprietà delle Classi e degli Oggetti in Java Overriding: n La possibilitàdi ri-definire (sovrascrivere) in una classe derivata i metodi della classe genitrice. n n n In questo caso, quando viene invocato un metodo si usa quello che è definito all’interno della sottoclasse. Se invece si vuole usare in una classe derivata un metodo della classe genitrice che ha lo stesso nome del metodo della classe derivata si può fare tramite la parola chiave super Nel caso dell’overriding i metodi hanno stessa firma. Ma stanno in due classi diverse! 11

Test Polymorphism in object oriented is: 1. 2. 3. 4. Is an inherent characteristic of good design Allows us to define differents methods with the same names, but the different behaviours Is not related to the inheritance Is not depending to the parameters 12

Test Polymorphism in object oriented is: 1. 2. 3. 4. Is an inherent characteristic of good design Allows us to define differents methods with the same names, but the different behaviours Is not related to the inheritance Is not depending to the parameters 13

Test In Object Oriented programming, which of the following best characterises the concept of information hiding? 1. Information hiding is needed to keep software project development confidential. 2. Information hiding is used to ensure privacy and security of data. 3. Information hiding is a technique to forbid the access of server's internal data to client modules. 4. Information hiding is a method to prevent access of data from the Internet. 14

Test In Object Oriented programming, which of the following best characterises the concept of information hiding? 1. Information hiding is needed to keep software project development confidential. 2. Information hiding is used to ensure privacy and security of data. 3. Information hiding is a technique to forbid the access of server's internal data to client modules. 4. Information hiding is a method to prevent access of data from the Internet. 15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

Test Spesso quando si pensa alla tecnologia ad oggetti, si fa riferimento all’information hiding. Cosa si intende per questo concetto? A. B. C. D. Lo stato degli oggetti non è accessible direttamente, ma solo attraverso metodi opportuni; Il progettista deve definire vincoli appropriati sulla visibilità delle proprietà (attributi e metodi) di ogni classe; Gli utenti delle classi devono usarle “al buio”, senza sapere come sono fatte; L’utente ha una visione ristretta delle funzionalità di ogni classe Quali affermazioni sono corrette? : 1. A, B; 2. A, B, C, D; 3. C, D; 4. A, B, D; 30

Test Spesso quando si pensa alla tecnologia ad oggetti, si fa riferimento all’information hiding. Cosa si intende per questo concetto? A. B. C. D. Lo stato degli oggetti non è accessible direttamente, ma solo attraverso metodi opportuni; Il progettista deve definire vincoli appropriati sulla visibilità delle proprietà (attributi e metodi) di ogni classe; Gli utenti delle classi devono usarle “al buio”, senza sapere come sono fatte; L’utente ha una visione ristretta delle funzionalità di ogni classe Quali affermazioni sono corrette? : 1. A, B; 2. A, B, C, D; 3. C, D; 4. A, B, D; 31

test Passando dall’esecuzione di un programma C compilato all’esecuzione di un programma Java interpretato, qual è la differenza principale dal punto di vista dell’utente? 1. 2. 3. 4. I due casi richiedono un interprete opportuno Per eseguire un programma compilato non è necessario sapere in che linguaggio è scritto, mentre per eseguirne uno interpretato bisogna conoscere il linguaggio di programmazione Non vi è alcuna differenza È solo un problema di efficienza 32

test Passando dall’esecuzione di un programma C compilato all’esecuzione di un programma Java interpretato, qual è la differenza principale dal punto di vista dell’utente? 1. 2. 3. 4. I due casi richiedono un interprete opportuno Per eseguire un programma compilato non è necessario sapere in che linguaggio è scritto, mentre per eseguirne uno interpretato bisogna conoscere il linguaggio di programmazione Non vi è alcuna differenza È solo un problema di efficienza 33

34

35

36

37

test L’ambiente di sviluppo di Eclipse quali caratteristiche soddisfa? a) Free b) Open source c) Multipiattaforma d) Usa i plug-in i. iii. iv. A e B A, B, C Tutte B e C 38

test L’ambiente di sviluppo di Eclipse quali caratteristiche soddisfa? a) Free b) Open source c) Multipiattaforma d) Usa i plug-in i. iii. iv. A e B A, B, C Tutte B e C 39

Tecniche per verificare la correttezza del sw Test (sono volti a rilevare la presenza di errori) Debugging (localizzare le anomalie) I test non verificano l’assenza di errori, ma ne individuano la presenza. Il superamento di una serie di test non implica che il codice è esente da errori, ma semplicemente che il programma è corretto rispetto ad una serie di test Adriana Fasulo 40

Tecniche per verificare la correttezza del sw in modo dinamico Ci sono tre situazioni differenti in cui applicare l’analisi dinamica per rilevare errori: q q q Unit test Test di integrazione e test di sistema Test di accettazione Adriana Fasulo 41

Unit test E’ relativo al test del singolo modulo, di complessità limitata che fa parte di un programma più complesso Tecniche: Approccio white-box (conoscenza del codice da testare) Approccio black-box (non conoscenza del codice da testare) Adriana Fasulo 42

Test di integrazione e di sistema Quando i moduli sono integrati insieme è necessario testare il funzionamento complessivo del sistema. Es. nel caso di un’applicazione che ha un’interfaccia grafica in cui l’utente deve fornire i dati, si crea un software molto più semplice senza componenti grafici (ad esempio console) che permette di simulare l’inserimento dei vari dati dell’utente Adriana Fasulo 43

Test di integrazione e di sistema Dopo avere eseguito il test dei singoli moduli, si può operare per il test dell’integrazione nei seguenti due modi: Non incrementale (big bang test) che prevede l’integrazione complessiva di tutti i moduli testati singolarmente Incrementale (incremental test) che prevede i test dopo aver aggiunto un modulo per volta Altro test importante può essere lo stress test per vedere come si comporta il sistema in situazioni di carico estremo Adriana Fasulo 44

Test di accettazione Il cliente deve “accettare” il sw che il produttore ha creato. Bisogna quindi effettuare il test di accettazione che è eseguito dall’utente finale. Non ci sono tecniche formali Se il prodotto deve essere distribuito sul mercato, il test di accettazione è suddiviso in : α test: il prodotto è rilasciato all’interno dell’organizzazione e testato ß test il prodotto è distribuito ad un numero ristretto di utenti scelti come utenti campione Adriana Fasulo 45

No regression test Test di non regressione (no regression test) Sono fondamentali quando si fanno modifiche al codice per aggiungere funzionalità oppure quando si fanno modifiche per risolvere faults. La risoluzione di faults può generare altri errori, quindi è necessario effettuare dei test Se erano stati predisposti dei collaudi automatizzati, il collaudo di regressione ha normalmente un basso costo, in quanto si tratta solo di lanciare le procedure di collaudo esistenti, eventualmente ritoccate. n Es. Junit, dot. Unit, NUnit Un completo collaudo di regressione manuale sarebbe invece enormemente costoso, e per tale motivo normalmente il collaudo di regressione manuale è più sbrigativo del collaudo originale Adriana Fasulo 46

No regression test La logica che sta alla base di questi strumenti di esecuzione automatica di test è sempre la stessa: Per utilizzarli è necessario realizzare un progetto di definizione dei test in una fase parallela o addirittura precedente allo sviluppo Se è più onerosa la fase iniziale, è più semplice la fase di esecuzione dei test che si possono rieseguire più volte in modo automatico (vedere articolo su Junit) Adriana Fasulo 47

48

49

50

51

documentazione Nel corso del ciclo di vita di un sistema sw le esigenze di documentazione a cui essa va incontro sono molto varie. Durante la fase di definizione dei requisiti e di progettazione, la comunicazione è all’interno del gruppo di progetto. Quando si passa alla fase realizzativa la documentazione assume una connotazione più tecnica e deve essere descritta con un formalismo rigoroso Adriana Fasulo 52

documentazione Nella fase finale viene prodotto il manuale utente. Se il linguaggio è informale, quello che si descrive è soggetto ad ambiguità. La specifica formale è realizzata mediante un formalismo rigoroso, che offre: Vantaggi: non è soggetta ad ambiguità e può essere anche eseguibile (es. compilatore rispetto al codice sorgente) Svantaggi: può essere un vincolo troppo forte che ti obbliga a trattare aspetti che magari potrebbero essere ignorati Adriana Fasulo 53

documentazione Esistono formalismi con un rigore intermedio chiamati semiformali, caratterizzati da strutture che accanto a notazioni grafiche permettono descrizioni informali in linguaggio naturale: Modello E/R Data flow diagram Pseudocodifica (structured english) Flow chart Adriana Fasulo 54

UML In ingegneria del software, UML (Unified Modeling Language, "linguaggio di modellazione unificato") è un linguaggio di modellazione e specifica basato sul paradigma object-oriented Il linguaggio nacque con l'intento di unificare approcci precedenti , raccogliendo le best practices nel settore e definendo così uno standard industriale unificato. UML può quindi essere utilizzato nel contesto di diversi approcci metodologici. Ogni sistema complesso può essere descritto grazie ad un insieme di viste logiche. UML prevede la definizione dei diversi diagrammi: Adriana Fasulo 55

Software ben strutturato e ben documentato Un sw è un prodotto che varia nel tempo e che può essere modificato da team di lavoro completamente diversi da quelli che lo hanno sviluppato all’inizio Perchè può essere molto importante commentare il codice e mantenere sempre aggiornata la documentazione? Adriana Fasulo 56

57

58

Maintenance “Changing of a software product executed, after the release, in order to correct the malfunctions, enhancing performance or adapt it to the changed using context” (Definition adopted by the IEEE) I sistemi sw tendono ad evolvere nel tempo, per cui è necessario stabilire un modello per un processo di manutenzione I requisiti del sw sono in continua evoluzione anche in base alle nuove richieste degli utenti, ai cambiamenti delle tecnologie Adriana Fasulo 59

Maintenance Cost Per ridurre i costi di manutenzione è fondamentale che l’applicazione sia facilmente riparabile ed evolvibile. Tali obiettivi si raggiungono attraverso la modularizzazione e la documentazione del codice. Perchè è importante documentare ogni cambiamento? Adriana Fasulo 60

Versioning Un sistema evolve costantemente nel tempo. L’effetto di tale evoluzione è destinato a trasformare il sw in modo irreversibile, in un sistema sempre più complesso E’ importante considerare anche di uno stesso sistema ci possono essere più versioni: Adriana Fasulo 61

Versioning Si supponga di aver creato un prodotto sw che viene venduto a diversi clienti. Ad alcuni di questi clienti il prodotto va bene così com’è. Per altri clienti sono necessarie delle modifiche legate all’uso particolare di questo sistema. Dello stesso prodotto devono essere mantenute versioni diverse Adriana Fasulo 62

Sistema per la gestione delle configurazioni Per poter gestire la presenza di più versioni contemporanee, ci sono dei sw di supporto chiamati sistemi di configuration management. Il prodotto più diffuso è CVS (Concurrent Versioning System) che è open source. Fornisce un meccanismo di repository centralizzato di tutte le risorse del progetto (codice sorgente, librerie, documenti, . . ) a cui gli sviluppatori, i progettisti, i manager possono accedere in modo concorrente Adriana Fasulo 63

64

65

documentation Design documentation vs User documentation 66

test Considering user documentation, the use of precise modeling notations like UML: 1. 2. 3. 4. Would help to obtain better documents Would improve the readabilty of produced documents Is a choise that is up to the editor of the documents Would be a wrong choise since users are not supposed to be proficient in UML, which is utilized to document software designs 67

test Considering user documentation, the use of precise modeling notations like UML: 1. 2. 3. 4. Would help to obtain better documents Would improve the readabilty of produced documents Is a choise that is up to the editor of the documents Would be a wrong choise since users are not supposed to be proficient in UML, which is utilized to document software designs 68

69

70