Laboratorio di Informaticaswap/labinf1617/Casi_di_Studio_Introduzione.pdf · Laboratorio di...

Laboratorio di InformaticaPresentazione Casi di Studio

Corso di Laurea in Informatica e Tecnologie per la Produzione del Sofware (Track B) - A.A. 2016/2017

docente: Cataldo Musto

[email protected]

mailto:[email protected]

Caso di StudioProgetto da sviluppare in totale autonomia a partire da una traccia contenente delle specifiche

• Specifiche = funzionalità che il sistema dovrà implementare, vincoli che dovrà rispettare

• Il caso di studio è da sviluppare individualmente o in coppia

• Leggére differenze nella modalità d’esame

• Possibilità di scegliere la traccia da un insieme di 3 scenari d’uso proposti

11/05/2017 2Cataldo Musto - Presentazione Casi di Studio

Laboratorio di Informatica (ITPS, Track B) – Università degli Studi di Bari – A.A. 2016/2017

Caso di Studio

Progetto da sviluppare in totale autonomia a partire da una

traccia contenente delle specifiche

• Specifiche = funzionalità che il sistema dovrà implementare, vincoli che dovrà rispettare

• Il caso di studio è da sviluppare individualmente o in coppia

• Leggére differenze nella modalità d’esame

• Possibilità di scegliere la traccia da un insieme di 3 scenari d’uso proposti



Caso di StudioProgetto da sviluppare in totale autonomia a partire da una traccia contenente delle specifiche

• Il caso di studio scelto vale per l’intero anno accademico

• Ogni traccia NON può essere scelta da più di 50 studenti (Sistema di prenotazione FCFS)

• Dopo aver scelto la traccia, la scelta NON può più essere modificata, a meno di motivata richiesta al docente



Caso di Studio – Linee Guida

Realizzare il caso di studio

Seguendo i quattro passi

Standard del Ciclo di Vita

del Software



Analisi

Progettazione

Codifica

Test


• Analisi• Studio di fattibilità

• Il problema si può risolvere?• Analisi Costi/Benefici

• Chiarifica del problema• COSA si ha a disposizione ?• COSA si deve ottenere ?

• Progettazione• Individuazione di una strategia di

soluzione• COME raggiungere l'obiettivo?

• Scelta delle strutture dati• Scelta degli algoritmi più adeguati

• Codifica• Scrittura del programma

• Verifica (e correzione)• (Test) del programma

• Rimanda ad una delle fasi precedenti

• Manutenzione• Correttiva

• Adattativa

• Migliorativa






1) Analisi• Chiarifica in linguaggio naturale del problema

• Chiarisce il problema (chi userà il sistema? Come lo userà? Per quanto tempo?) e il dominio applicativo in cui si lavora

• Definisce le funzionalità (requisiti funzionali)• Specifica le condizioni che devono verificarsi per poter eseguire le operazioni

• Specifica dati di input (valori accettati/non accettati) e dati di output (valori attesi)

• Definisce eventuali assunzioni ed ipotesi semplificative

• Definisce i vincoli (requisiti non funzionali)• Caratteristiche che il programma deve garantire (in merito ad esempio all’efficienza o alla

semplicità d’uso)

• Produce un documenti di Analisi dei Requisiti




2) Progettazione• Dal Problema alla Soluzione

• Progettazione Top-Down / Bottom-Up

• Utilizzo di formalismi standard (pseudo-linguaggio/flow-chart)

• Esame di Programmazione ☺

• Scelta delle Strutture Dati

• Definizione dei tipi di dato necessari a risolvere il problema (tipicamente delle struct) e dei relativi campi, valutazione Pro/Contro

• Progettazione Modulare

• Quali funzioni? Quali procedure? Quali parametri? Concetti: Astrazione Dati e Information Hiding

• Scelta degli Algoritmi

• Ordinamento, Ricerca, etc.

• Produce un documento di Progettazione


3) Codifica• Utilizzo Corretto del Linguaggio C

• Conoscenza e utilizzo delle librerie (es. <string.h>)• Utilizzo corretto di procedure e funzioni• Utilizzo adeguato di file e puntatori, quando necessario

