saverioriotto.it

Modelli essenziali per l’architettura del software

Lo sviluppo di un'architettura può essere visto come un processo di selezione, adattamento e combinazione di modelli. L'architetto del software deve decidere come istanziare un modello, come adattarlo al contesto specifico e ai vincoli del problema.

Modelli essenziali per l’architettura del software

Proprio come l'architettura di un edificio, l'architettura software descrive la progettazione e la raccolta di componenti che costituiscono gli elementi costitutivi del software. L'architettura software spiega la composizione strutturale del software e le interazioni tra gli elementi. Il principio che definisce lo schema di organizzazione del software per questi sistemi è chiamato modello architettonico (architectural pattern).

Il modello architettonico cattura le strutture di progettazione di vari sistemi ed elementi software in modo che possano essere riutilizzati. Durante il processo di sviluppo  del software, gli sviluppatori incontrano problemi simili più volte all'interno di un progetto, all'interno dell'azienda e all'interno della loro carriera. Un modo per affrontare questo problema è creare modelli di progettazione che diano agli ingegneri un metodo riutilizzabile per risolvere questi problemi, consentendo agli ingegneri del software di ottenere lo stesso output strutturalmente per un determinato progetto.

Dal punto di vista di un ingegnere, i modelli di architettura del software sono importanti perché guidano efficienza e produttività. Gli sviluppatori possono aderire a un progetto esistente in qualsiasi momento con onboarding limitato poiché comprendono già il modello di architettura utilizzato nel progetto. Nuove funzionalità possono anche essere aggiunte al progetto senza alcuna difficoltà e i problemi applicativi comuni possono essere risolti facilmente.

Esistono diversi tipi di modelli di architettura software, ma in questo articolo esploreremo quelli più utilizzati e vedremo come sono parte integrante dello sviluppo del software.

Modello Microkernel

Il modello microkernel viene anche definito modello architettonico plug-in. Viene in genere utilizzato quando i team software creano sistemi con componenti intercambiabili.

Si applica ai sistemi software che devono essere in grado di adattarsi ai mutevoli requisiti di sistema. Separa un nucleo funzionale minimo da funzionalità estese e parti specifiche del cliente. Serve anche come collante per collegare queste estensioni e coordinare la loro collaborazione.

Il modello microkernel è un modello naturale per l'implementazione di applicazioni basate su prodotti. Un'applicazione che viene confezionata e resa disponibile per il download nelle versioni come un tipico prodotto di terze parti. Tuttavia, molte aziende sviluppano e rilasciano anche le proprie applicazioni aziendali interne come prodotti software, complete di versioni, note di rilascio e funzionalità estensibili.

E’ costituito da due tipi di componenti dell'architettura: un sistema principale e moduli plug-in. La logica dell'applicazione è suddivisa tra moduli plug-in indipendenti e il sistema principale di base, fornendo estensibilità, flessibilità e isolamento delle funzionalità dell'applicazione e logica di elaborazione personalizzata. E il sistema centrale del modello di architettura del microkernel contiene tradizionalmente solo la funzionalità minima richiesta per rendere operativo il sistema.

Un esempio dell'architettura microkernel è l'IDE Eclipse. Il download del prodotto Eclipse di base fornisce poco più di un editor. Tuttavia, una volta che inizi ad aggiungere plug-in, diventa un prodotto altamente personalizzabile e utile.

Modello a microservizi

Quando scrivi la tua applicazione come un insieme di microservizi, stai effettivamente scrivendo più applicazioni che interagiscono tra di loro. Ogni microservizio ha la propria responsabilità distinta e i team di sviluppo possono svilupparli in modo indipendente da altri microservizi aumentando potenzialmente la sua funzionalità e scalabilità.. L'unica dipendenza tra loro è la comunicazione. Poiché i microservizi comunicano tra loro, dovrai assicurarti che i messaggi inviati tra di loro rimangono compatibili con le versioni precedenti. Il che significa che i componenti della struttura possono essere completamente disaccoppiati e accessibili tramite protocolli di accesso remoto come REST, SOAP o GraphQL. Questa natura distribuita del modello consente le sue elevate proprietà di scalabilità.

L'architettura dei microservizi utilizza diversi modelli di progettazione: modello aggregatore, modello di progettazione gateway API, modello di catena di responsabilità, modello di ramo e modello di progettazione della messaggistica asincrona. Ogni approccio fornisce un metodo per manipolare i dati per produrre servizi.

Inoltre, poiché ogni microservizio è piccolo, è più facile riscriverlo e aggiornarlo. L'architettura dei microservizi è la migliore per applicazioni web e siti web con piccoli componenti. È utile anche per i data center aziendali che hanno confini ben definiti. Alcune sfide per i microservizi si presentano intorno alla complessità, in particolare a livello di rete. Inoltre, il disaccoppiamento dei servizi per lavorare completamente indipendenti l'uno dall'altro richiede una significativa competenza architettonica.

Modello di architettura a strati

