Ingegneria del Software Dott. Ing. Leonardo Rigutini Dipartimento Ingegneria dellInformazione Università di Siena Via Roma 56 – 53100 – SIENA Uff. 0577233606.

Presentazione sul tema: "Ingegneria del Software Dott. Ing. Leonardo Rigutini Dipartimento Ingegneria dellInformazione Università di Siena Via Roma 56 – 53100 – SIENA Uff. 0577233606."— Transcript della presentazione:

1 Ingegneria del Software Dott. Ing. Leonardo Rigutini Dipartimento Ingegneria dellInformazione Università di Siena Via Roma 56 – 53100 – SIENA Uff. 0577233606 rigutini@dii.unisi.it www.dii.unisi.it/~rigutini/

2 Prodotto software Rilevanti differenze rispetto alle tradizionali tipologie di prodotto: – Intangibile: descrizione funzionale – Modificabile il risultato non è definitivo, ma nel tempo può subire modifiche anche molto rilevanti

3 Prodotto e processo Prodotto Risultato dello sviluppo dell'applicazione richiesta Processo: Insieme di operazioni che portano alla realizzazione del prodotto La qualità del processo influenza la qualità del prodotto.

4 Caratteristiche esterne: Visibili agli utenti –> funzionalità richieste e interfaccia grafica interne: Riguardano gli sviluppatori –> funzionalità interne, progettazione, problemi di performance ecc.. Le caratteristiche interne influenzano quelle esterne.

5 Caratteristiche di un prodotto software

6 1 - Correttezza Un prodotto software è corretto se soddisfa i requisiti funzionali richiesti analisi dei requisiti e specifiche Se le specifiche sono formali (caso di programmi formali), la correttezza può essere verificata formalmente: prova di un teorema matematico

7 1 – Correttezza Non esistono gradi di correttezza ma è un valore assoluto e binario: corretto/non corretto Cosa succede se le specifiche iniziali sono sbagliate? Es. caso di un'analisi iniziale parziale o non chiara

8 2 - Affidabilità L'utilizzatore del programma DEVE fidarsi che ciò che sta facendo sia fatto correttamente E' definita come la probabilità di assenze di fallimenti in un certo periodo di tempo: Maggiore è il periodo di lavoro senza intoppi, maggiore è l'affidabilità di un programma Es. windows vs. MacOS

9 3 - Robustezza Capacità di gestire situazioni fuori dalla normalità: Operazioni incorrette da parte dell'utilizzatore Problemi hardware … Più il programma riesce a prevedere e a gestire comportamenti errati dell'utente, maggiore è il grado di robustezza del software: Procedure di backup, undo, richieste di conferma per le operazioni più pericolose ecc...

10 4 – Prestazioni (performances) Efficiente utilizzo delle risorse: Memoria – occupazione di spazio CPU – occupazione di tempo Rete – Occupazione di banda … Verifica: analisi della complessità simulazioni

11 5 – Usabilità Misura la capacità richiesta all'utente per l'utilizzo del programma. Altrimenti conosciuta come: user-friendliness Caratteristiche: Molto soggettiva e variabile: utenti diversi possono ritenere lo stesso programma più o meno usabile Riguarda principalmente l'insieme delle interfacce uomo/macchina utilizzate nel programma (uso di finestre rispetto alla linea di comando, device esterni come lettori ottici ecc...)

12 6 - Manutenibilità Manutenzione: modifiche o miglioramenti successivi al rilascio del prodotto. I costi di manutenzione sono il 60% dei costi totali di produzione di un programma. La manutenibilità di un software misura quanto esso sia facile da aggiornare, modificare o migliorare: In altre parole, facilità di manutenzione.

13 6 – Manutenibilità Tre tipi di interventi: Correttiva – rimozione di errori residui (20%) Adattiva – aggiustamenti necessari a seguito di cambiamenti dell'ambiente (20%): es. modifica di una legge in un programma di gestione tributaria. Perfettiva – Miglioramenti rispetto alla versione attuale (60%).

14 7 - Riusabilità Capacità del software di poter essere riutilizzato in altri ambiti con uno sforzo programmativo ridotto: Es. software per la gestione di magazzino di un negozio di PC e di un negozio di abiti. Riutilizzo di gran parte del codice scritto. Enorme risparmio di tempo e conseguente possibilità di allargamento del mercato.

15 8 - Portabilità Capacità del programma di essere eseguito su diverse piattaforme hardware o software Portabilità software: Sistema operativo – Windows, MacOS, linux ecc... Portabilità hardware: Computer con diverse caratteristiche fisiche, 256Mb contro 1Gb di RAM, ecc...

16 9 - Interoperabilità Capacità del software di comunicare con altri programmi. Uso di standard: per lo scambio di dati (es. PDF, xml, ecc...) per la comunicazione (es. TCP/IP, ethernet ecc..) Per la gestione di periferiche (es. stampanti, periferiche video ecc..)

17 10 - Chiarezza Misura la facilità di comprensione da parte di un tecnico del programma Influenza la manutenibilità in quanto nuovi programmatori possono facilmente ed in tempi brevi entrare nel programma.

18 Tipologie di programma Operazioni real-time: requisiti temporali stringenti necessità di risposte immediate e in tempi certi Es. sistemi di guida, programmi per automazione industriale ecc... Operazioni batch: Possono essere demandate ad un secondo momento Es. aggiornamento, ricreazione dell'indice, ecc...

19 Tipologie di programma Standalone: Programma completamente installato su un computer. Maggior consumo di memoria e cpu. Programma distribuito: Software di rete, normalmente applicazioni client- server che centralizzano il nucleo dell'applicazione su un server remoto. Sul computer è in esecuzione solamente un programma client che richiede funzionalità al server. Minor utilizzo di memoria e cpu, ma maggior consumo di rete

