Ingegneria del Software

Dott. Ing. Leonardo RigutiniDipartimento Ingegneria dell’InformazioneUniversità di SienaVia Roma 56 – 53100 – SIENAUff. 0577233606rigutini@dii.unisi.itwww.dii.unisi.it/~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