Il modello di architettura più comune è il modello di architettura a strati (Layered architecture pattern). I modelli di architettura a strati sono modelli a n livelli in cui i componenti sono organizzati in livelli orizzontali. Questo è il metodo tradizionale per progettare la maggior parte dei software ed è pensato per essere auto-indipendente. Ciò significa che tutti i componenti sono interconnessi ma non dipendono l'uno dall'altro. Ciascun livello del modello di architettura a strati ha un ruolo e una responsabilità specifica all'interno dell'applicazione. Ad esempio, un livello di presentazione sarebbe responsabile della gestione di tutta l'interfaccia utente e della logica di comunicazione del browser, mentre un livello aziendale sarebbe responsabile dell'esecuzione di regole aziendali specifiche associate alla richiesta.

Una delle potenti caratteristiche del modello di architettura a strati è la separazione delle preoccupazioni tra i componenti. I componenti all'interno di un livello specifico si occupano solo della logica che appartiene a quel livello.

Modello basato su eventi

Questa è l'architettura asincrona distribuita più comune utilizzata per sviluppare sistemi altamente scalabili. L'architettura è costituita da componenti di elaborazione degli eventi quindi rimangono in attesa di un eventi e li elaborano in modo asincrono. L'architettura basata sugli eventi dispone di un'unità centrale che accetta tutti i dati e quindi li delega ai moduli separati che gestiscono quel particolare tipo di elaborazione.

Con un'architettura scalabile basata sugli eventi, puoi creare e rispondere a un gran numero di eventi in tempo reale. E’ particolarmente adatta per software liberamente accoppiati, come i microservizi e funziona bene con eventi imprevedibili e non lineari.

Modello model-view-controller (MVC)

Il modello model-view-controller (MVC) divide un'applicazione in tre componenti: un modello, una vista e un controller.

Il modello, che è il componente centrale del modello, contiene i dati dell'applicazione e le funzionalità principali. È la struttura dati dinamica dell'applicazione software e controlla i dati e la logica dell'applicazione. Tuttavia, non contiene la logica che descrive come i dati vengono presentati ad un utente.

La vista visualizza i dati dell'applicazione e interagisce con l'utente. Può accedere ai dati nel modello ma non può capire i dati, né capisce come i dati possono essere manipolati.

Il controller gestisce l'input dell'utente e media tra il modello e la vista. Ascolta input esterni dalla vista o da un utente e crea output appropriati. Il controller interagisce con il modello chiamando un metodo su di esso per generare risposte appropriate.

Queste tre componenti interagiscono tramite una forma di notifica, come un evento o una chiamata. Queste notifiche contengono informazioni sullo stato, come le modifiche allo stato, che vengono comunicate per aggiornare questi componenti. Ad esempio, un evento esterno dell'utente può essere trasmesso al controller per aggiornare la vista. Il modello MVC, quindi, disaccoppia i componenti software e consente, con semplicità, il riutilizzo del codice.

Modello basato sullo spazio

Il modello di architettura basato sullo spazio è specificamente progettato per affrontare e risolvere problemi di scalabilità e concorrenza. È anche un modello di architettura utile per le applicazioni che hanno volumi di utenza simultanei variabili e imprevedibili. L'elevata scalabilità si ottiene rimuovendo il vincolo del database centrale e utilizzando invece griglie di dati in memoria replicate.

L'architettura basata sullo spazio è progettata per evitare il collasso funzionale in condizioni di carico elevato suddividendo sia l'elaborazione che lo storage tra più server.

Modello client-server

Nei modelli di architettura client-server, ci sono due componenti principali: il client, che è il richiedente del servizio, e il server, che è il fornitore di servizi. Sebbene sia il client che il server possano trovarsi all'interno dello stesso sistema, spesso comunicano su una rete su hardware separato.

Il componente client avvia determinate interazioni con il server per generare i servizi. Mentre i componenti client hanno porte che descrivono i servizi, i server hanno porte che descrivono i servizi che forniscono. Entrambi i componenti sono collegati da connettori di richiesta/risposta. Un classico esempio di questo modello di architettura è il World Wide Web. Il modello client-server viene utilizzato anche per applicazioni online come la condivisione di file e la posta elettronica.

Modello controller-responder

Questo è stato spesso definito il modello di architettura master/slave, ma poiché non è una metafora utile, alcuni ingegneri e società di software hanno adottato termini di sostituzione come primary/secondary, primary/replica, parent/helper, master/replica o il modello controller/responder. In particolare, l'IEEE ha adottato quest’ultimo come termine migliore per la tecnologia di rete.

Come il modello di architettura client-server, questo modello è costituito da due componenti: il controller e il responder. Il componente del controller distribuisce il lavoro tra componenti del responder e genera un risultato composto dai risultati generati da ciascun responder.

Conclusione

L’utilizzo del modello di architettura sbagliato potrebbe ritardare il tuo progetto e potrebbe persino portare a un problema nel software. Pertanto, la chiave è avere una buona comprensione dei modelli di architettura e per quali applicazioni sono più adatti in modo da poter scegliere quella che si adatta ai tuoi requisiti del software.




Commenti
* Obbligatorio