Ingegneria del software

12.4 IDENTIFICARE GLI OBIETTIVI DI DESIGN

Identificare gli obiettivi del system design é il primo passo. Molti dei desing goal possono essere ricavati dai requisiti

non funzionali o dal dominio di applicazione, altri sono forniti dal cliente, altri sono derivati da aspetti di management. È

importante formalizzare esplicitamente poiché ogni importante decisione di design deve essere fatta seguendo lo stesso in-

sieme di criteri.

12.4 CRITERI DI DESIGN

Possiamo selezionare gli obiettivi di design da una lunga lista di qualità desiderabili. I criteri sono organizzati in

cinque gruppi: performance, dependability, costi, manutenzione, criteri dell'utente finale.

12.4.1 CRITERI DI PERFORMANCE

I criteri di performance includono i requisiti imposti sul sistema in termini di spazio e velocità. Tra i criteri abbiamo:

tempo di risposta, con quali tempi una richiesta di un utente deve essere soddisfatta dopo che la richiesta è stata immessa;

throughput, quali task il sistema deve portare a compimento in un periodo di tempo prefissato; memoria, quanto spazio è

richiesto al sistema per funzionare.

12.4.2 CRITERI DI DEPENDABILITY

Questi criteri definiscono quanto sforzo deve essere speso per minimizzare i crash di sistema e le loro conseguenze.

Tra i criteri di dependability troviamo: robustezza, che è la capacità di sopravvivere ad input non validi immessi dall'utente;

affidabilità, differenza tra comportamento specificato e osservato; disponibilità, percentuale di tempo in cui il sistema può

essere utilizzato per compiere le normali attività; tolleranza agli errori, capacità di operare sotto condizioni di errore; security,

capacità di resistere ad attacchi di malintenzionati; safety, capacità di evitare di danneggiare vite umane, anche in presenza

di errori e di fallimenti.

12.4.3 CRITERI DI COSTO

Tra questi criteri includiamo i costi per sviluppare sistema, per metterlo in funzione e per amministrarlo. Quando il

sistema sostituisce un sistema vecchio, è necessario considerare il costo per assicurare la compatibilità con il vecchio o per

transitare verso il nuovo sistema. Tra i criteri di costo troviamo: Costi di sviluppo, costo di sviluppo del sistema iniziale; costi

di deployment, costo relativo all'installazione del sistema e training degli utenti; costi di aggiornamento, costo di convertire i

dati da sistema precedente, questo criterio viene applicato quando nei requisiti è richiesta la compatibilità con il sistema

precedente; costo di manutenzione, costo richiesto per correggere errori software o hardware; costi di amministrazione, costo

richiesto per amministrare il sistema.

12.4.4 CRITERI DI MANUTENZIONE Pag. 29 a 57

Attraverso i costi di manutenzione determiniamo quanto deve essere difficile modificare il sistema dopo il suo rila-

scio. Tra questi criteri troviamo: estensibilità, quando è facile aggiungere funzionalità o nuove classi al sistema; modificabi-

lità, quanto facilmente possono essere cambiate le funzionalità del sistema; adattabilità, quanto facilmente può essere portato

il sistema su differenti domini di applicazione; portabilità, quanto è facile portare il sistema su differenti piattaforme; leggi-

bilità, quanto è facile comprendere il sistema dalla lettura del codice; tracciabilità dei requisiti, quanto è facile mappare il

codice nei requisiti specifici.

12.4.5 CRITERI DELL’UTENTE FINALE

Questi criteri includono qualità che sono desiderabili dal punto di vista dell'utente, ma che non sono state coperte dei

requisiti di performance e dependability. Tra questi criteri troviamo: utilità, quanto bene dovrà il sistema a supportare il

lavoro dell'utente; usabilità, quanto dovrà essere facile per l'utente l'utilizzo del sistema.

12.5 DESIGN TRADE-OFF

Quando definiamo gli obiettivi di design, spesso solo un piccolo sottoinsieme di questi criteri può essere tenuto in

considerazione. Gli sviluppatori devono dare delle priorità agli obiettivi di design, tenendo anche conto di aspetti manage-

riali, quali il rispetto dello schedule e del budget. Tipici design trade-off sono: funzionalità vs usabilità, costi vs robustezza,

efficienza vs portabilità, sviluppo rapido vs funzionalità, costi vs riusabilità, compatibilità backward vs leggibilità.

12.6 CONCETTI DEL SYSTEM DESIGN

Nel system design descriviamo in dettaglio il concetto di sottosistema e come è collegato alle classi e le interfacce

dei sottosistemi poiché i sottosistemi forniscono dei servizi agli altri sottosistemi. Un servizio è un insieme di operazioni

correlate che condividono uno scopo comune. I sottosistemi hanno due proprietà: coupling, misura la dipendenza fra due

sottosistemi, e la coesione, misura la dipendenza fra classi entro un sottosistema. Esaminiamo due tecniche per collegare fra

loro due sottosistemi: layering, che consente a un sistema di essere organizzato come una gerarchia di sottosistemi in cui

ognuno fornisce servizi al sistema di livello superiore utilizzando i servizi forniti dal sistema al livello inferiore, partitio-

ning, che organizza sottosistemi come peer che mutuamente forniscono differenti servizi agli altri sottosistemi.

12.6.1 I SOTTOSISTEMI

Per ridurre la complessità della soluzione, decomponiamo in sistemi in parti più piccole chiamate sottosistemi. Un

