La Progettazione del Software

Transcript

1 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 1 IEEE Std La fase di Progettazione 2 1

2 3 4 2

3 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

4 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

5 Fasi di un processo di design Requirements specification Design activities Architectural design Abstract specification Interface design Component design Data structure design Algorithm design System architecture Software specification Interface specification Component specification Data structure specification Algorithm specification Design products 9 Architectural design Fasi di un processo di 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

6 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

7 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 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à: Component family molte funzionalità sono simili, alcune sono diverse (es., facilities possono essere gratis o meno) 14 7

8 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

9 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 il problema della comunicazione fra le varie parti, il che aggiunge complessità per l interfacciamento. Costo 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

10 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

11 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

12 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

13 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

14 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

15 RICONOSCIMENTO DELLA COESIONE Nel modulo si riconosce una funzione del dominio di applicazione? no si cosa lega le attività nel modulo funzionale Flusso di controllo Nessuno dei due Flusso dei dati E importante E importante Le attività la sequenza? la sequenza? appartengono alla stessa categoria? no si no si no si Temporale Procedurale Comunicazion. Sequenz. Casuale 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

16 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

17 Relazioni fra moduli Relazione USA: due moduli m i ed m j sono in tale relazione (m i USA m j ) se, affinché il modulo m i risulti corretto rispetto alle sue specifiche, è necessaria anche la corretta esecuzione di m j : ovvero m i necessita di qualche cosa implementata in m j. A costituzione di gerarchie (relazione USA priva di cicli) D B E F C 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. m i ha un astrazione maggiore di m j se ha un livello minore. 33 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: Relazione USA 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

18 Relazione COMPONENTE_DI deriva dalla scomposizione, raffinamento, di moduli in sottomoduli; dà luogo ad una gerarchia, rappresentabile graficamente. A A 1 A 2 A 3 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

19 Se un modulo m i 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 A USA A 1 A 2 A 3 A 1 A 2 A 3 F B C B C B 1 B 2 B 1 B 2 C 1 C 2 D E F 37 Notazioni grafiche del Design (GDN) M esprimono la struttura gerarchica e le relazioni tra i moduli B C B 1 B 2 C 1 C 2 A D E F B B1 B2 C1 C2 C D E F 38 19

20 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> --descrizionead alto livello di astrazione della implementazione end <nome_modulo> 39 Esempio moduley modulex R T modulez A B C Risorse richieste da moduli client 40 20

21 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 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 42 21

22 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 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

23 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 Struttura dei file esterni Struttutra logica Descrizione dei record logici 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 uomomacchina 4.3 Progetto delle interfacce esterne Interfacce verso i dati esterni 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 Linee guida Strategia di integrazione 7. Considerazioni specifiche 8. Note particolari 9. Appendici 45 23