20 Ciclo di vita del software

21 Analisi dei requisiti Primo passo per la progettazione di un software: Specifica dei requisiti da parte del committente Analisi dei requisiti da parte del progettista Passo che normalmente viene iterato più volte per accertare al massimo l'accordo tra committente e realizzatore: Differenze di linguaggio Differenze di punti di vista (interfaccia rispetto a funzionalità) Problemi inizialmente non analizzati e/o apparsi successivamente

22 Progettazione Fase di progettazione dell'architettura del programma Principi chiave: Rigore e formalismo Separazione tra concetti Modularità Astrazione Anticipazione dei cambiamenti Generalità Incrementalità

23 1 – Rigore e formalismo La specifica e l'analisi dei requisiti deve essere il più possibile rigorosa e formale. Laddove è possibile dare una rappresentazione formale (matematica o simile), dovrebbe essere fatto. Normalmente vengono redatti una serie di documenti descrittivi delle funzionalità e dei requisiti individuati.

24 2 – Separazione tra concetti Per dominare la complessità di grossi progetti software è necessario separare i problemi, affrontarli in maniera indipendente e poi ri-assemblarli per ottenere la soluzione generale. Approccio Divide et Impera: i sotto-problemi sono più semplici da risolvere la loro ricomposizione per la soluzione generale non dovrebbe aggiungere eccessiva complessità al problema

25 2 – Separazione tra concetti Permette la parallelizzazione degli sforzi di realizzazione: i singoli sotto-problemi individuati possono essere sviluppati indipendentemente e ri-assemblati alla fine per ottenere il prodotto finale Anche le responsabilità realizzative all'interno del team di progettazione/sviluppo sono separate e limitate a sottoparti dell'intero sistema: pochi responsabili di progetto, molti responsabili di primo livello ecc...

26 3 – Modularità La separazione dei concetti, in fase di schematizzazione del progetto si trasforma in modularità: il progetto generale viene suddiviso in moduli. Modulo: Sotto-blocco di un sistema caratterizzato da un insieme di funzionalità o compiti affini es. un modulo gestore di database si occupa di tutte le operazioni su database.

27 3 – Modularità La suddivisione in moduli può essere ricorsiva: Primo livello individuazione di entità funzionali di alto livello (molto astratte) Secondo livello all'interno di ogni modulo individuato al passo precedente vengono isolati altre entità funzionali chiare e con sotto-compiti distinti (sempre più specifiche).... Ultimo livello livello oltre il quale non si riesce ad individuare ulteriori blocchi funzionali (funzionalità di basso livello)

28 3 – Modularità Creazione di schemi a blocchi: Rettangoli per individuare le entità (moduli) Frecce o linee per schematizzare le interconnessioni tra esse La direzione delle frecce chiarisce la direzionalità dello scambio dati tra moduli: input, output o entrambe Es: il risultato dell'elaborazione di un modulo viene passato al gestore di database, ma, in altre situazioni, la lettura effettuata dal gestore di database deve essere passata al modulo (freccia bidirezionale)

29 3 – Modularità: coesione ed accoppiamento Elevato grado di coesione interna: moduli capibili separatamente moduli con operazioni e/o proprietà affini Elevato accoppiamento interno ed uno scarso accoppiamento esterno: le funzionalità di un modulo utilizzano il più possibile le altre funzionalità e/o proprietà interne le funzionalità e/o proprietà interne di un modulo sono scarsamente utilizzate da altri moduli (tranne i moduli padre in cui eventualmente sono inseriti)

30 4 - Astrazione Identificare gli aspetti importanti di un fenomeno (leggi modulo) ed ignorare il più possibile i suoi dettagli. Approccio a scatola nera (black-box): Definire le funzionalità di interfaccia senza preoccuparsi di come esse saranno realizzate

31 5 – Anticipazione dei cambiamenti Abilità a supportare le evoluzioni del software richiede di anticipare i possibili cambiamenti futuri. E' alla base per un software manutenibile e in continuo aggiornamento.

32 6 – Generalizzazione Quando si approccia ad un problema, cercare di capire se esso è un caso particolare di un problema più generale: Molte volte il problema più generale è già stato risolto oppure è più semplice da risolvere. Vantaggi: Riutilizzo Astrazione Modularità

33 7 - Incrementabilità Il processo di realizzazione di un software segue due strade in parallelo: Sviluppo Rilascio di versioni intermedie Dal rilascio di versioni intermedie è possibile avere feedback per modificare o aggiungere caratteristiche (funzionalità)

34 Fase di rilascio 1.Rilascio di un un sottoinsieme di funzionalità allo scopo di ottenere dagli utenti dei feedback per successive modifiche o aggiunte. Le rimanenti funzionalità sono aggiunte in maniera incrementale. 2.Rilascio di un prodotto completo in termini di funzionalità, ma poco ottimizzato in termini di performances. 3.Rilascio di un primo prototipo del prodotto (non singole funzionalità come nel caso 1) e successiva trasformazione in prodotto finale.

35 Sviluppo Una volta creato/i gli schemi a blocchi individuanti le entità del progetto e le loro interconnessioni è possibile passare alla fase di realizzazione: Implementazione Ogni entità corrisponde ad una classe: le proprietà di una entità possono essere realizzate tramite variabili della classe. Le funzionalità assegnate alla entità (modulo) possono essere realizzate tramite i metodi.

36 Sviluppo Le interazioni tra moduli si trasformano in chiamate di funzione: la direzione della freccia indica chi chiama cosa Es: Service chiama il metodo scrivi della classe DBManager Service Salva nel DB DBManager