La Progettazione del Softwarewpage.unina.it/fasolino/is/materiale/6-progetto-new.pdf4 Anna Rita Fasolino - Ingegneria del Software - La Progettazione 7 Livelli di progettazione •

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


2

La fase di Progettazione

IEEE Std 610.12-1990

2


3


4

3


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


6

Requisiti Software

High Level Design

Low Level Design

4


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


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


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


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


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


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


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


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


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


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


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


18

Raffinamento

• Gli elementi individuati con la decomposizione sono ulteriormente decomposti per passi successivi

• …. generazione di strutture gerarchiche

10


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


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


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.


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


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)


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


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


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


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à


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


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 .


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


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.


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


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.


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


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


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


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


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


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)


40

Ymodule

X

Z

A B C

R

T

module

module

Risorse richieste da moduli client

Esempio

21


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


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


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


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


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

Documents

La Progettazione del Softwarewpage.unina.it/fasolino/is/materiale/6-progetto-new.pdf4 Anna Rita Fasolino - Ingegneria del Software - La Progettazione 7 Livelli di progettazione •