• Programmazione «difensiva»• Corretta gestione degli errori• Corretta gestione dei casi «limite»

• Corretto Stile di Programmazione• Indentazione Adeguata• Identificatori significativi• Commenti opportuni

• Documentazione con Tool Standard (es. Doxygen)

• Produce il file eseguibile del progetto



Caso di Studio – Linee Guida4) Testing

• Metodo Empirico• Ispezione del codice per individuare errori

• Tracing (simula l’esecuzione passo dopo passo)

• Metodo delle stampe (stampare a video nei punti critici)

• Test a scatola nera dei valori di input e output• Casi tipici (con valori attesi)

• Casi limite (con valori particolari)

• Metodo Analitico• Correttezza semantica mediante asserzioni logiche (CUnit)

• Garantire la terminazione mediante analisi dei cicli

• Produce un piano di test (e la relativa esecuzione)



Caso di Studio – La SceltaUna volta selezionato lo scenario del caso di studio e formato (eventualmente il gruppo, procedere seguendo questo protocollo:

1. Inviare una mail all’indirizzo [email protected] con oggetto:• [LabInf1617] Scelta Caso di Studio

2. Nel corpo della mail indicare:• Nome, Cognome, Matricola, Anno di Corso (se diverso dal primo), scelta dello scenario

ed eventuale scelta dell’estensione

• In caso di consegna in gruppo, indicare le informazione per entrambi i membri del gruppo. Le consegne di gruppo prevedono obbligatoriamente almeno una estensione.



mailto:[email protected]

Caso di Studio – La Scelta



3. In risposta alla mail riceverete:

• Una conferma di avvenuta prenotazione, e un identificativo del gruppo da utilizzare per tutte le comunicazioni successive.

• Es) [LabInf1617-Gruppo12] Richiesta Informazioni

• OPPURE Una richiesta di modifica dello scenario d’uso o di integrazione delle informazioni.

• In caso di mancata risposta entro 48h, scrivere nuovamente.

Caso di Studio – Gli Scenari






Obiettivo: creare dei programmi che simulino una piccola parte delle funzionalità offerte da queste piattaforme.




• Progettare, realizzare e testare un programma che simuli la gestione della piattaforma NETFLIX

• Netflix è una piattaforma che permette agli utenti di vedere in streaming le proprie serie TV e i propri film. Gli utenti possono inserire le proprie preferenze rispetto a film e serie TV. Le preferenze vengono utilizzate per dare dei suggerimenti agli utenti.

• Due «tipi di dato» fondamentali: utenti e film

Caso di Studio – Netflix



• Ogni FILM deve essere descritto da un insieme di caratteristiche, ad esempio un codice identificativo, il nome, l’anno, la durata, il genere (o i generi), il regista, la trama, etc.

• Netflix prevede anche la possibilità di memorizzare le abitudini (gusti, preferenze) degli utenti. Ogni UTENTE è descritto da caratteristiche come nome utente, nome, cognome, data di nascita, data di iscrizione, etc.

• Importante: l’elenco delle caratteristiche non è esaustivo! Può essere esteso (o anche ridotto o modificato). Si tratta di una scelta di progetto.




• La piattaforma NETFLIX deve implementare le seguenti funzionalità

1. Caricamento/Salvataggio dell'elenco di film/Serie TV da file

Es. 1, House of Cards, 2009, David Fincher, Kevin Spacey; Robin Wright, Drammatico …..

2. Aggiunta, Modifica ed eliminazione dei film/Serie TV

3. Caricamento e Salvataggio dell'elenco degli utenti da file

4. Aggiunta, Modifica ed eliminazione degli utenti

5. Caricamento e Salvataggio dell'elenco delle preferenze degli utenti, da file

Es. utente1, House of Cards, like

Es. utente1, Stranger Things, watch

Es. utente2, Bojack Horseman, dislike

6. Aggiunta, Modifica e Cancellazione delle preferenze degli utenti




• La piattaforma NETFLIX deve implementare le seguenti funzionalità

7. Ricerca dei film/serie TV dato un campo di ricerca (genere, regista, attore, tipologia, anno, etc.)

