La Progettazione del Software

Transcript

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
1
La fase di Progettazione
IEEE Std 610.12-1990
2
1
3
4
2
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
5
Requisiti Software
Low Level
Design
High Level Design
6
3
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
7
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à
8
4
Fasi di un processo di design
Requirements
specification
Design acti
vities
Architectur
al
design
Abstract
specification
Interface
design
Component
design
Data
structur
e
design
Algorithm
design
System
architectur
e
Softwar e
specification
Interface
specification
Component
specification
Data
structur
e
specification
Algorithm
specification
Design pr
oducts
9
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
10
5
Design 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
11
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
12
6
Design 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
13
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)
14
7
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
15
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..
16
8
Decomposizione
•
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
il problema della
comunicazione fra le varie
parti, il che aggiunge
complessità per
l’interfacciamento.
Costo totale
Costo
interfacciamento
Costo modulo
Numero di moduli
17
Raffinamento
• Gli elementi individuati con la decomposizione sono
ulteriormente decomposti per passi successivi
• …. generazione di strutture gerarchiche
18
9
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
19
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
20
10
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.
21
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;
22
11
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)
23
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)
24
12
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 interconnessioni 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
25
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
-
+
26
13
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à
27
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
28
14
RICONOSCIMENTO DELLA COESIONE
Nel modulo si riconosce una funzione
del dominio di applicazione ?
no
s i
cosa lega le
attività nel modulo
funzionale
N e s s u n o d e i d u e
Flusso di controllo
Flusso dei dati
E’ importante
la sequenza ?
n o
Temporale
E’ importante
la sequenza ?
si
no
Procedurale
C o m u n i c a z i o n .
Le attività
appartengono
alla stessa
categoria ?
si
Sequenz.
no
Casuale
si
Logico
29
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)
30
15
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.
31
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
32
16
Relazioni 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 .
costituzione di gerarchie (relazione USA
priva di cicli)
A
B
D
C
E
F
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.
33
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.
34
17
Relazione COMPONENTE_DI
deriva dalla scomposizione, raffinamento, di moduli in sottomoduli;
dà luogo ad una gerarchia, rappresentabile graficamente.
A
A1
A2
A3
COMPONENTE_DI
35
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
36
18
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:
COMPONENTE_DI
USA
A
A1
A2
A3
B
B1
A1
A2
A3
F
B
C
C
B2
C1
B1
C2
D
B2
F
E
37
Notazioni grafiche del Design (GDN)
esprimono la struttura gerarchica e
le relazioni tra i moduli
M
B
B1
D
C
B2
E
C1
A
C2
F
B
B1
D
C
B2
C1
E
C2
F
38
19
Una Notazione Testuale dei Moduli (TDN)
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;
implementation
is composed of <lista_ nomi_moduli_componenti>
--descrizione ad alto livello di astrazione della implementazione
end <nome_modulo>
39
Esempio
moduleY
module X
R
T
A
B
module Z
C
Risorse richieste da moduli client
40
20
Esempio
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
41
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
42
21
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
43
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
44
22
La documentazione di Progetto
1. Ambito
1.1 Obiettivi del sistema
1.2 Requisiti principali del Sw
1.3
Vincoli e limitazioni progettuali
2. Progetto dei dati
2.1 Oggetti-dato e strutture dati
2.2 File e Basi di dati
2.2.1 Struttura dei file esterni
2.2.2 Struttutra logica
2.2.2.1 Descrizione dei record logici
2.2.2.2 Metodo di accesso
2.3 Riferimenti incrociati file-dati
3. Progetto architetturale
rappresentazione grafica della struttura
3.1 Descrizione della struttura modulare
3.2 Descrizione del flusso dati e di controllo
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
5. Progetto procedurale
Per ogni modulo
5.1 Descrizione informale
5.2 Descrizione delle interfacce
5.3 Descrizione del linguaggio del progetto
5.4 Moduli utilizzati
5.5 Descrizione strutture dati interne
5.6 Descrizione del progetto di dettaglio
5.7 Commenti/restrizioni/limitazioni
rappresentazione in TDN
6. Indice dei requisiti (con riferimenti incrociati)
6.1 preparazione al testing
6.1.1 Linee guida
6.1.2 Strategia di integrazione
7. Considerazioni specifiche
8. Note particolari
9. Appendici
45
23

La Progettazione del Software

Transcript

Documenti analoghi

Scarica il modulo per l`istanza da inviare alla competente autorità

contratto Baliva - Istituto Comprensivo n.1 G.Mazzini

20100428Programma (20100428ProgrammaFesta)

Associazione Casa Rita - Suor Rita dello Spirito Santo

Entra a far parte di LIDL Italia

notice to graduating students pc

La tutela dei minori nel mondo virtuale

STAMPAGGIO AD INIEZIONE ASSISTITO DA GAS (GAIM)

Attività

Dott.ssa BERGHELLA Sonia Rita