Scopo
|
Considerazione dei nuovi elementi del modello nell'organizzazione del modello di progettazione.
Nuovo bilanciamento della struttura del modello di progettazione dove necessario.
|
Aggiungendo nuovi elementi al modello di progettazione si rende spesso necessario un suo reimpacchettamento. Si
ottengono così diversi risultati: riduzione delle dipendenze tra pacchetti ed il miglioramento della loro coesione nel
modello di progettazione. L'intento principale e quello di consentire a pacchetti (e sottosistemi) diversi di essere
progettati in modo indipendente l'uno dall'altro, da persone diverse del team. Mentre la completa indipendenza è
praticamente impossibile da raggiungere, la diminuzione delle dipendenze tra i pacchetti tende semplificare lo sviluppo
di sistemi grandi e complessi.
Un struttura di modello 'piatta' (dove tutti i pacchetti ed i sottosistemi si trovano allo stesso livello concettuale
nel sistema) è adatta a piccoli sistemi; in sistemi più grandi si necessita di un ulteriore strutturazione definita
'strutturazione a livelli' (consultare Linee guida del prodotto
di lavoro: Strutturazione a livelli). Le regole di strutturazione a livelli definiscono le restrizioni presenti
sulle relazioni consentite tra determinati pacchetti. Tali regole riconoscono che determinate dipendenze non devono
esistere: la funzionalità dell'applicazione non deve dipendere in modo diretto dal sistema operativo o dai servizi del
sistema di finestre, dove esserci un livello intermedio contenente servizi di finestre e del sistema operativo logici
che isoli la funzionalità dell'applicazione dalle modifiche nel servizi di implementazione di basso livello. La
strutturazione a livelli consente di ridurre l'impatto delle modifiche: l'inserimento di regole che restringono le
dipendenze tra i pacchetti ed i sottosistemi rende il sistema più solido. Gli si consente di sopportare le modifiche.
L'aggiunta di nuovi elementi del modello al sistema potrebbe rendere i pacchetti esistenti troppo grandi per essere
gestiti da un unico team: si deve quindi dividerlo in più pacchetti con un'alta coesione interna, ma con basse
dipendenze tra i pacchetti. quest'operazione potrebbe essere complicata, alcuni elementi potrebbero essere difficili da
posizionare in un determinato pacchetto poiché essi potrebbero essere utilizzati da elementi di diversi pacchetti.
Esistono due diverse soluzioni: dividere l'elemento in diversi oggetti, uno in ciascun pacchetto (questo è possibile in
elementi che abbiano diverse 'personalità', o in insiemi con responsabilità in qualche modo disgiunte), oppure spostare
l'elemento in un pacchetto di un livello sottostante, da cui tutti gli elementi di livello più alto dipendano in modo
uguale.
Quanto più aumenta la complessità del sistema tanti più livelli saranno necessari per ottenere una struttura
comprensibile e gestibile. Tuttavia sarà difficile avere strutture con più di 7-10 livelli, anche nei sistemi più
grandi, poiché la complessità aumenta e diminuisce in proporzione al numero di livelli.
Di seguito viene mostrata un esempio di strutturazione a livelli che comprende livelli middleware e di software del
sistema:
La strutturazione a livelli di un pacchetto di esempio di un'applicazione basata su Java/Web. Nota: le dipendenze dal
pacchetto TCP/IP non verrebbero di solito modellate in modo esplicito, siccome l'utilizzo dei servizi TCP/IP è
incapsulato in Java VM, java.rmi e nel browser web. Sono descritte solo per esempio.
Assegnazione delle responsabilità per i sottosistemi ed i livelli ai singoli o ai team. Ciascun pacchetto o
sottosistema deve essere di responsabilità di una singola persona (se il suo ambito è piccolo) o di un team (se il suo
ambito è più vasto).
|