8. Ordinamento dei film/serie TV, dato un campo di ricerca (ultimi film usciti,top-10 film più votati, top-10 film più visti, etc.)

9. Dato un utente, mostrare il suo "profilo" , cioè l'elenco dei contenuti che ha visto e l'elenco dei contenuti che ha gradito

• Tutte le funzionalità devono essere gestite ovviamente tramite un menu iniziale che guidi l’utente

• I file possono essere gestiti utilizzando il formato CSV (Comma Separated Value) oppure scegliendo i file binari. Il progetto deve ovviamente essere corredato con dei dati d’esempio.




• Progettare, realizzare e testare un programma che simuli la gestione della piattaforma SPOTIFY

• Spotify è una piattaforma che permette agli utenti di ascoltare in streaming i propri brani preferiti. Gli utenti possono inserire le proprie preferenze rispetto a brani. Le preferenze vengono utilizzate per dare dei suggerimenti agli utenti.

• Due «tipi di dato» fondamentali: utenti e artisti

• Nota: Spotify in realtà prevede anche i singoli brani. Per semplicità memorizziamo le informazioni sui singoli artisti.




• Ogni ARTISTA deve essere descritto da un insieme di caratteristiche, ad esempio un codice identificativo, il nome, il genere (o i generi), il produttore, la nazionalità, l’anno di inizio attività, etc.

• Spotify prevede anche la possibilità di memorizzare le abitudini (gusti, ascolti) degli utenti. Ogni UTENTE è descritto da caratteristiche come nome utente, nome, cognome, data di nascita, data di iscrizione, etc.





• La piattaforma SPOTIFY deve implementare le seguenti funzionalità

1. Caricamento/Salvataggio dell'elenco degli artisti da file

Es. 1, Coldplay, 1997, Pop; Britpop; Alternative Rock, England, Parlophone …..

2. Aggiunta, Modifica ed eliminazione degli artisti



5. Caricamento e Salvataggio dell'elenco delle preferenze degli utenti, da file

Es. utente1, Mannarino, like

Es. utente1, Sigur Ros, listen

Es. utente2, Justin Bieber, dislike

6. Aggiunta, Modifica e Cancellazione delle preferenze degli utenti




• La piattaforma SPOTIFY deve implementare le seguenti funzionalità

7. Ricerca degli artisti dato un campo di ricerca (genere, nazionalità, etichetta discografica, anno di inizio attività, etc.)

8. Ordinamento degli artisti, dato un campo di ricerca (top-10 artisti più ascoltati, top-10 artisti preferiti, etc.)

9. Dato un utente, mostrare il suo "profilo" , cioè l'elenco dei artisti che ha ascoltato e l'elenco degli artisti che ha gradito






• Progettare, realizzare e testare un programma che simuli la gestione della piattaforma AMAZON

• AMAZON è una piattaforma che permette agli utenti di acquistare prodotti. Le abitudini di acquisto degli utenti vengono registrate dalla piattaforma Le preferenze vengono utilizzate per dare dei suggerimenti agli utenti.

• Due «tipi di dato» fondamentali: utenti e prodotti

• Nota: Per semplicità ci si può concentrare su poche categorie di prodotti




• Ogni PRODOTTO deve essere descritto da un insieme di caratteristiche, ad esempio un codice identificativo, il nome, un’azienda produttrice, una categoria, un costo, eventuali caratteristiche, etc.

• Amazon prevede anche la possibilità di memorizzare le abitudini di acquisto degli utenti. Ogni UTENTE è descritto da caratteristiche come nome utente, nome, cognome, data di nascita, data di iscrizione, etc.





• La piattaforma AMAZON deve implementare le seguenti funzionalità

1. Caricamento/Salvataggio dell'elenco dei prodotti da file

Es. 1, iPhone 7, Apple, Telefonia, Rosso, 799

2. Aggiunta, Modifica ed eliminazione dei prodotti da file



5. Caricamento e Salvataggio delle abitudini di acquisto (e di visualizzazione) degli utenti, da file

Es. utente1, Samsung S7, view

Es. utente1, iPhone 7, buy

6. Aggiunta di nuovi acquisti o di visualizzazione di prodotti




