la progettazione del softwarewpage.unina.it/fasolino/is/materiale/6-progetto-new.pdf4 anna rita...
TRANSCRIPT
1
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
1
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 -La Progettazione
2
La fase di Progettazione
IEEE Std 610.12-1990
2
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
3
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
4
3
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
5
La 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 -La Progettazione
6
Requisiti Software
High Level Design
Low Level Design
4
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
7
Livelli 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 -La Progettazione
8
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à
5
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
9
Architecturaldesign
Abstractspecification
Interfacedesign
Componentdesign
Datastructuredesign
Algorithmdesign
Systemarchitecture
Softwarespecification
Interfacespecification
Componentspecification
Datastructure
specification
Algorithmspecification
Requirementsspecification
Design activities
Design products
Fasi di un processo di design
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
10
• 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 delproblema
• Algorithm design Progettazione degli algoritmi per le funzioni del problema
Fasi di un processo di design
6
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
11
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à delprogetto
• Caratteristiche di qualità sono ugualmente applicabili aprogettazione function-oriented e object-oriented
Design quality
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
12
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
Design goals
7
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
13
Semplici esempi:
• Cambiamenti negli algoritmi
da bubblesort a quicksort
• Cambiamenti nelle strutture dati17% 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
Design for change
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
14
Pensare ad un componente e a tutte le sue varianti come unmembro 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., facilitiespossono essere gratis o meno)
Component family
8
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
15
A 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 -La Progettazione
16
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..
9
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
17
Decomposizione
• Decomporre il Sistema in sottosistemi, gestibili separatamente, per dominarne la complessità
• P= problema, C=complessità di P, E=sforzo per la risoluzione di PDati 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 il problema della comunicazione fra le varie parti, il che aggiunge complessità per l’interfacciamento. Numero di moduli
Costo Costo totaleCostointerfacciamento
Costo modulo
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
18
Raffinamento
• Gli elementi individuati con la decomposizione sono ulteriormente decomposti per passi successivi
• …. generazione di strutture gerarchiche
10
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
19
Astrazione
• 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 -La Progettazione
20
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
11
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
21
Information 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 -La Progettazione
22
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;
12
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
23
Modulo
• 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 -La Progettazione
24
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)
13
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
25
Decomposizione 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 -La Progettazione
26
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
-
+
14
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
27
Spettro 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 -La Progettazione
28
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
15
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
29
RICONOSCIMENTO DELLA COESIONE
N e l m o d u l o s i r i c o n o s c e u n a f u n z i o n ed e l d o m i n i o d i a p p l i c a z i o n e ?
n o s i
c o s a l e g a l ea t t i v i t à n e l m o d u l o
E ’ i m p o r t a n t e E ’ i m p o r t a n t e L e a t t i v i t àl a s e q u e n z a ? l a s e q u e n z a ? a p p a r t e n g o n o
a l l a s t e s s ac a t e g o r i a ?
n o s i n o s i n o s i
f u n z i o n a l e
N e s s u n o d e i d u e
F l u s s o d e i d a t i
F l u s s o d i c o n t r o l l o
C a s u a l e L o g i c oT e m p o r a l e P r o c e d u r a l e C o m u n i c a z i o n . S e q u e n z .
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
30
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)
16
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
31
Spettro 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 -La Progettazione
32
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
17
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
33
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 .
Relazioni fra moduli
A
B C
FED
costituzione di gerarchie (relazione USA priva di cicli)
Livelli : livello 0 per moduli senza archi 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 livello minore.
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
34
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.
Relazione USA
18
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
35
deriva dalla scomposizione, raffinamento, di moduli in sottomoduli; dà luogo ad una gerarchia, rappresentabile graficamente.
Relazione COMPONENTE_DI
A
A1 A2 A3
COMPONENTE_DI
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
36
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
19
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
37
Se 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:
A
A1 A2 A3
COMPONENTE_DI
A1 A2 A3
F B C
B
B1 B2
B1
D E
B2
F
C
C1 C2
USA
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
38
M
B
B1
D E
B2
F
C
C1 C2A
B C
FED
B1 B2 C1 C2
Notazioni grafiche del Design (GDN)
esprimono la struttura gerarchica e le relazioni tra i moduli
20
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
39
module <nome_modulo> uses <lista_nomi_moduli_usati> exports <lista_risorse_esportate>
--eventuali commenti sulle risorse esportate--vincoli su come possono essere usate dai clienti;
implementationis composed of <lista_ nomi_moduli_componenti>--descrizione ad alto livello di astrazione della implementazione
end <nome_modulo>
Una Notazione Testuale dei Moduli (TDN)
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
40
Ymodule
X
Z
A B C
R
T
module
module
Risorse richieste da moduli client
Esempio
21
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
41
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
implementationis composed of R, T--se necessario, fornire commenti su come realizzato--nell’es., come è scomposto in moduli di più basso livello;
end X
Esempio
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
42
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
Esempio
22
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
43
Il 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 -La Progettazione
44
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
23
Anna Rita Fasolino- Ingegneria del Software -La Progettazione
45
1. Ambito1.1 Obiettivi del sistema1.2 Requisiti principali del Sw1.3 Vincoli e limitazioni progettuali
2. Progetto dei dati2.1 Oggetti-dato e strutture dati2.2 File e Basi di dati
2.2.1 Struttura dei file esterni2.2.2 Struttutra logica2.2.2.1 Descrizione dei record logici2.2.2.2 Metodo di accesso
2.3 Riferimenti incrociati file-dati
3. Progetto architetturalerappresentazione grafica della struttura3.1 Descrizione della struttura modulare3.2 Descrizione del flusso dati e di controllo
4. Progetto delle interfacce4.1 Specifica dell’interfaccia uomo -macchina4.2 Regole di progettazione dell’interfaccia uomo -macchina4.3 Progetto delle interfacce esterne
4.3.1 Interfacce verso i dati esterni4.3.2 Interfacce verso sistemi e dispositivi esterni
4.4 Regole di progettazione dell’interfacce esterne
5. Progetto proceduralePer ogni modulo
5.1 Descrizione informale5.2 Descrizione delle interfacce5.3 Descrizione del linguaggio del progetto5.4 Moduli utilizzati5.5 Descrizione strutture dati interne5.6 Descrizione del progetto di dettaglio5.7 Commenti/restrizioni/limitazioni
rappresentazione in TDN6. Indice dei requisiti (con riferimenti incrociati)
6.1 preparazione al testing6.1.1 Linee guida6.1.2 Strategia di integrazione
7. Considerazioni specifiche8. Note particolari9. Appendici
La documentazione di Progetto