Progettazione del Software 1 Progettazione del software • Riguarda tutte quelle attività che permettono di passare dalla raccolta ed elaborazione dei requisiti di un sistema software alla sua effettiva realizzazione • Ponte tra la fase di specifica e la fase di codifica • Durante la fase di progettazione si decidono le modalità di passaggio da "che cosa" deve essere realizzato (specifica) a "come" la realizzazione deve avere luogo • La complessità della progettazione viene "ridotta" suddividendo il sistema complessivo in più sottosistemi • Vantaggi: • complessità delle singole parti minore della complessità totale originaria; • i sottosistemi ottenuti possono essere realizzati ed analizzati da gruppi diversi di programmatori in modo il più possibile indipendente
48
Embed
Progettazione del software - LIA · Progettazione del Software 2 • Due esigenze contrastanti: • progetto risultantesufficientemente astratto per poter essere agevolmente confrontato
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Progettazione del Software
1
Progettazione del software
• Riguarda tutte quelle attività che permettono dipassare dalla raccolta ed elaborazione dei requisiti diun sistema software alla sua effettiva realizzazione
• Ponte tra la fase di specifica e la fase di codifica
• Durante la fase di progettazione si decidono lemodalità di passaggio da "che cosa" deve essererealizzato (specifica) a "come" la realizzazione deveavere luogo
• La complessità della progettazione viene "ridotta"suddividendo il sistema complessivo in piùsottosistemi
• Vantaggi:
• complessità delle singole parti minore dellacomplessità totale originaria;
• i sottosistemi ottenuti possono essere realizzati edanalizzati da gruppi diversi di programmatori inmodo il più possibile indipendente
Progettazione del Software
2
• Due esigenze contrastanti:
• progetto risultante sufficientemente astratto perpoter essere agevolmente confrontato con lespecifiche da cui viene derivato
• progetto sufficientemente dettagliato in modotale che la codifica possa avvenire senza ulteriorinecessità di chiarire le operazioni che devonoessere realizzate
• A seconda della tecnica impiegata per laprogettazione, la realizzazione del sistema puòrisultare più o meno naturale ed immediata
Ad es., progettazione orientata a oggetti
+ realizzazione in un linguaggio a oggetti
• Il progetto di un sistema software non si ottiene intempi brevi ne` in un solo passo
• Sottosistemi individuati troppo complessi per essererealizzati direttamente: iterazione della suddivisionefin dove necessario
Progettazione del Software
3
Iterazione del metodo
SPECIFICA
Progetto1
Progetto2
ProgettoN
CODIFICA
Inco
ngru
enze
ne
lle s
peci
fich
e
…
• Non esiste un criterio che permetta di individuare concertezza fino a dove sia necessario spingere il livellodi dettaglio
• Regole empiriche basate sulla dimensione deisottosistemi
Progettazione del Software
4
• Non esiste un metodo generale per la progettazionedel software
• Tipologie di software (software sequenziale,concorrente ed in tempo reale)
• In fase di progettazione vengono fissate le direttivedi sviluppo del software, le quali costituiscono unriferimento che il più delle volte risulta particolarmentevincolante per le attività successive (scelte diprogetto)
• Ad una stessa specifica possono corrispondere piùprogetti, ossia più metodi di soluzione diversi
• Le scelte di progetto devono poter cambiare inrisposta a mutate esigenze di vario tipo senza che perquesto tutto il progetto e perciò tutto il softwareprodotto debba essere modificato radicalmente
• Scelte di progetto espresse e realizzate in modo che ilprogetto ne risulti trasparente, ossia suffi-cientementeindipendente
• Il progetto di un sistema software è perciò un'attivitàaltamente creativa, che richiede un insieme di abilitàa coloro che vi sono preposti
Progettazione del Software
5
Requisiti per il progettista
• Profonda conoscenza di tutto ciò che riguarda ilprocesso di sviluppo del software
• Capacità di saper anticipare i cambiamenti (modificheeffettive in porzioni limitate e ben identificate delsistema software prodotto, senza che ne vengaintaccata la struttura complessiva)
• Notevole inventiva per riuscire a trovare unasoluzione progettuale accettabile anche in mancanzadi una metodologia che sia sufficientementeespressiva
• Buon grado di esperienza per poter individuare conmaggiore rapidità e sicurezza le soluzioni piùopportune (allocazione di risorse)
Progettazione del Software
6
Obiettivi della progettazione
• Produrre software con le caratteristiche di qualitàche sono state dettagliate nella fase di analisi especifica dei requisiti
• Ad esempio:
• affidabilità
• modificabilità
• comprensibilità
• riusabilità
• Obiettivi che si possono riassumere nelladiminuzione dei costi e tempi di produzione enell'aumento della qualità del software
• I costi maggiori riguardano la fase di manutenzionedel software
• Capacità di poter far fronte a modifiche da effettuaresenza che l'intera struttura dell'applicazione giàcostruita debba essere messa nuovamente indiscussione ed elaborata
• Saper anticipare il cambiamento durante laprogettazione: ciò si ha, secondo la dizione di Parnas,
Progettazione del Software
7
con la cosiddetta progettazione per il cambiamento(design for change)
Progettazione del Software
8
Affidabilita`
• Durante la progettazione viene effettuata una verificaapprofondita del fatto che le specifiche sianoeffettivamente dotate di tutte le necessariecaratteristiche di consistenza, completezza, etc.
• Con la suddivisione in sottosistemi del sistemacomplessivo, verifica dei sottosistemi
• Collegamenti tra sottosistemi semplici e regolari, percui anche i difetti nelle interrelazioni tra i sottosistemirisultano meno frequenti e di minore entità
Progettazione del Software
9
Modificabilita`
• Cambiamenti nel sistema di calcolo per cui il prodottoviene sviluppato
Macchine fisiche e sistemi operativi differenti, oppure anchesistemi per la gestione di basi di dati diversi, etc
• Evoluzione nel tempo delle specifiche dei requisiti
L'uso dell'applicazione mostra la possibilità o la necessità dimodificare le procedure impiegate
• Cambiamenti nel software per il miglioramento delleprestazioni
Modifica del linguaggio di programmazione scelto(inizialmente, costruzione del prototipo, anche inefficiente,ad esempio Smalltalk; poi realizzazione in C++)
Modifica degli algoritmi
Modifica delle strutture dati utilizzate
• Inadeguatezza della specifica dei requisiti
• Evoluzione per motivi di mercato
Progettazione del Software
10
Comprensibilità del progetto
• Un progetto comprensibile, con un'adeguatadocumentazione, può essere rivisto ed utilizzatoanche da persone che non hanno partecipatodirettamente alla sua stesura
• Aumenta le caratteristiche di affidabilità e dimodificabilità
Riusabilità
• Poter utilizzare un'applicazione od anche una suaparte all'interno di una nuova applicazione
• Sottosistemi costruiti in modo tale da poter essereriutilizzati
• Diminuzione dei costi e dei tempi di produzione
• La parte di software che viene riutilizzata dopo esserestata sottoposta a convalida e ad un periodo di usooperativo è più affidabile
• Costruire o comperare componenti software (make orbuy)?
Progettazione del Software
11
• Il riuso molto spesso si accompagna ad una modificadel software
Progettazione del Software
12
Criteri generali e metodologie:
moduli ed architettura
• Il termine modulo designa ciascuno dei sottosistemi incui il sistema complessivo viene suddiviso
• La progettazione di un sistema software riguardal'identificazione dei vari moduli e delle loro mutueinterrelazioni
• Modulo: sottoprogramma, ma anche un'unità a séstante
• Un modulo risulta quindi uno strumento perraggruppare tipi, strutture dati, sottoprogrammi etc
• Contiene e fornisce risorse e servizi computazionali
• La definizione di un modulo deve essere basata sudue fattori fondamentali:
• il grado di coesione del suo contenuto
• il grado di disaccoppiamento con il resto delsistema
Progettazione del Software
13
Moduli
• Coesione interna
Unità sostanzialmente omogenea e facilmentecomprensibile
Ciò che è contenuto in un modulo deve far riferimentoad un insieme di caratteristiche comuni
Maggior comprensibilità
Maggiore facilità nella realizzazione e nella modifica
• Grado di disaccoppiamento
Maggiore è il disaccoppiamento, tanto più si è riuscitia dominare la complessità del sistema totale
Progettazione del Software
14
Architettura del sistema
• Struttura del sistema complessivo
• Indica quali siano le interrelazioni tra i vari moduli
• Esistono più tipi di relazioni che possono interveniretra i moduli
• Relazioni tra moduli rappresentate in formamatematica o mediante grafi orientati
a
b
c
d
e
f g
Progettazione del Software
15
Relazione USA
• mi USA mj (definita staticamente)
• Affinché il modulo mi risulti corretto rispetto alle suespecifiche, è necessaria anche la corretta esecuzionedi mj
• Modulo mi cliente di servizi forniti dal modulo mj (disolito attraverso chiamata di procedure)
• Sia M = {mi | i=1,..,n}
USA = M ∞ M disaccoppiamento troppo basso
USA = Ø funzionalità comuni a più moduli,distribuite e replicate(scarsa coesione)
• Di solito si richiede che sia aciclica (gerarchia)
Progettazione del Software
16
Relazione COMPONENTE_DI
• Raffinamento progressivo dei moduli in sottomoduli(approccio top-down)
• Deve necessariamente essere costruita in modo taleda dar luogo ad un grafo orientato aciclico(gerarchia)
a
b c d
e f g
h
• Solo i moduli con grado di uscita 0 avrannoun'esistenza fisica effettiva nel sistema software finale
• La scomposizione così effettuata può servire a fini didocumentazione del progetto
Progettazione del Software
17
• Modulo mi scomposto in una famiglia di sottomodulim(i)
• Se mi USA mj, ridefinizione di vari collegamenti daimoduli di m(i) a mj
Esempio
a
b c
d e f
USES
Ciascuno dei moduli a, b ec viene raffinato in modulicomponenti
a
a 1 a 2 a 3
IS_COMPONENT_OF
b1 b2
b
IS_COMPONENT_OF
c1 c2
c
IS_COMPONENT_OF
Progettazione del Software
18
Legami dovuti alla relazione USA sui modulicomponenti:
a 1 a 2 a 3
f b c
USES
b1 b2
fd e
USES
Non è fornita la ridefinizione di USA dal momento cheil modulo c non era in tale relazione con alcun altromodulo, per cui non lo sono neanche c1 e c2
Progettazione del Software
19
Costruzione incrementale
• Metodologia particolarmente efficace quando siintenda sviluppare un prodotto software a partire daun prototipo
• Il primo prototipo realizza le funzionalità più importantiper dimostrare la fattibilità
• Aggiunta di funzionalità, oppure riscrittura dellefunzionalità già realizzate al fine di migliorarneefficienza e precisione
Differimento delle decisioni
• Le scelte di progetto devono essere effettuate soloquando si raggiunga una conoscenza necessaria esufficiente per operarle
• Attivita` condotta con l'ausilio del principio diinformation hiding
• Si limita l'entità degli inconvenienti derivanti da unadecisione non corretta al singolo modulo
Progettazione del Software
20
Information hiding
• Occorre stabilire quale sia il "contenuto" di ognimodulo e quali siano i "servizi" che esporta
• Ogni modulo deve presentare al suo esterno uninsieme di funzionalità che sia il più possibile stabile
• Il contenuto del modulo deve invece poter esseredeciso localmente al modulo
• Obiettivo finale della progettazione: definizione di uninsieme di moduli che devono essere vistidall'esterno come scatole nere, accessibili solotramite i servizi che mettono a disposizione
• Un modulo mette a disposizione degli altri moduli unainterfaccia
• Il contenuto del modulo prende il nome direalizzazione
Progettazione del Software
21
Cosa nascondere: scelte di progetto
• Algoritmo
Visibile all'esterno soltanto attraverso il nome dellafunzione (sottoprogramma, metodo) che lo realizza
Il modulo cliente non deve conoscere i dettagli delprocedimento scelto dal modulo servitore per larealizzazione di una funzionalità (maggioredisaccoppiamento)
• Struttura dati
La scelta della struttura dati deve essere anch'essatenuta nascosta ai fini di migliorare la modificabilità
Ad esempio, tabella come vettore, lista, file, etc.
• Politiche
Accessi a risorse condivise
La politica di gestione scelta deve essere del tuttoinvisibile all'esterno
Progettazione del Software
22
Architettura modulare: vantaggi
• Rapida prototipazione del sistema
• Definita l'architettura del sistema e specificate leinterfacce dei vari moduli, la realizzazione dei singolicomponenti può essere fatta senza curare in modoparticolare l'efficienza
• Il sistema può poi essere progressivamentemodificato con l'obiettivo di ingenerizzare larealizzazione dei requisiti
Progettazione del Software
23
Notazioni di progetto
• Anche la progettazione porta alla generazione di unoo più documenti che nel complesso costituiscono ilprogetto vero e proprio del software
• Lo scopo di tale documentazione è da un lato difornire un riferimento univoco per le successive fasi dicodifica e di verifica, e dall'altro di poter essereutilizzata per chiarire se durante la fase diprogettazione non si siano avuti errori od omissioninei riguardi di quanto stabilito durante la specifica
• Alla documentazione di progetto si fa riferimento nelcaso si debbano apportare modifiche di una qualcheentità al prodotto, purché queste non intacchino lespecifiche
• Notazioni di progetto formali (metodi algebrici) o piu`pragmatici
• Notazioni che fanno riferimento all'uso di opportunicostrutti di linguaggi di programmazione (testuali) eall'uso di raffigurazioni visive (grafiche)
Progettazione del Software
24
Esempio:
Textual Design Notation (TDN)
• Derivata dal linguaggio Ada
• Notazione (semi)formale per specificare un modulo
module M;-- commento in generale sul modulo M: ad esempio gestisce un elenco-- anagraficouses A, B, C;exports const Max = 7;
-- commento su Max: ad esempio è il numero massimo di personetype Vet = array [1 .. Max] of Persona;-- commento su Vet: è il tipo dell'elenco gestito da M-- Persona è un tipo esportato dal modulo Avar X: integer;-- commento sul significato di X: è il numero di persone presenti-- inoltre può essere precisato che la variabile non è inizializzata-- in Mprocedure Y(in Par1: Vet; inout Par2: integer; out Par3: real);-- commento sul significato di Y: è da notare che il parametro-- Par1 è-- in ingresso, Par2 in ingresso uscita e Par2 solo in uscita
implementation-- eventuali commenti su strategie e motivazioni dell'implementazione
composed of P, Q, R;end M;
Progettazione del Software
25
• L'interfaccia del modulo può essere vista comedivisa in sue sottosezioni: le importazioni e leesportazioni
• Il modulo M, tramite l'utilizzo della clausola uses,importa le risorse computazionali messe adisposizione dai moduli A, B e C
• Tramite l'utilizzo della clausola exports, il modulo Mesporta le risorse computazionali listate di seguito(tutto ciò che precede la parola chiaveimplementation)
• Nella parte di implementazione vengono descritti imoduli componenti M, ossia P, Q e R
• Insieme all'uso di una notazione testuale il progetto diun prodotto software può essere sviluppato conl'ausilio di un formalismo grafico
• Maggiore immediatezza nella rappresentazionegrafica
• Notazione basata su un grafo aciclico che descrive leinterrelazioni tra i moduli (relazioni USA eCOMPONENTE_DI)
• Ogni nodo del grafo rappresenta un modulo
• Ogni nodo è connesso agli altri nodi per il tramite diarchi orientati
• Un arco uscente da un modulo M e diretto verso unmodulo A rappresenta la relazione M USA A
Progettazione del Software
29
A B C
M
P R Q
Max
Vet
X
Y
• I nodi riportano la struttura interna dei moduli: i moduliP, Q e R sono componenti del modulo M
Progettazione del Software
30
• Struttura interna di M:
A B C
M
P R Q
Max
Vet
X
Y
Progettazione del Software
31
• Quando uno stesso modulo e` un componente di dueo più moduli:
(1) si rappresenta tale modulo come indipendente esi introducono archi diversi per le relazioni USA eCOMPONENTE_DI
Esempio
Si supponga che uno stesso modulo S siacomponente di un modulo M, che contiene anche unmodulo J, e di un modulo N, che contiene anche unmodulo K; il modulo N sia inoltre in relazione USA conil modulo M
S KJ
M N
USES IS_COMPONENT_OF
Progettazione del Software
32
(2) oppure si replica il modulo all'interno di tutti imoduli di cui è componente
M N
J KS S
Progettazione del Software
33
I moduli come astrazione sul controllo:Librerie
• Nei linguaggi di programmazione tradizionali permodulo si intende una prima forma di astrazioneeffettuata sul flusso di controllo
• Il concetto di modulo è identificato con il concetto disubroutine o procedura
• Una procedura può effettivamente nascondere unascelta di progetto riguardante l'algoritmo utilizzato
Ad esempio, per l'ordinamento di un vettore di elementi interisi hanno più algoritmi diversi per tale compito: bubblesort,shellsort, quicksort, etc.
• Il principio di information hiding puo` essere disattesoqualora compaiano effetti collaterali
• Le procedure in quanto astrazioni sul controllo sonoutilizzate come parti di alcune classi di moduli, cheprendono il nome di librerie (ad esempio, librerie difunzioni matematiche e grafiche)
Progettazione del Software
34
I moduli come Astrazioni di Dato
• Un'Astrazione di Dato (o Struttura Dati Astratta, ADS)è un modo di incapsulare un dato in unarappresentazione tale da regolamentarne l'accesso ela modifica
• Interfaccia dell'oggetto (operazioni) stabile anche inpresenza di modifiche alla struttura dati
Dati
Interfaccia
Corpo
Operazioni
• Risultati dell'attivazione di un'operazione su unoggetto dipendenti anche dal valore del dato (stato)
• L'astrazione sui dati può procedere in due direzionicomplementari:
- il passaggio da astrazioni di dato a tipi di datiastratti
- il passaggio da astrazioni/tipi di dato adastrazioni/tipi generici
Astrazioni di Dato
Tipi di dati astratti
Tipi di dati astratti
generici
Tipizzazione
Genericità
Astrazioni di Dato
generiche
Progettazione del Software
37
Tipi di dati astratti
• Un Tipo di dato Astratto (ADT) descrive la strutturainterna degli oggetti che fanno riferimento al tipo el'insieme di risorse che gli oggetti del tipo in esameesportano
• La struttura del dato risulta invisibile all'esterno
Def. Tipo di Dato
Interfaccia
Corpo
Id_tipoOperazioni
Progettazione del Software
38
Esempio TDN di un ADT:
module NumeriComplessi;
uses …
exports
type Complesso = ?;
function Somma(in Addendo1, Addendo2: Complesso): Complesso;
function Sottrazione(in Addendo1, Addendo2: Complesso): Complesso;
function Moltiplicazione(in Addendo1,Addendo2:Complesso):Complesso;
function Divisione(in Addendo1, Addendo2: Complesso): Complesso;
function ParteReale(in Numero: Complesso): Real;
function ParteImmaginaria(in Numero: Complesso): Real;
function Modulo(in Numero: Complesso): Real;
function Argomento(in Numero: Complesso): Real;
function Inizializzazione(in ParteReale,ParteIm: Complesso):Complesso;
…
end NumeriComplessi;
• Il modulo esporta il tipo Complesso, ma non rendevisibili in alcun modo i dettagli realizzativi
Progettazione del Software
39
Oggetti generici
• Spesso le modalità di manipolazione di un oggettoper così dire "composto" non dipendono dall'effettivanatura dei suoi "componenti"
• Ad esempio, tabella di interi o reali: le operazioni sonoindipendenti dal tipo dei dati
• Un oggetto generico è perciò, in un certo senso,parametrico rispetto ad un tipo (ad esempio, tipo deisuoi componenti)
Dati (<Tipo>)
Interfaccia(<Tipo>)
Corpo (<Tipo>)
Operazioni (<Tipo>)
• Rappresenta lo schema (in inglese template) da cuivengono ricavati gli oggetti (astrazioni di dato, inquesto caso)
Progettazione del Software
40
• Definizione di un'istanza specificando il parametrotipo
procedure Elimina (inout Insieme1: TipoInsieme; in Elemento: TipoElemento);
function Vuoto: TipoInsieme;
implementation
…
end InsiemeGenerico;
Progettazione del Software
45
Definizione di una istanza
• Per usare un ADT generico occorre istanziarlo
• Costruzione di un ADT specificando un tipo effettivo alposto del tipo generico
Def. Tipo di Dato (integer)
Interfaccia(integer)
Corpo
Operazioni (integer)
Id_tipo
(integer)
module InsiemeDiInteri is InsiemeGenerico(Integer);
• Sia le astrazioni di dato che i tipi di dato astrattopossono poi essere generici anche rispetto aprocedure
Progettazione del Software
46
Progettazione orientata agli oggetti
• Favorisce la riusabilità dei componenti, la loroaffidabilità ed un procedimento di sviluppoincrementale del prodotto software
• Alle caratteristiche di information hiding vieneaggiunta la possibilità di definire un modulo comespecializzazione di un altro modulo con l'aggiunta diulteriori proprietà
• Ulteriore relazione, EREDITA_DA, detta diereditarietà (anche IS_A)
• L'ereditarieta` consente di costruire un modulosoftware dato da un Parent (genitore) piu` un Modifier(modificatore):
Parent
Modifier
R = compose(P,M)
Progettazione del Software
47
Ereditarieta`
• M IS_A P
P
M
- P, modulo genitore
- M, modulo erede (o figlio)
• Il modulo M eredita perciò tutte le caratteristiche di P,ossia mette anch'esso a disposizione tutte le risorseesportate da P
• Alcune di tali risorse possono però essere ridefinite(overriding)
• Nel modulo erede possono essere definite ulterioririsorse esportate (raffinamento)
Progettazione del Software
48
Esempio:
• InsiemeOrdinatoDiInteri come una specializzazione diInsiemeDiInteri (aggiunge la funzione PrimoElemento)