La Progettazione del Software
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
La Progettazione del Software
Definizioni IEEE
Metodologie di progettazione
Principi di progettazione
Tecniche di progettazione (top down e bottom up)
Moduli e criteri di modularizzazione: coesione ed
accoppiamento, indipendenza Funzionale
Notazione e specifica di progetto: GDN e TDN
Anna Rita Fasolino- Ingegneria del Software - 1
La Progettazione
La fase di Progettazione
IEEE Std 610.12-1990
Anna Rita Fasolino- Ingegneria del Software - 2
La Progettazione
1Anna Rita Fasolino- Ingegneria del Software - 3
La Progettazione
Anna Rita Fasolino- Ingegneria del Software - 4
La Progettazione
2La progettazione
– l’insieme delle attività che, a partire dalla specifica dei
requisiti del sistema software, producono un modello del
sistema da realizzare (una soluzione al problema...)
– da un modello del dominio applicativo ad un modello
della soluzione da attuare
– mappare” i requisiti specificati su elementi che dovranno
essere fisicamente realizzati
– individuazione e specificazione degli elementi da
realizzare, delle relazioni tra tali componenti, e di come
realizzarli
– il tutto sempre in accordo ai requisiti software specificati
nella fase di analisi
Anna Rita Fasolino- Ingegneria del Software - 5
La Progettazione
Requisiti Software
Low Level
Design
High Level Design
Anna Rita Fasolino- Ingegneria del Software - 6
La Progettazione
3Livelli di progettazione
• High level design (o progetto architetturale)
– identificazione e specifica delle componenti strutturali del
sistema e delle loro inter-connessioni
• Low level design (o progetto di dettaglio )
– decisione su come la specifica delle componenti sarà
realizzata (descrizione dettagliata della logica di
elaborazione)
• Data design
– definizione delle strutture logiche dei dati
Anna Rita Fasolino- Ingegneria del Software - 7
La Progettazione
La fase di progettazione
• Input alla fase di progettazione:
– la specifica del sistema da realizzare (quanto più completa,
consistente, non ambigua)
• Output della fase:
– progetto architetturale
– progetto di dettaglio
– Progetto dei dati
• Terminazione ed uscita dalla fase:
– verifica del progetto rispetto alla specifica
– valutazione ed approvazione della sua qualità
Anna Rita Fasolino- Ingegneria del Software - 8
La Progettazione
4Fasi di un processo di design
Requirements
specification
Design acti
vities
Architectur
al Interface Component Data Algorithm
Abstract
design design design structur
e design
specification
design
Softwar e Data
System Interface Component Algorithm
specification structure
architectur
e specification specification specification
specification
Design pr
oducts
Anna Rita Fasolino- Ingegneria del Software - 9
La Progettazione
Fasi di un processo di design
• Architectural design
Definizione dei componenti (sottosistemi) software e loro relazioni
• Abstract specification
Specifica di alto livello dei componenti
• Interface design
Definizione e specifica delle interfacce dei componenti
• Component design
Specifica dettagliata dei singoli componenti
• Data structure design
Progettazione delle strutture dati atte a contenere i dati del
problema
• Algorithm design
Progettazione degli algoritmi per le funzioni del problema
Anna Rita Fasolino- Ingegneria del Software - 10
La Progettazione
5Design quality
Design quality is an elusive concept
• Un “buon” design può essere il più efficiente, il più
economico, il più manutenibile, il più affidabile, etc.
• Gli attributi riguardano anche la manutenibilità del
progetto
• Caratteristiche di qualità sono ugualmente applicabili a
progettazione function-oriented e object-oriented
Anna Rita Fasolino- Ingegneria del Software - 11
La Progettazione
Design goals
Design for change
• anticipare i cambiamenti plausibili
• non concentrarsi sulle necessità di oggi, ma pensare
alla possibile evoluzione
• ma anche ... non fare assunzioni che si sa che
domani si riveleranno false
» es., the Y2K problem
Component family
• pensare ad un componente (es. programma) come ad
un membro di una famiglia
Anna Rita Fasolino- Ingegneria del Software - 12
La Progettazione
6Design for change
Semplici esempi:
• Cambiamenti negli algoritmi
da bubblesort a quicksort
• Cambiamenti nelle strutture dati
17% dei costi di manutenzione
• Cambiamenti nella “underlying abstract machine”
Periferiche hardware, OS, DBMS, …
new releases, portability problems
• Cambiamneti nell’ambiente (es., EURO)
• Cambiamenti dovuti alla strategia di sviluppo
evolutionary prototype
Anna Rita Fasolino- Ingegneria del Software - 13
La Progettazione
Component family
Pensare ad un componente e a tutte le sue varianti come un
membro di una famiglia
• l’obiettivo è di progettare l’intera famiglia, non ogni singolo
individuo della famiglia separatamente
Esempio di component family: Un sistema a supporto di
prenotazioni
• per un hotel:
prenota stanze, ristorante, spazio per conferenze, …
apparecchiature (video beams, overhead projectors, …)
• per una università:
molte funzionalità sono simili, alcune sono diverse (es., facilities
possono essere gratis o meno)
Anna Rita Fasolino- Ingegneria del Software - 14
La Progettazione
7A parità di specifica dei requisiti sono possibili differenti soluzioni
progettuali
Scegliere quella che consentirà di realizzare il sistema con il più elevato
livello di qualità, rispetto ai requisiti
In particolare, i componenti dovrebbero essere progettati in modo da
essere:
• facilmente costruibili
• facilmente collaudabili
• facilmente comprensibili
• facilmente correggibili
• facilmente modificabili
• affidabili
• corrette
• ……….
Uso di principi e metodologie di progettazione
– definiscono un approccio sistematico alla definizione del
progetto, attraverso l'applicazione di tecniche e linee guida
Anna Rita Fasolino- Ingegneria del Software - 15
La Progettazione
Principi di progettazione
• Perché i principi?
– La progettazione è un’attività estremamente creativa, non
riducibile ad un insieme di passi da seguire
– I principi di riferimento guidano verso il raggiungimento degli
obiettivi di qualità per il progetto
– Correttezza, Verificabilità, Completezza, Tracciabilità,
Semplicità del progetto conducono verso...
– Manutenibilità, Modificabilità, Comprensibilità, Riusabilità del
software
• alcuni principi: Decomposizione, Raffinamento,
Astrazione, Information Hiding, Modularità,
Anticipazione del cambiamento..
Anna Rita Fasolino- Ingegneria del Software - 16
La Progettazione
8Decomposizione
• Decomporre il Sistema in sottosistemi, gestibili separatamente, per
dominarne la complessità
• P= problema, C=complessità di P, E=sforzo per la risoluzione di P
Dati 2 problemi P1 e P2
se C(P1) > C(P2), allora E(P1)> E(P2)
ma è stato dimostrato che C(P1+P2)> C(P1) + C(P2),
e quindi si ha che E(P1+P2)> E(P1) + E(P2)
La scomposizione introduce Costo Costo totale
il problema della Costo
comunicazione fra le varie interfacciamento
parti, il che aggiunge Costo modulo
complessità per
l’interfacciamento.
Numero di moduli
Anna Rita Fasolino- Ingegneria del Software - 17
La Progettazione
Raffinamento
• Gli elementi individuati con la decomposizione sono
ulteriormente decomposti per passi successivi
• …. generazione di strutture gerarchiche
Anna Rita Fasolino- Ingegneria del Software - 18
La Progettazione
9Astrazione
• Permette di concentrarsi su un problema ad un
determinato livello di astrazione, senza perdersi in
dettagli irrilevanti
• Permette di descrivere un componente tramite il suo
comportamento esterno senza preoccuparsi dei
dettagli interni che lo producono
• E’ fondamentale nel partizionamento, giacché
consente di individuare le componenti del sistema e
le modalità di interazione
Anna Rita Fasolino- Ingegneria del Software - 19
La Progettazione
Forme di astrazione
• funzionale:
– completa definizione di una funzionalità indipendentemente
dall’algoritmo che la implementa
• di dati:
– completa definizione di un dato o un tipo di dato in base alle
operazioni che su di esso possono essere fatte, senza
definirne una struttura concreta
• di controllo:
– completa definizione di un meccanismo di controllo senza
indicarne i dettagli interni, ad esempio semafori per
sincronizzare processi concorrenti
Anna Rita Fasolino- Ingegneria del Software - 20
La Progettazione
10Information Hiding
• consiste nel rendere invisibili i dettagli interni di un
modulo, e nel rendere inaccessibili, a componenti
che non ne necessitano, i dettagli di strutture dati e
strutture procedurali.
Anna Rita Fasolino- Ingegneria del Software - 21
La Progettazione
Modularità
• E’ una conseguenza del principio di decomposizione: il progetto
deve essere modulare, con moduli ben definiti, facilmente
gestibili e con interfacce ben definite
• ….. architettura del software è vista come l’organizzazione della
struttura modulare, cioè moduli + relazioni fra di essi
– ogni modulo implementa un’astrazione, potenzialmente
riusabile nello stesso o in altri sistemi;
– ogni astrazione ha un unico e ben definito scopo;
Anna Rita Fasolino- Ingegneria del Software - 22
La Progettazione
11Modulo
• Un modulo è un’entità SW identificata da un nome
che:
– contiene istruzioni, strutture dati, controllo
– può essere incluso in un altro modulo
– può usare un altro modulo.
– In termini di costrutti di programmazione : una macro, un
programma, un sottoprogramma, un processo, un package
• …. considereremo il modulo come un contenitore per esprimere
astrazioni (funzionali, di strutture dati, di controllo)
Anna Rita Fasolino- Ingegneria del Software - 23
La Progettazione
Tecniche di progettazione
• Approccio Top- down
– si parte con l’identificazione dei principali componenti del
sistema, i quali vengono decomposti in componenti di più
basso livello, iterando finché viene raggiunto il desiderato
livello di dettaglio (Step-wise Refinement)
• Approccio Bottom-up
– si parte progettando i componenti basilari di basso livello e si
procede con i componenti di più alto livello che utilizzano i
primi.
– Si procede dunque per livelli di astrazione (layers of
abstraction)
Anna Rita Fasolino- Ingegneria del Software - 24
La Progettazione
12Decomposizione funzionale
• Ciascun modulo implementa una specifica
funzionalità dei requisiti (o sub-funzionalità) ed ha
una interfaccia semplice verso gli altri moduli
(indipendenza funzionale)
– Minimizzare il numero e la complessità delle inter-
connessioni fra moduli
– Massimizzare la forza interna di un modulo intesa come
contributo alla funzionalità dato da ciascun modulo
• Criteri per la modularizzazione: Coesione ed
Accoppiamento
Anna Rita Fasolino- Ingegneria del Software - 25
La Progettazione
Coesione
• Esprime il grado di correlazione fra gli elementi all’interno di un
modulo.
– Un modulo coesivo esegue un singolo compito e richiede poca
interazione con le procedure eseguite in altre parti del software
• coesione ⇒ un modulo deve esprimere 1 sola astrazione
• (1 funzione, 1 oggetto, 1 tipo astratto, 1 oggetto generico, 1 tipo
astratto generico, 1 politica, 1 controllo)
• Spettro di coesione
• Casuale
-
• Logica
• Temporale
• Procedurale
• Comunicazionale
• Sequenziale
• Funzionale
+
Anna Rita Fasolino- Ingegneria del Software - 26
La Progettazione
13Spettro di Coesione
• coesione casuale: un modulo svolge attività poco correlate fra loro;
• coesione logica: un modulo svolge attività logicamente correlate fra loro
(trattamento errori, stampa risultati,…);
• coesione temporale: un modulo svolge attività che devono essere
eseguite in uno stesso intervallo di tempo (inizializzazione,
terminazione,…);
• coesione procedurale: un modulo svolge attività correlate da eseguirsi in
uno specifico ordine;
• coesione comunicazionale: un modulo svolge attività che si riferiscono
ad un insieme di dati comune;
• coesione sequenziale: un modulo svolge attività per cui l’output di
un’attività è l’input della successiva;
• coesione funzionale: un modulo svolge un’unica attività e nessun’altra
aggiuntiva, tutti gli elementi del modulo sono strettamente correlati e
contribuiscono alla realizzazione dell’attività
Anna Rita Fasolino- Ingegneria del Software - 27
La Progettazione
RICONOSCIMENTO DELLA COESIONE
• Una regola empirica per determinare la coesione è la seguente:
• descrivere la funzione del modulo con una frase:
• se la frase è composta, contiene virgole o più di un verbo, il
modulo probabilmente svolge più di una funzione; (sequenziale
- comunicazionale - logica)
• se la frase fa riferimento al tempo ( prima, dopo, quando, alla
fine, …) probabilmente coesione sequenziale, temporale o
procedurale;
• se la parte predicativa non ha, dopo il verbo, un singolo oggetto
specifico, probabilmente coesione comunicazionale o logica
(ad es. “stampa tutti i dati”, … ma “stampa tutti i dati della
fattura” ha coesione funzionale);
• parole come inizializza, pulisci, implicano coesione temporale
Anna Rita Fasolino- Ingegneria del Software - 28
La Progettazione
14RICONOSCIMENTO DELLA COESIONE
Nel modulo si riconosce una funzione
del dominio di applicazione ?
no s i
cosa lega le
attività nel modulo funzionale
Flusso di controllo N e s s u n o d e i d u e
Flusso dei dati
E’ importante E’ importante Le attività
la sequenza ? la sequenza ? appartengono
alla stessa
categoria ?
n o si no si no si
Temporale Procedurale C o m u n i c a z i o n . Sequenz. Casuale Logico
Anna Rita Fasolino- Ingegneria del Software - 29
La Progettazione
Accoppiamento
• Esprime la forza di inter-connessione fra moduli
– maggiori connessioni implicano maggiore dipendenza fra
moduli, ossia maggiore conoscenza di un modulo richiesta
per comprendere un altro modulo (implicazioni su
comprensibilità e manutenibilità del modulo)
• Minimizzare l’accoppiamento, semplificando:
– tipo di connessione (solo connessioni attraverso l’interfaccia,
non patologiche)
– complessità dell’interfaccia (numero e tipo di parametri)
– tipo di flusso di informazioni fra moduli (dati / controlli)
Anna Rita Fasolino- Ingegneria del Software - 30
La Progettazione
15Spettro di accoppiamento
• nessun accoppiamento diretto;
• accoppiamento per dati: lista di parametri costituiti da dati
semplice;
• accoppiamento per strutture: struttura dati passata tramite
interfaccia;
• accoppiamento per controllo: passaggio di flag condizionanti
l’esecuzione in un altro modulo;
• accoppiamento esterno: associazione ad elementi esterni (ad es.
I/O a specifici dispositivi);
• accoppiamento per aree comuni: condivisione di aree dati
comuni;
• accoppiamento per contenuto: un modulo usa e modifica dati o
informazioni di controllo propri di un altro modulo.
Anna Rita Fasolino- Ingegneria del Software - 31
La Progettazione
Obiettivi della progettazione modulare
• massimizzare la coesione interna: per migliorare la
comprensibilità del modulo e la sua modificabilità;
• minimizzare il grado di accoppiamento fra i moduli:
per migliorare la comprensibilità di ciascun modulo.
• Con riferimento all’astrazione, un lasco
accoppiamento ⇒ un’astrazione implementata in un
modulo deve essere largamente indipendente da
ogni altra astrazione
Anna Rita Fasolino- Ingegneria del Software - 32
La Progettazione
16Relazioni fra moduli
Relazione USA:
due moduli mi ed mj sono in tale relazione (mi USA mj ) se, affinché il modulo
mi risulti corretto rispetto alle sue specifiche, è necessaria anche la corretta
esecuzione di mj : ovvero mi necessita di qualche cosa implementata in mj .
A costituzione di gerarchie (relazione USA
priva di cicli)
Livelli: livello 0 per moduli senza archi
B C entranti; livello i se il cammino di massima
lunghezza congiungendoli a moduli a livello
0 ha lunghezza i.
mi ha un’astrazione maggiore di mj se ha un
D E F livello minore.
Anna Rita Fasolino- Ingegneria del Software - 33
La Progettazione
Relazione USA
Due estremi:
• ciascun modulo usa tutti gli altri: accoppiamento elevato;
• nessun modulo usa un altro (sistema complessivo formato da moduli totalmente
isolati, non interagenti tra loro): può nascondere gravi difetti di duplicazione di
intere parti, ad esempio funzionalità comuni a più moduli distribuite tra essi e
non raggruppate.
Per una buona progettazione:
• un modulo dovrebbe fare un uso limitato delle risorse messe a disposizione
dagli altri
• un modulo dovrebbe essere usato da più altri (buona fattorizzazione delle
risorse che sono usate da altri)
Attenzione: la realizzazione fisica di una relazione USA fra moduli non sempre
ha luogo tramite chiamate a procedura, ma anche mediante accessi ad
informazioni condivise, scambio di messaggi.
Anna Rita Fasolino- Ingegneria del Software - 34
La Progettazione
17Relazione COMPONENTE_DI
deriva dalla scomposizione, raffinamento, di moduli in sottomoduli;
dà luogo ad una gerarchia, rappresentabile graficamente.
A
A1 A2 A3
COMPONENTE_DI
Anna Rita Fasolino- Ingegneria del Software - 35
La Progettazione
N.B.
fra tutti i moduli di una relazione COMPONENTE_DI, solo quelli
che non hanno alcun altro modulo componente hanno un’esistenza
fisica effettiva nel sistema SW finale
I moduli intermedi sono contenitori logici di moduli.
Essi sono dovuti al fatto che è impossibile in un unico passo
giungere alla comprensione di tutti e soli i moduli reali.
Fanno comunque parte della documentazione del progetto
Anna Rita Fasolino- Ingegneria del Software - 36
La Progettazione
18Se un modulo mi scomposto in sottomoduli m(i) era in relazione
USA con altri moduli, vanno ridefiniti (ridistubuiti) i
collegamenti delle relazioni USA sui moduli m(i).
Con riferimento all’esempio presedente:
COMPONENTE_DI USA
A
A1 A2 A3
A1 A2 A3 F B C
B C
B1 B2
B1 B2 C1 C2 F
D E
Anna Rita Fasolino- Ingegneria del Software - 37
La Progettazione
Notazioni grafiche del Design (GDN)
M esprimono la struttura gerarchica e
le relazioni tra i moduli
B C
B1 B2 C1 C2 A
D E F
B C
B1 B2 C1 C2
D E F
Anna Rita Fasolino- Ingegneria del Software - 38
La Progettazione
19Una Notazione Testuale dei Moduli (TDN)
module
uses
exports
--eventuali commenti sulle risorse esportate
--vincoli su come possono essere usate dai clienti;
implementation
is composed of
--descrizione ad alto livello di astrazione della implementazione
end
Anna Rita Fasolino- Ingegneria del Software - 39
La Progettazione
Esempio
moduleY
module X
R
T module Z
A B C
Risorse richieste da moduli client
Anna Rita Fasolino- Ingegneria del Software - 40
La Progettazione
20Esempio
module X
uses Y, Z
exports var A : integer;
type B : array (1. .10) of real;
procedure C ( D: in out B; E: in integer; F: in real);
--eventuali commenti su chi sono A, B, e C, con eventuali
--vincoli su come possono essere usati dai clienti;
--p.es., elementi di tipo B trasferiti a C devono essere
--inizializzati dal cliente e non devono contenere tutti 0
implementation
is composed of R, T
--se necessario, fornire commenti su come realizzato
--nell’es., come è scomposto in moduli di più basso livello
;
end X
Anna Rita Fasolino- Ingegneria del Software - 41
La Progettazione
Esempio
module R
uses Y
exports var K : record . . . end;
type B : array (1. .10) of real;
procedure C (D: in out B; E: in integer; F: in real);
implementation
...
end R
module T
uses Y, Z, R
exports var A : integer;
implementation
...
end T
Anna Rita Fasolino- Ingegneria del Software - 42
La Progettazione
21Il Progetto dei dati
• In questa fase vengono scelte le rappresentazioni logiche più
opportune dei dati (struttura dei dati) identificati nella fase di specifica
dei requisiti, che siano più vicine a quelle che saranno utilizzate in fase
di codifica
• ad esempio si decide di utilizzare liste, stacks, archivi, … senza
specificare come poi saranno implementati
• Alcune linee guida...
• usare metodi di analisi sistematici: rappresentare la struttura dei dati e
le relazioni tra di essi, considerare strutture alternative e valutarne
l’impatto sul software
• astrazione sui dati: identificare tutte le strutture dati e le relative
operazioni su di esse
• sviluppare un dizionario dei dati: indicare esplicitamente le relazioni tra
i dati ed i vincoli esistenti sugli elementi di una struttura dati
• information hiding e pensare al riuso
Anna Rita Fasolino- Ingegneria del Software - 43
La Progettazione
La Progettazione di dettaglio
• Scopo di questa fase, detta anche di progetto procedurale, è
di fissare il come debbano essere realizzate le componenti di
progetto specificate. Richiede la definizione di:
• dettagli algoritmici,
• rappresentazioni reali dei dati,
• relazioni tra funzioni e strutture dati,
• packaging del software: cioè come mettere insieme in moduli
funzioni e strutture dati.
• Diversi tipi di notazione:
• flow-chart o linguaggio naturale strutturato
• pseudocodice (PDL)
• diagrammi a scatole
• tabelle di decisione
Anna Rita Fasolino- Ingegneria del Software - 44
La Progettazione
22La documentazione di Progetto
1. Ambito
5. Progetto procedurale
1.1 Obiettivi del sistema
Per ogni modulo
1.2 Requisiti principali del Sw
5.1 Descrizione informale
1.3 Vincoli e limitazioni progettuali
5.2 Descrizione delle interfacce
2. Progetto dei dati
5.3 Descrizione del linguaggio del progetto
2.1 Oggetti-dato e strutture dati
5.4 Moduli utilizzati
2.2 File e Basi di dati
5.5 Descrizione strutture dati interne
2.2.1 Struttura dei file esterni
5.6 Descrizione del progetto di dettaglio
2.2.2 Struttutra logica
5.7 Commenti/restrizioni/limitazioni
2.2.2.1 Descrizione dei record logici
rappresentazione in TDN
2.2.2.2 Metodo di accesso
6. Indice dei requisiti (con riferimenti incrociati)
2.3 Riferimenti incrociati file-dati
6.1 preparazione al testing
6.1.1 Linee guida
3. Progetto architetturale
6.1.2 Strategia di integrazione
rappresentazione grafica della struttura
7. Considerazioni specifiche
3.1 Descrizione della struttura modulare
8. Note particolari
3.2 Descrizione del flusso dati e di controllo
9. Appendici
4. Progetto delle interfacce
4.1 Specifica dell’interfaccia uomo -macchina
4.2 Regole di progettazione dell’interfaccia uomo -
macchina
4.3 Progetto delle interfacce esterne
4.3.1 Interfacce verso i dati esterni
4.3.2 Interfacce verso sistemi e dispositivi
esterni
4.4 Regole di progettazione dell’interfacce esterne
Anna Rita Fasolino- Ingegneria del Software - 45
La Progettazione
23Puoi anche leggere
