La strutturazione a livelli offre i seguentu vantaggi:
-
I livelli aiutano a portare attributi di qualità di modificabilità e portabilità in un sistema IT. Una modifica ad
un livello inferiore che non ne influenza l'interfaccia non richiede nessuna modifica ad un livello superiore. Ad
esempio, tutti i server di applicazione conformi a J2EE™ che rispettano lo standar J2EE™ potrebbero essere
liberamente sostituiti con la modifica al software di livello di applicazione. Una modifica ad un livello inferiore
che non influenza le funzioni che richiede dagi livelli inferiori non influenzerà nessun livello inferiore. In
generale, le modifiche ad un sistema software strutturato in livelli che non influenza nessuna interfaccia sono
confinate ad un livello singolo.
-
I livelli sono parte di un ruolo blueprint che l'architettura interpreta per costruire il sistema. Conoscendo i
livelli nei quali il software risiede, gli sviluppatori consocono su quali servizi si possono affidare
nell'ambiente di codifica. I livelli potrebbero definire le assegnazioni del lavoro per i team di sviluppo (sebbene
non sempre).
-
I livelli sono parte di un ruolo di comunicazione giocato dall'architettura. In un sistema ampio, il numero di
dipendenze tra i moduli si espande in modo rapido. L'organizzazione del software in livelli con le interfacce è uno
strumento importante per gestire la complessità e comunicare la struttura agli sviluppatori.
-
I livelli aiutano con il ruolo di analisi interpretato dall'architettura. Questi possono essere utilizzati per
l'analisi dell'impatto delle modifiche al progetto.
La strutturazione in livelli può essere streatta e non stretta. Uno schema di strutturazione in livelli stretto
significa che i componenti possono solo utilizzare i componente nello stesso livello o livelli immediatamente al di
sotto di questi. Uno schema di suddivisione in livelli significa che i componenti possono utilizzare i componenti nello
stetto o in qualsiasi livello inferiore. Notare che come regola generale, tuttavia, ai componenti non dovrebbe
essere consentito utilizzare i componenti nei livelli superiori. Se i componenti hanno dipendenze sui componenti nei
livelli superiori, allora diventa difficile sostituire i componenti del livello superiore senza dover modificare i
componenti del livello inferiore. Per ulteriori informazioni, incluse le tecniche per il modellamento dei
livelli, consultare Concetto: Partizionamento della soluzione.
Un punto importante è notare che i livelli software non sono uguali ai livelli. L'assegnazione alle macchine in un
ambiente distribuito, il flusso di dati tra gli elementi e la presenza e l'utilizzo di canali di comunicazione, tutto
tende ad essere espresso in immagini in file che possono essere incomprensibili per i diagrammi di livello. I diagrammi
a file tendono a mostrare freccie a due punte che indicano una certa comunicazione bidirezionale. La comunicazione
bidirezionale (simmetrica) è una cattiva notizia in un diagramma a strati. Inoltre, l'assegnazione di un componente ad
una file si basa sul posizionamento delle regole considerate durante la definizione dell'architettura operativa ed è
definita dalle caratteristiche del livello di servizio richiesto del sistema. La differenza principale tra i diagrammi
di livello e le immagini in fila è che il primo non ha alcuna nozione del posizionamento mentre le altre ovviamente ce
l'hanno.
Regola pratica a livelli
-
Tutti i componenti che forniscono una funzionalità del business indipendente dall'applicazione può andare in un
livello. Le funzioni del business indiepndenti dall'applicazione sono la "gestione del cliente" e la "gestione del
prodotto" che si applica ad un intervallo di diverse applicazioni.
-
Tutti i componenti che forniscono funzioni tecniche, come la gestione dell'errore, l'autenticazione, la
registrazione ed il controllo possono andare in un altro livello. Questi componenti sono indipendenti dal business
e dall'applicazione. In alcuni casi, la prossimità di componenti tecnici e funzionali può richiedere che vengano
posti in un livello comune. Queste sono decisioni strutturali e devono essere documentate come tali.
-
I componenti middleware come l'accodamento dei messaggi ed il software DBMS relazionale possono andare in un altro
livello. Questi vengono denominati "Fabrica".
Esempio
La seguente è una vista a livelli di una SOA che mostra i livelli tipici (e soprattutto consigliati) per gli elementi
diversi presenti in una soluzione.
Ora, in questo schema a livelli, è consigliabile semplicemente relizzare come i componenti risiedono, i componenti
importanti vengono posti per l'esempio Noleggi auto nel livello dei componenti del servizio, come di seguito
illustrato. Notare che si desidera impiegare i livelli stretti nel modello e così viene utilizzata la
composizione UML per contenere i componenti nel livello del componente del servizio ed esporre solo la funzione dei
componenti del servizio utilizzando porte delegate dove la porta fornisce la stessa interfaccia del componente del
servizio stesso.
|