Che cos’è, caratteristiche e progettazione di un’architettura software

Che cos’è, caratteristiche e progettazione di un’architettura software

Che cos’è l’architettura software?

Non c’è dubbio che oggi il mondo dipenda dal software. Questo è un elemento essenziale di tutti i dispositivi digitali ed elettronici che ormai accompagnano quotidianamente la nostra vita aiutandoci a svolgere compiti di ogni genere. Un elenco in ordine sparso di oggetti che fino a qualche anno fa non pensavamo minimamente di poter associare al software comprende spazzolini da denti, scarpe, occhiali, canne da pesca, bici, irrigatori e molto altro ancora. Vedendola in modo più ampio, il software è presente in tutte le aziende tradizionali che non si occupano di vendere o produrre software.

Ma che cos’è effettivamente questo software? Di che cosa è fatto? Quali parti lo compongono? Come lo si può rappresentare?

La maggior parte delle persone, esclusi gli sviluppatori e chi lavora nel settore, quando sentono parlare di software immaginano qualcosa di astratto che permette il funzionamento della tecnologia per magia. Qualcuno potrebbe essere a conoscenza del lavoro complesso che si cela dietro la realizzazione di un software, qualcun altro è pratico di qualche componente, ma difficilmente si ha un’idea esauriente di cosa esso sia.

Il software (dall’inglese ware, prodotto, e soft, leggero), è stato elaborato per modificare il comportamento delle macchine in modo leggero, ovvero in modo che sia facile da modificare. Rappresenta, all’atto pratico, l’insieme di istruzioni che dicono ad un calcolatore cosa fare e comprende tutta la serie di algoritmi, procedure, routine che permetteranno all’hardware, la componente materiale, di funzionare.

Pertanto, il software materialmente, non è altro che linee e linee di codice. Ma come sono organizzate queste linee di codice? Da dove si parte a scriverle? Chi decide chi si occupa di quale aspetto? Qui entrano in gioco l’architettura e il ruolo dell’architetto software.

Su internet non mancano le definizioni quando si parla di architettura, esistono persino siti web che contengono raccolte di definizioni di architettura. Tuttavia, sfogliandole si può notare che tutte utilizzano all’incirca gli stessi termini o sinonimi, quali: organizzazione, sistema, componenti, relazioni, ambiente.

Dato che questa tesi si occupa principalmente della Clean Architecture, la definizione più coerente che sembra giusto citare è quella data dall’ideatore dell’architettura pulita, Robert C. Martin:

“L’architettura di un sistema software è la “forma” data a quel sistema da coloro che la costruiscono. Per “forma” si intende la divisione di tale sistema in componenti, nella disposizione di essi e nei modi in cui tali componenti comunicano tra loro. Lo scopo è quello di facilitare lo sviluppo, la distribuzione, il funzionamento e la manutenzione del sistema software in esso contenuto”.

Questa definizione evidenza in modo chiaro e conciso tutti gli elementi chiave che servono per comprendere il ruolo dell’architettura in un software.

In primo luogo, la parola su cui concentrarsi è “forma”.

Come descritto nel libro Clean Architecture di Robert C. Martin, spesso si fa confusione tra architettura e struttura:

la parola “architettura” viene spesso usata nel contesto di qualcosa che si trova a un livello superiore, distinto dai dettagli di basso livello, mentre “struttura” sembra implicare strutture e decisioni a un livello più basso. Ma questa distinzione non ha senso considerando quello che fa davvero un architetto.
I dettagli di basso livello e la struttura di alto livello fanno parte dello stesso insieme. Essi costituiscono un unico insieme che definisce la forma del sistema. Non potete avere gli uni senza l’altra; in effetti, non esiste una linea che li separi. Vi è semplicemente un continuum di decisioni dai livelli più elevati a quelli più bassi“.

Ovviamente, il paragone immediato da applicare per comprendere il concetto di “forma” del software è con l’architettura di un edificio: la conformazione, l’aspetto esteriore, l’elevazione e la disposizione degli spazi e delle stanze rappresentano gli elementi di alto livello, la posizione delle prese di corrente, degli interruttori e delle luci rappresentano gli elementi di basso livello. Entrambi gli aspetti fanno parte della struttura della casa e sono il risultato delle decisioni prese dall’architetto prima della realizzazione effettiva dell’edificio. Allo stesso modo l’architetto del software prende decisioni su come organizzare i vari componenti partendo prima dai requisiti di alto livello, per poi andare a organizzare il lavoro nel dettaglio, e tutto questo andrebbe fatto, così come per la costruzione di edifici e ponti, prima che gli sviluppatori inizino a scrivere righe di codice.