• La piattaforma AMAZON deve implementare le seguenti funzionalità

7. Ricerca dei prodotti dato un campo di ricerca (produttore, categoria, costo etc.)

8. Ordinamento dei prodotti, dato un campo di ricerca (top-10 prodotti più costosi, top-10 prodotti più acquistati, etc.)

9. Dato un utente, mostrare il suo "profilo" , cioè l'elenco dei suoi acquisti e dei prodotti che ha visualizzato.



Caso di Studio – La ValutazioneA ogni caso di studio sarà assegnato un punteggio da 0 a 33 punti, distribuiti come segue.



Griglia di Valutazione Punti (max.)

Progetto Singolo Progetto in Coppia

Correttezza 12 punti 9 punti

Modularità 6 punti 6 punti

Stile di Programmazione 4 punti 4 punti

Testing 4 punti 4 punti

Documentazione 4 punti 4 punti

Funzionalità Avanzate Non previste 3 punti

Estensioni 3 punti (opzionale) 3 punti (opzionali)

Totale 33 punti 33 punti

Caso di Studio – La Valutazione1. Correttezza (9/12 punti)

• Il programma implementa correttamente tutte le funzioni indicate nelle specifiche. La correttezza riguarda anche l’utilizzo adeguato di puntatori e file, quando necessario. Anche la corretta progettazione delle strutture e delle variabili atte a risolvere il problema rientra in questa voce. La correttezza del programma riguarda anche la quantità di dati inseriti (max. 3 punti) nei file di esempio.

2. Modularità (max. 6 punti)

• Il programma è implementato seguendo correttamente i principi della programmazione modulare. Procedure e funzioni sono progettate correttamente, sia in termini di parametri di input che in termini di tipi di ritorno. E’ corretto implementare il progetto sia come libreria statica che come file .h /.c separati.

3. Stile di Programmazione (max. 4 punti)

• Il codice è scritto seguendo le linee guida corrette in termini di nomenclatura delle variabili e delle funzioni, scelta delle espressioni, indentazione, spaziatura e leggibilità.



Caso di Studio – La Valutazione4. Testing (max. 4 punti)

• I test sono progettati nel modo corretto e coprono tutti i casi (es. casi limite, situazioni di errore, etc.) che è necessario valutare. L’esecuzione dei test corrisponde a quanto indicato nel piano di test.

5. Documentazione (max. 4 punti)

• Il progetto è correttamente documentato e utilizza le librerie per la generazione automatica della documentazione dei metodi implementati. Ciascun elemento del progetto è documentato in modo preciso e completo seguendo le linee guida mostrate a lezione.

6. Funzionalità Avanzate (max. 3 punti per progetti in gruppo)

• Corretta implementazione delle funzionalità avanzate. La correttezza delle funzionalità avanzate è valutata esattamente come la correttezza delle funzionalità di «base» (punto 1)

7. Estensioni (opzionali)

• Eventuali estensioni alla traccia proposta, per puntare alla lode ☺

• Nei progetti «singoli» l’estensione può essere rappresentata dalle funzionalità avanzate.



Caso di Studio – La Consegna• Consegna: 10 giorni prima della data d’appello

• Es: Primo Appello = 19 Giugno Consegna = 9 Giugno

• Come?

• Collegarsi al servizio Inserire la password: labinf1617

• Creare un archivio zip che deve utilizzare la seguente nomenclatura: <matricola>_<cognome>_<appello>_<versione>.zip

• Es) 432941_musto_luglio2017_v1.zip



Caso di Studio – La Consegna• Consegna: max. 10 giorni prima della data d’appello

• Es: Primo Appello = 19 Giugno Consegna = 9 Giugno

• Come?

• Collegarsi al servizio Droppitome (https://dropitto.me/cataldomusto)

• Inserire la password: labinf1617

• Creare un archivio zip che deve utilizzare la seguente nomenclatura: <matricola>_<cognome>_<appello>_<versione>.zip

• Es) 432941_musto_luglio2017_v1.zip

• In caso di consegne di gruppo, sostituire il numero del gruppo a <cognome>