sottosistema è costituito da un certo numero di classi del dominio della soluzione e tipicamente corrisponde alla parte di

lavoro che può essere svolta da un singolo sviluppatore o da un team di sviluppatori. Decomponendo il sistema in sottosi-

stemi relativamente indipendenti, i film di progetto possono lavorare sui sottosistemi individuali con un minimo overhead

di comunicazione. Nel caso dei sottosistemi complessi, applichiamo ulteriormente questo principio e li decomponiamo in

sottosistemi più semplici. La definizione di sottosistema ci viene da UML e cioè è una collezione di classi, associazioni,

operazioni e vincoli che sono correlati. Java fornisce i package che sono costrutti per modellare i sottosistemi.

Un sottosistema è caratterizzato dai servizi che fornisce gli altri sottosistemi. L'insieme di operazioni di un sottosi-

stema che sono disponibili agli altri sottosistemi formano l'interfaccia del sottosistema ed include il nome delle operazioni,

parametri e il loro tipo e il loro valori di ritorno. Il system design si focalizza sulla definizione dei servizi forniti da ogni

sottosistema in termini di operazioni, loro parametri, loro comportamento ad alto livello. L'Object Design invece si foca-

lizza sulle operazioni.

La definizione dei sottosistemi in termini di servizi aiuta a concentrarci sull'interfaccia piuttosto che sulla implemen-

tazione. Quando si descrive un’interfaccia si dovrebbero cercare di ridurre info sull'implementazione, ciò consente di ridurre

l'impatto dei cambiamenti di un sottosistema sugli altri.

12.7 COESIONE E ACCOPPIAMENTO

Attraverso il system design vogliamo classi altamente coese dentro ogni sottosistema e sottosistemi bassamente ac-

coppiati. Questo ha un impatto sulla comprensibilità, manutenibilità, la facilità con cui i team possono lavorare contempora-

neamente su sottosistemi, l'integrazione di sottosistemi, ecc.

L'accoppiamento è una misura di come due classi o sottosistemi sono connessi, invece la coesione è una misura di

come una classe o sottosistema è legato insieme. L'obiettivo dell'accoppiamento è ridurre la complessità. Se due sistemi sono

scarsamente accoppiati significa che sono relativamente indipendenti e quindi modifiche su uno dei sottosistemi avranno

probabilmente pochi infatti sull'altro. Se due sistemi sono fortemente accoppiati una modifica su di un sottosistema proba-

bilmente avrà impatti sull'altro. Quindi è desiderabile avere uno scarso accoppiamento tra i sottosistemi. Con l'obiettivo di

ridurre l'accoppiamento si rischia di aggiungere livelli di astrazione che consumano tempo di sviluppo e tempo di elabora-

zione. Un accoppiamento estremamente basso va perseguito solo se ci sono elevate probabilità che qualche sottosistema

cambi. Pag. 30 a 57

La coesione tra classi significa che le operazioni costituiscono un "intero" funzionale, gli attributi e le strutture dati

descrivono gli stati ben definiti che sono modificati dalle operazioni e le operazioni si usano a vicenda. La coesione tra

sottosistemi significa che le classi dei sottosistemi sono concettualmente correlate, le relazioni strutturali tra classi sono fon-

damentalmente generalizzazioni e aggregazioni e le operazioni chiavi sono eseguite all'interno dei sottosistemi.

La coesione misura le dipendenze entro un sottosistema. Un'alta coesione significa che le classi di un sottosistema

realizzano compiti simili e sono collegate le une alle altre. Una bassa coesione invece significa che il sistema contiene un

certo numero di oggetti non correlati. Aumentando la pressione aumenta il numero di sottosistemi, invece se aumenta il

numero di interfacce aumenta l'accoppiamento. Gli sviluppatori possono trattare ad ogni livello di astrazione un numero di

concetti pari a 7±2, significa che qualcosa non va se ci sono più di 9 sottosistemi ad un livello di astrazione è un sottosistema

fornisce più di 9 servizi.

12.8 LAYERS E PARTIZIONI

Un sistema grande è di solito decomposto in sottosistemi usando layer e partizioni. Una decomposizione gerarchica

di un sistema consiste di un insieme ordinato di layer (strati). Un layer è un raggruppamento di sottosistemi che forniscono

servizi correlati, eventualmente realizzati utilizzando servizi di altri layer. Un layer può dipendere solo layer di livello più

basso mentre non ha la conoscenza dei layer dei livelli più alti. Attraverso un'architettura chiusa, ogni layer può accedere

solo a leggere immediatamente sotto di esso, mentre attraverso un'architettura aperta, un layer può anche accedere ai layer

di livello più basso. Anche in questo caso non ci dovranno essere più di 7 più o meno due sottosistemi per layer, poiché più

sottosistemi accrescono la coesione ma anche la complessità; non ci dovranno essere neanche più di 5 più o meno 2 layer.

Un sistema basato sul layer è gerarchico e ciò riduce la complessità. Le architetture chiuse sono più portabili mentre

le architetture aperte sono più efficienti. Se un sottosistema è un layer spesso è chiamato macchina virtuale. Un sistema

dovrebbe essere sviluppato da un insieme di macchine virtuali, ognuna costruita in termini di quelle al di sotto di essa. Una

macchina virtuale è un'astrazione che fornisce un insieme di attributi operazioni, è un sottosistema connesso a macchine

virtuali di livello pi&u