La strutturazione a livelli fornisce un partizionamento logico dei sottosistemi in diversi insiemi, con determinate
regole, relative alle modalità di formazione delle relazioni tra livelli. Essa fornisce un modo per limitare le
dipendenze interne ai sottosistemi, con il risultato che il sistema è legato in modo non saldo e viene, quindi, gestito
più facilmente.
I criteri per i raggruppamento dei sottosistemi seguono pochi modelli:
-
Visibilità. I sottosistemi possono dipendere solo da sottosistemi nello stesso livello e nel successivo
livello inferiore.
-
Volatilità.
-
Nei livelli più elevati, inserire gli elementi che variano quando i requisiti dell'utente vengono
modificati.
-
Nei livelli meno elevati, inserire gli elementi che variano quando la piattaforma di implementazione
(hardware, lingua, sistema operativo, database, ecc.) cambia.
-
Tra i due livelli, inserire gli elementi generalmente applicabili entro vaste gamme di ambienti di
implementazione e di sistemi.
-
Aggiungere dei livelli quando ulteriori partizioni all'interno di tali ampie categorie consentono di
organizzare il modello.
-
Generalità. Gli elementi di un modello astratto tendono ad essere collocati nei livelli inferiori del
modello. Se specifici dell'implementazione, tendono a gravitare verso i livelli intermedi.
-
Numero di livelli.Per un sistema di piccole dimensioni, tre livelli sono sufficienti. Per un sistema
complesso sono sufficienti da 5 a 7 livelli. Per qualsiasi grado di complessità, si consiglia di visualizzare più
di 10 livelli, considerando che più è alto il numero di livelli e maggiore è il dubbio relativo al numero
effettivo. Di seguito sono riportate delle regole pratiche:
Num. di classi
|
Num. di livelli
|
0 - 10
|
Non è necessaria alcuna strutturazione a livelli
|
10 - 50
|
2 livelli
|
25 - 150
|
3 livelli
|
100 - 1000
|
4 livelli
|
I sottosistemi e i pacchetti all'interno di uno specifico livello dovrebbero dipendere solo dai sottosistemi
all'interno dello stesso livello e nel livello immediatamente inferiore. Un errore di limitazione delle dipendenze in
questo modo causa un degrado strutturale e rende il sistema fragile e difficile da gestire.
Le eccezioni comprendono i casi in cui i sottosistemi necessitano di un accesso diretto ai servizi di livello
inferiore; decidere con attenzione le modalità di gestione dei servizi primitivi necessari nel sistema, ad esempio la
stampa, l'invio di messaggi, ecc. Non ha senso limitare i messaggi ai livelli inferiori se la soluzione è implementare
in modo efficace i pass-through di chiamate nei livelli intermedi.
Nei livelli più elevati del sistema, un ulteriore partizionamento consentirebbe di organizzare il modello. Le seguenti
linee guide per il partizionamento presentano problematiche differenti da considerare:
-
Organizzazione dell'utente. E' possibile organizzare i sottosistemi lungo linee che rispecchino
l'organizzazione della funzionalità nell'organizzazione di business (ad esempio, il partizionamento avviene lungo
linee di dipartimento). Questo partizionamento spesso si verifica all'inizio della progettazione, perché un modello
aziendale esistente ha una struttura fortemente suddivisa in partizioni organizzate. Tale modello organizzativo,
generalmente, influenza solo i pochi livelli più elevati dei servizi specifici dell'applicazione e, spesso, cessa
di esistere con l'evoluzione della progettazione.
-
Il partizionamento lungo le linee organizzative dell'utente può essere un buon punto di partenza per il
modello.
-
La struttura dell'organizzazione dell'utente non è stabile per un lungo periodo di tempo (a causa della
riorganizzazione di business) e non è una buona base a lungo termine per il partizionamento del sistema.
L'organizzazione interna del sistema dovrebbe consentire l'evoluzione del sistema e la relativa gestione in
modo indipendente dall'organizzazione del business che supporta.
-
Aree di competenza e/o di skill. E' possibile organizzare i sottosistemi per suddividere le responsabilità
per parti del modello tra gruppi differenti all'interno dell'organizzazione di sviluppo. Generalmente, ciò si
verifica nei livelli inferiori e intermedi del sistema e rispecchia l'esigenza di specializzazione negli skill
durante lo sviluppo e il supporto di una tecnologia infrastrutturale complessa. Esempi di tali tecnologie
comprendono, tra le altre, la gestione di distribuzione e di rete, la gestione del database, della comunicazione e
il controllo dei processi. Il partizionamento lungo le linee di competenza può avvenire anche nei livelli
superiori, in cui è richiesta una competenza speciale nel dominio del problema per comprendere e supportare la
funzionalità di business chiave; tra gli esempi vanno annoverati la gestione delle chiamate di telecomunicazione,
lo scambio di azioni, l'elaborazione di domande d'indennizzo assicurativo e il controllo del traffico aereo.
-
Distribuzione del sistema. All'interno di qualsiasi livello del sistema, i livelli possono essere suddivisi
"orizzontalmente" per rispecchiare la distribuzione fisica della funzionalità.
-
Il partizionamento per riflettere la distribuzione consente di visualizzare la comunicazione di rete che si
verifica durante l'esecuzione del sistema.
-
Il partizionamento per riflettere la distribuzione può, tuttavia, rendere difficile apportare modifiche al
sistema, qualora il Modello di distribuzione dovesse cambiare notevolmente.
-
Aree riservate. Alcune applicazioni, soprattutto quelle che necessitano di un permesso di sicurezza speciale
da sviluppare e/o supportare, richiedono un ulteriore partizionamento lungo le linee del privilegio di accesso
della sicurezza. Il software che controlla l'accesso alle aree riservate deve essere sviluppato e gestito da un
personale con permessi appropriati. Se il numero di persone con questo background sul progetto è limitato, la
funzionalità che richiede permessi speciali deve essere suddivisa in sottosistemi che verranno sviluppati in modo
indipendente dagli altri sottosistemi, con le interfacce alle aree riservate come unico aspetto visibile di tali
sottosistemi.
-
Aree di variabilità. La funzionalità che si prevede essere facoltativa e quindi fornita soltanto in alcune
varianti del sistema, dovrebbe essere organizzata in sottosistemi indipendenti sviluppati e forniti in modo
autonomo dalla funzionalità obbligatoria del sistema.
|