L’utilizzo del condizionale è voluto, come sottolinea Robert C. Martin (chiamato anche Uncle Bob), capita spesso che per questioni di tempistiche richieste dal cliente, la realizzazione di una buona architettura di un sistema venga messa da parte, per cui si inizia a scrivere codice senza avere basi solide, “basta che il software funzioni”.

Però, come evidenziato dalla definizione di architettura sopra citata, “lo scopo è quello di facilitare lo sviluppo, la distribuzione, il funzionamento e la manutenzione del sistema“. Certo, un programma deve funzionare, ma deve essere anche facile da manutenere altrimenti, se è impossibile da modificare allora non funzionerà più quando cambieranno i requisiti. Mentre, un programma con un’architettura ben pensata e organizzata sarà facile da far funzionare anche quando verranno richiesti altri cambiamenti.

Questo discorso fa risaltare i due valori del software: il comportamento e l’architettura. Il primo ha una priorità urgente, ma non sempre particolarmente importante. Il secondo è importante, ma mai particolarmente urgente.

I manager di un’azienda di sviluppo software spesso non sono in grado di valutare l’importanza dell’architettura software, perciò ritengono più importante “skippare” la fase di realizzazione di quest’ultima per concentrarsi direttamente sul funzionamento: scrivere codice al più presto distribuibile che soddisfi i requisiti momentanei del cliente. Invece, è sempre importante difendere l’architettura, che si tratti di un sistema piccolo o di un progetto ampio: “Se l’architettura verrà per ultima, lo sviluppo del sistema diverrà sempre più costoso e alla fine ogni modifica diverrà praticamente impossibile anche se riguarda solo una parte del sistema” (Robert C. Martin).

Che cos'è, caratteristiche e progettazione di un'architettura software

Principali problemi dell’architettura software

Oltre al principale problema di scarsa manutenibilità, una cattiva architettura software presenta le seguenti complicazioni.

  • Difficile comprensione: nel momento in cui si lavora ad un sistema software, bisogna far in modo che chiunque entri nel team riesca a comprendere ciò che è stato scritto in precedenza dagli altri sviluppatori. Capita spesso di dover mettere mano a codice scritto da altri, se l’organizzazione del sistema viene a mancare, la comprensione risulterà molto difficile e il tempo perso sarà notevole. Uno sviluppatore, quando guarda per la prima volta un nuovo software, deve capire subito di che tipologia di sistema si sta parlando, se di un applicativo che gestisce le prenotazioni di un coworking o se di un software per elaborare le L’architettura deve “urlare” il tema del software;,deve urlare “coworking” o “bustepaga” così come una piantina che rappresenta una sala, una cucina, un bagno urla “casa”.
  • Scarsa riusabilità: quando l’architettura viene a mancare o risulta poco curata, nel progetto si ritroveranno inevitabilmente grossi blocchi di codice e funzionalità dupliNel momento in cui si dovrà effettuare una modifica su uno di questi blocchi, bisognerà riportare tale cambiamento su tutti gli altri blocchi connessi. Quindi significa che bisognerà effetturare lo stesso lavoro tante volte tante quante sono le duplicazioni e implica la perdita di tempo e di risorse spendibili, invece, per lavoro utile.
  • Difficilmente testabile: bisogna sempre tener conto che qualsiasi funzionalità, qualsiasi pezzo di codice scritto in azienda deve essere testato, è la parte più importante. Una cattiva progettazione dell’architettura rende complicata la fase di scrittura dei test automatici, poiché componenti troppo grandi con dipendenze complesse rendono impossibile testare in modo isolato il componente o il mocking delle dipendenze.

