Ingegneria del Software Dott. Ing. Leonardo Rigutini Dipartimento Ingegneria dell’Informazione Università di Siena Via Roma 56 – 53100 – SIENA Uff. 0577233606 [email protected] www.dii.unisi.it/ ~ rigutini /
Ingegneria del Software
Dott. Ing. Leonardo RigutiniDipartimento Ingegneria dell’InformazioneUniversità di SienaVia Roma 56 – 53100 – SIENAUff. [email protected]/~rigutini/
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
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.
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.
Caratteristiche di un prodotto software
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
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
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
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...
4 – Prestazioni (performances)
Efficiente utilizzo delle risorse: Memoria – occupazione di spazio CPU – occupazione di “tempo” Rete – Occupazione di banda …
Verifica: analisi della complessità simulazioni
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...)
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.
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%).
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.
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...
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..)
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.
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...
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
Ciclo di vita del software
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
Progettazione
Fase di progettazione dell'architettura del programma
Principi chiave: Rigore e formalismo Separazione tra “concetti” Modularità Astrazione Anticipazione dei cambiamenti Generalità Incrementalità
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.
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
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...
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.
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)
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)
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)
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
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.
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à
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à)
Fase di rilascio1. 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.
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.
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