Qual è lo scopo dei livelli?
L' architettura pulita mira a raggiungere la separazione delle preoccupazioni , dividendo il software in strati concentrici.
La principale differenza rispetto alle tradizionali architetture stratificate è il principio di dipendenza: le parti esterne dipendono dalla parte interna e non il contrario.
Nell'architettura a strati, i livelli più alti dipendono dal livello inferiore. Tuttavia, per ragioni grafiche, il livello più basso tende a fare affidamento (e quindi a dipendere) dal livello di accesso ai dati che si trova nell'anello esterno nelle architetture pulite. Questo porta quindi alle entità che dipendono dal livello di accesso al database, quindi dalla loro implementazione.
Per architetture concentriche e stratificate, esiste comunque una base comune: i livelli corrispondono a un raggruppamento logico di dipendenze. Questi raggruppamenti possono in alcuni casi coincidere con componenti, ma non è una regola generale.
Come diagrammi i livelli in UML
In UML non esiste un singolo diagramma di architettura che riassuma tutto. Per quanto riguarda un edificio, la cui architettura sarà descritta da diversi diagrammi (ad esempio diagramma di facciata frontale, diagramma laterale, diagramma di terra per l'implementazione dell'edificio sul terreno, e un diagramma per ogni piano) l'architettura del software sarà descritta con diversi diagrammi che ciascuno si concentra su diversi aspetti.
Per i livelli, il raggruppamento logico delle risorse correlate del software e le relative dipendenze viene mostrato in un pacchetto schema . Un pacchetto può raggruppare non solo classi, ma anche componenti e casi d'uso. Qui un bel esempio .
Più architettura
Viste strutturali
Al livello più alto, descrivi il sistema preso in considerazione nel suo ambiente e descrivi le funzioni principali. Per questo avrai un schema dei casi d'uso .
Quindi puoi dividere il sistema in componenti indipendenti e mostrare come questi sono correlati tra loro. Lo descriveresti in un diagramma dei componenti .
Quindi puoi ingrandire e mostrare la struttura interna dei componenti e mostrare le classi che vengono assemblate come componenti. Lo mostri con un diagramma composito .
Infine, ingrandirai ulteriormente e mostrerai i dettagli delle classi e delle loro associazioni in un diagramma di classe.
Vista comportamentale: la vita interiore della tua struttura
Per ciascuno di questi aspetti strutturali, puoi anche mostrare aspetti comportamentali pertinenti:
- per ogni classificatore, puoi documentarne il ciclo di vita spiegando in un diagramma di stato i diversi afferma che un oggetto o un componente potrebbero avere e come gli eventi stanno cambiando questo stato.
- con diagramma di sequenza puoi modellare come interagiscono gli oggetti
- con diagrammi delle attività puoi modellare la panoramica di un flusso complesso di esecuzione che coinvolge oggetti.
Vista fisica
Tutti questi componenti e artefatti sono stati considerati così lontani dal punto di vista logico (cioè come lo vede lo sviluppatore). Tuttavia, a volte è necessario comprendere come questi componenti verranno distribuiti sull'infrastruttura operativa, ad esempio cosa succede sul server e cosa succede sul client.
Per questo, puoi utilizzare i diagrammi di implementazione , che mostrano come i componenti / gli artefatti sono distribuiti tra i nodi (ad es. hardware e all'interno di un dispositivo, diversi ambienti operativi (sistema operativo, server virtuali, ecc.).
Nota finale
L'ordine sopra è puramente illustrativo. In generale l'elaborazione di un tale modello è iterativa. Quindi puoi anche iniziare con un diagramma di classe, elaborare le interazioni, mettere a punto le classi, assemblarle in compositi, ecc ...