Si può quindi osservare che tralasciare la parte di progettazione significa andare a condizionare gli attributi che determinano la Quality of Service di un software, ovvero i requisiti non funzionali quali:

  • disponibilità: è il grado in cui un sistema, un sottosistema o un’apparecchiatura è accessibile ed è in grado di svolgere una funzione richiesta in determinate condizioni ad un dato istante (es. fornire un servizio ad un utente), o durante un dato intervallo di tempo, supponendo che siano assicurati i mezzi esterni eventualmente necessari;
  • affidabilità: è la capacità di un oggetto di eseguire una funzione richiesta in una data condizione per un periodo di tempo specificato ed anche la capacità di garantire l’integrità e la coerenza di un’applicazione e delle sue transazioni. È anche definibile come la probabilità che un’unità funzionale esegua la sua funzione richiesta per un intervallo specificato;
  • robustezza: è la capacità di far fronte ad errori durante l’esecuzione o input errati gestendo arresti e azioni inattese. Un esempio può essere la gestione delle eccezioni per evitare comportamenti non previsti o arresti anomali dell’esecuzione;
  • gestibilità: è la capacità di amministrare e quindi gestire le risorse del sistema per garantire la disponibilità e le prestazioni del sistema stesso rispetto alle altre funzionalità. Si tratta dell’insieme di funzionalità di sistema utilizzate per l’avvio e l’arresto del server, un esempio sono l’installazione di nuovi componenti, la gestione delle autorizzazioni di sicurezza e l’esecuzione di altre attività;
  • flessibilità: è la capacità di adattarsi a modifiche della configurazione hardware o dell’architettura senza provocare un grande impatto sul sistema sottostante;
  • performance: è la capacità di eseguire le funzionalità richieste in un lasso di tempo che soddisfa gli obiettivi specificati;
  • scalabilità: è la capacità di supportare i requisiti di disponibilità e performance all’aumentare del carico. La scalabilità può essere di due tipi: verticale, aumentando la capacità del server esistente (es: in termini di memoria o numero CPU), oppure orizzontale aggiungendo server o numero di istanze;
  • estensibilità: è la capacità di aggiungere facilmente nuove funzionalità minimizzando l’impatto sulle funzionalità già esistenti;
  • manutenibilità: è la capacità di un software di essere facilmente manutenuto, ad esempio in termini di correzione di bug, sostituzione di componenti o massimizzando la vita di un prodotto;
  • riusabilità: è la capacità di usare un componente in uno o più contesti senza dover apportare modifiche allo Questo aspetto assume una notevole importanza perché permette di ottenere un risparmio in termini di tempi e costi;
  • sicurezza: è la capacità di assicurare che le informazioni gestite da un componente non siano accessibili e modificabili da altre parti.

Lasciando ora da parte i requisiti non funzionali di un software, sarebbe opportuno focalizzarsi nuovamente sulla definizione di architettura data da Uncle Bob, in particolare sull’ultima frase: “lo scopo è quello di facilitare lo sviluppo, la distribuzione, il funzionamento e la manutenzione del sistema“, e quindi sulle fasi che un buon architetto software deve cercare di ottimizzare in termini di costo e qualità oltre allo sviluppo, il deploy e, in aggiunta, la scalabilità che sono altri momenti estremamente fondamentali che devono funzionare al meglio.

Nella fase di sviluppo va sempre tenuto a mente il principio KISS (Keep It Simple Stupid), che afferma “la maggior parte dei sistemi funziona meglio se vengono mantenuti semplici anziché complessi; quindi, la semplicità dovrebbe essere un obbiettivo chiave nella progettazione e dovrebbe essere evitata la complessità non necessaria” (Robert C. Martin). Se si lavora su codice semplice e lineare da comprendere, gli sviluppatori, che sono persone e non macchine (bisogna sempre tenerlo presente), riusciranno a coordinarsi meglio tra loro nelle fasi di sviluppo, riuscendo a parallelizzare il lavoro in più risorse senza “pestarsi i piedi”. Inoltre, qualsiasi aumento della complessità aumenta notevolmente il lavoro nel momento in cui bisognerà aggiustare o modificare il codice.

Inoltre, citando l’articolo di Dario Frongillo, “per essere efficace, un sistema software deve essere distribuibile. Maggiore è il costo di deployment, meno efficace è il sistema.” Quindi, un buon architetto software deve predisporre le fondamenta per un sistema facilmente distribuibile e quindi coordinarsi al meglio con il Devops del team.

Sfortunatamente, le strategie di distribuzione non vengono molto esaminate durante le fasi iniziali di sviluppo. Questo porta a creare sistemi che possono anche essere semplici da sviluppare, ma complicati da fornire all’utente finale.

Infine, bisogna soddisfare il requisito di scalabilità. Come già accennato prima “la scalabilità è la capacità del sistema di gestire volumi di elaborazione crescenti nel futuro, se richiesto”. I tipi di incremento di carico possono essere di diverse tipologie: il numero degli utenti, le richieste da parte degli utenti, la quantità di dati che il sistema deve gestire, ecc. Un sistema in grado di gestire questi aumenti di carico senza impattare negativamente altre qualità (di prestazioni e disponibilità) è un sistema che rispetta la scalabilità. Ritornando a una delle domande poste ad inizio articolo, come rappresentiamo questo software? Si è detto che la forma del software è l’architettura, ma si parla ancora in termini astratti. Non possiamo creare una piantina di un software per rappresentare l’architettura e non possiamo neanche consegnare un intero applicativo comprensivo di tutto il codice e dire “questa è l’architettura del software”.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *