Linea guida: Livelli
Questa linea guida introduce strategie per la divisione di un sistema in livelli.
Relazioni
Elementi correlati
Descrizione principale

Guide linee della strutturazione a livelli

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.

Modelli di partizionamento

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.