https://dropitto.me/cataldomusto

Caso di Studio – La Consegna



Caso di Studio – La Consegna• Cosa metto nel file .zip?

1. Documentazione del Caso di Studio

• Documento di Analisi + Documento di Progetto + Piano di Test e Relativa Esecuzione

2. Progetto Eclipse con i Sorgenti (verificare che l’import funzioni!)

3. Eseguibile funzionante (verificare che l’eseguibile funzioni!)

4. Compilazione ed esecuzione devono essere riproducibili sul computer del docente, pena la non ammissione all’orale.

• IMPORTANTE: fare attenzione al nome del file .zip

• Creare un archivio zip che deve utilizzare la seguente nomenclatura: <matricola>_<cognome>_<appello>_<versione>.zip oppure <matricola>_<gruppo>_<appello>_<versione>.zip Es) 432941_musto_luglio2017_v1.zip



Caso di Studio – Prova d’esame• Come è organizzato l’esame?

1. Se lo studente ha superato la prova d’esonero, consiste in una discussione del caso di studio

2. Viceversa, la discussione prevederà anche delle domande di teoria relative ai contenuti del corso (programmazione modulare, testing, debugging, stile di programmazione, etc.)



Caso di Studio – Prova d’esame

• Cosa si intende per discussione?

• Fase 1: Demo

• Lo studente o gli studenti mostrano le funzionalità implementate. Evidenziano i punti di forza e i punti di debolezza del programma. Si mostra se il programma risponde (o meno) ai requisiti funzionali e non funzionali.

• Fase 2: Documentazione

• Si entra nel merito di quanto implementato. E’ importante mostrare consapevolezza delle funzionalità implementate. Bisogna saper giustificare le scelte progettuali effettuate e conoscere gli algoritmi.

• Fase 3: Codice Sorgente

• Eventualmente, si guarda insieme il codice sorgente in caso di dubbi relativi alla ‘paternità’ del codice



Caso di Studio - FAQ1. Cosa succede se non consegno in tempo?

• In caso di consegna oltre i limiti, il progetto verrà valutato per l’appello successivo. Anche in caso di prenotazione alla prova d’esame la prova NON sarà valutata.

2. Cosa succede se il nome del file è errato?

• In caso di impossibilità di identificazione (es. matricola assente, cognome non corretto, appello non corretto) il file .zip sarà cestinato e la prova NON sarà valutata.

3. Cosa succede se dimentico il numero di versione?

• In caso di assenza del numero di versione sarà valutata la prima versione inviata, eventuali revisioni saranno ignorate.

4. Cosa succede se l’eseguibile non parte?

• L’impossibilità di eseguire il file impatterà sulla voce ‘Correttezza’ della griglia di valutazione. Il codice sarà comunque compilato nuovamente, e successivamente valutato.



Caso di Studio - FAQ5. Cosa succede se il codice non compila?

• Se l’eseguibile non parte e il codice non compila la prova sarà ovviamente non sufficiente. Il test sulla compilazione sarà effettuato anche in caso di codice che risulta essere eseguibile

6. Cosa succede se copio il codice di un altro studente?

• Il (presunto) plagio del codice non sarà comunicato. La prova sarà valutata normalmente, poi nel corso della prova orale bisognerà dimostrare di essere in grado di riprodurre autonomamente il codice e di conoscere alla perfezione quanto implementato.

7. Quanti dati bisogna inserire nella versione che viene consegnata?

• Il codice consegnato deve essere completo di dati di esempio. Non c’è un valore «minimo» di dati di esempio. E’ sufficiente un valore «realistico». 2 utenti e 10 film non è realistico ☺10000 utenti e 1000000 oggetti richiede troppo tempo. Una via di mezzo va benissimo! La quantità di dati di esempio è un elemento di valutazione.



11/05/2017 3811/05/2017 38Cataldo Musto - Presentazione Casi di Studio


Laboratorio di Informaticaswap/labinf1617/Casi_di_Studio_Introduzione.pdf · Laboratorio di...

Documents

Transcript of Laboratorio di Informaticaswap/labinf1617/Casi_di_Studio_Introduzione.pdf · Laboratorio di...