Aspettando Embedded World 2021 – Parte 4

Nota del redattore: la prima parte della serie di cinque blog che ci stanno accompagnando all'edizione 2021 di Embedded World è stata dedicata a una presentazione della manifestazione. Nella seconda parte, Randall ha fornito un ripasso delle nozioni sul linguaggio di programmazione in C. Nella terza parte ci siamo concentrati su come la programmazione orientata agli oggetti possa contribuire a ridurre la complessità. Questa parte, la quarta, illustra come la buona progettazione si misuri sulla capacità di riconfigurazione al mutare dei requisiti senza bisogno di implementare di nuovo i componenti costitutivi. Nella quinta parte finale, ci si interroga sull'aumento incessante dello spazio richiesto dai sistemi operativi e si tocca l'argomento della scomposizione del sistema prima del discorso introduttivo di Randall a Embedded World 2021.

Finora mi sono occupato di come il software si è evoluto per diventare ciò che è oggi, vale a dire orientato agli oggetti, e ho descritto come l'approccio orientato agli oggetti presenti analogie con l'elettronica. Il paradigma della programmazione orientata agli oggetti è un modo per creare modelli surrogati delle cose del mondo reale, cioè gli oggetti. Ho anche parlato degli attributi della programmazione orientata agli oggetti (OOP) e di come valutare la qualità di questi modelli, ma non di come stabilirli. È un'attività che ha a che fare con il metodo di scomposizione di un sistema in moduli e in componenti costitutivi utili. Si tratta di una metodologia di progettazione che è stata delineata nei primi anni Settanta e alcune di quelle lezioni stanno riemergendo oggi.

Il modo più diffuso per suddividere un sistema è sicuramente per funzione. Consiste nell'elencare tutte le funzioni necessarie a un sistema sotto forma di componenti costitutivi e di assegnarli a degli sviluppatori per l'implementazione. Questo non si è rivelato il modo migliore per progettare un sistema. È molto insidioso e comporta quindi lavoro aggiuntivo per gli sviluppatori, oltre a mancare di flessibilità. I sistemi progettati sulla base della scomposizione funzionale fanno il loro lavoro, ma ci sono metodi migliori. È vero che l'altra strada è più difficile da imboccare e un po' complicata da capire. Richiede più tempo all'inizio ma in seguito lo sviluppo procede senza intoppi e porta a un sistema che accetta più facilmente le modifiche.

David L. Parnas, tratto da Wikipedia (https://en.wikipedia.org/wiki/David_Parnas)

David Parnas, della Carnegie-Mellon University, ha scritto parecchi articoli sulla progettazione dei sistemi e la modularità nel 1971. Questi articoli hanno contribuito all'affermazione delle nozioni di accoppiamento e coesione che ho menzionato nel mio precedente blog. Uno di questi, intitolato "Information Distribution Aspects of Design Methodology” (Aspetti della distribuzione delle informazioni nella metodologia di progettazione), è stato scritto nel febbraio del 1971. Si tratta di un lavoro breve, che tuttavia descrive accuratamente che cosa è una metodologia di progettazione. Qui l'autore afferma che "il progresso di un progetto è segnato da decisioni che eliminano alcune possibilità in merito alla struttura del sistema". Sostiene che, avendo eliminato alcune possibilità, si stabilisce una base logica per le decisioni successive e fornisce esempi a sostegno della sua tesi. Ciascuna di queste metodologie crea una convergenza verso una soluzione.

Parnas individua tre approcci:

1. Ottenere "buone" valutazioni esterne

2. Ridurre l'intervallo di tempo tra l'inizio e il completamento di un progetto

3. Realizzare un sistema facilmente modificabile

L'approccio 1 è collegato a un'impostazione "top-down". L'approccio 2 porta a scelte sulla modularizzazione che potrebbero non tenere in debita considerazione l'impatto completo sull'usabilità finale del prodotto ma velocizza il lavoro di sviluppo. L'approccio 3 individua i fattori che hanno meno probabilità di cambiare, dando la precedenza alle informazioni più generali.

L'autore argomenta che un approccio "top-down" può portare a sistemi che sono più difficili da modificare in un secondo momento semplicemente perché il criterio di decisione favorisce i fattori esterni più dei fattori che producono il cambiamento. Chiude poi questa sezione del suo articolo dicendo che l'ordine delle decisioni prese all'interno di questi approcci non è coerente e rende dunque impossibile soddisfarli tutti contemporaneamente. Parnas porta avanti questa posizione nel suo articolo successivo, di cui mi occuperò, ma prima vorrei esporre i miei commenti conclusivi su questo articolo.

Trovo interessanti le sue descrizioni di che cosa è un buon programmatore. Dice: "Un buon programmatore sfrutta le informazioni utilizzabili che gli vengono fornite". Prosegue affermando che un buon programmatore avrà l'intelligenza di usare informazioni non documentate, e fare questo equivale a dire che una modifica di un componente richiede modifiche degli altri. Questa è l'idea di conascenza che ho menzionato nel mio ultimo post e che non è in linea con l'approccio 3. La conclusione a cui giunge questo primo articolo è che nascondere le informazioni è una buona cosa, vale a dire che un progettista di sistema dovrebbe condividere le informazioni sulla base della "necessità di sapere", come la chiama Parnas.

Parnas continua a scrivere e nell'agosto 1971 pubblica un articolo successivo dal titolo "On the Criterion to Be Used in Decomposing Systems into Modules" (Sul criterio da utilizzare per la scomposizione dei sistemi in moduli). È un articolo che ha goduto di grande notorietà e che sta vivendo recentemente un periodo di rinnovato interesse. Qui, Parnas sostiene l'opportunità di progettare sistemi in base alla probabilità di cambiamento, vale a dire l'approccio 3 del suo lavoro precedente.

Il suo obiettivo consisteva nel migliorare la flessibilità del sistema e la comprensibilità riducendo al tempo stesso il tempo totale di sviluppo; il successo della sua strategia viene illustrato tramite esempi. Grazie alla modularizzazione del codice basata sul nascondimento delle informazioni, si modularizza un sistema a partire dalla gestione del cambiamento. I cambiamenti sono ristretti a pochi moduli, perciò è possibile modificare e riconfigurare più facilmente il sistema al mutare dei requisiti. Sia che si usi la scomposizione funzionale sia quella basata sul cambiamento, un sistema è in grado di fare il suo lavoro ma, con un grado elevato di coesione garantito dal nascondimento delle informazioni, esso diventa più flessibile, completo e il suo sviluppo avviene in tempi più rapidi.

Pensate a quando un elemento ben noto di una struttura data viene memorizzato. Se un sistema è scomposto per funzioni, tutti e ciascun modulo possono fare operazioni su di esso. Se la struttura viene modificata, tutti i moduli che hanno accesso ad essa devono essere modificati. Tuttavia, se quella struttura fosse gestita da un modulo responsabile di garantire l'accesso, la struttura potrebbe venir modificata senza bisogno di cambiare ogni modulo che deve accedervi. In questa metodologia, tutto sta nell'individuare dall'inizio ciò che è suscettibile di cambiamento. Ogni metodologia crea la stessa funzionalità ma è la modularità ad essere diversa. Parnas ritiene che la modularità basata sul cambiamento, svelando le decisioni di progettazione, fa meglio di una modularità basata sulle funzioni, rendendo con questo il sistema di più facile comprensione.

La modularizzazione basata sul nascondimento delle informazioni non è priva di rischi. I sistemi progettati in questo modo, sottolinea Parnas, possono essere inefficienti ma nascondere le informazioni diventa più importante man mano che il sistema cresce. Discuterò dei rischi nel mio ultimo post il mese prossimo.

La cosa che più conta per migliorare il riutilizzo delle funzionalità è che l'interfaccia di tale funzionalità riveli il minor numero di informazioni possibile. Come ha detto Einstein: "Bisognerebbe rendere tutto il più semplice possibile, ma non troppo semplice". Nel nostro caso, dobbiamo sostituire "tutto" con "l'interfaccia". È un compito adatto agli ingegneri embedded. Gli ingegneri embedded hanno una formazione che copre molte tecniche, perciò possono lavorare a qualsiasi livello di progettazione, al contrario di chi non è qualificato. Se devono essere alla portata del maggior numero di persone (cioè i clienti), i progetti dovrebbero poter essere utilizzati nel modo più semplice possibile.

Immagine per gentile concessione di: https://rightingsoftware.org/

Come accennavo sopra, il lavoro di Parnas sta vivendo recentemente un periodo di rinnovato interesse. Consiglio a tutti coloro che desiderano approfondire questi temi gli articoli di Parnas insieme a un libro che si intitola "Righting Software" (Rimettere il software sulla strada giusta) di Juval Löwy.

Löwy apprezza l'approccio di Parnas, che costruisce un sistema tramite scomposizione considerando la volatilità dei potenziali cambiamenti e incapsulando i cambiamenti potenziali all'interno dei componenti costitutivi. Il comportamento richiesto al sistema viene poi implementato sotto forma di interazioni tra tali componenti costituitivi. Un progetto riuscito è un progetto con il minor numero di componenti costitutivi in grado di soddisfare tutti i casi di utilizzo. Facile a dirsi.

Löwy sostiene che questo insieme può essere ottenuto conoscendo i principali casi di utilizzo. Aggiunge anche che difficilmente ve ne sono molti – li stima da uno a tre – perciò generalmente il numero di componenti è inferiore a una dozzina. Il numero di composizioni e di interazioni tra 12 elementi è enorme. Pensate alla varietà di canzoni che è possibile ricavare da 12 note su uno strumento musicale. Vi sono la sequenza di note e il tempo, perciò ritengo che abbia ragione.

Prosegue poi dicendo che un essere umano di 200.00 anni fa non aveva un caso d'uso diverso da quello che abbiamo oggi. Quel "caso d'uso" è la sopravvivenza; malgrado tutto l'architettura che la ha resa possibile grazie alla caccia e ai raccolti è la stessa architettura (cioè utilizza gli stessi componenti) che consentono oggi a un ingegnere software di sbarcare il lunario. Un elefante e un topo, secondo lui, hanno la stessa architettura ma differiscono per i dettagli progettuali. È un argomento persuasivo.

Perciò la buona progettazione si misura sulla capacità di riconfigurazione al mutare dei requisiti senza bisogno di implementare di nuovo i componenti costitutivi. Una scomposizione riuscita soddisfa tutti i requisiti: passati, futuri, noti e ignoti. Sono grandi riflessioni degne di approfondimento.

Nel mio ultimo post, descriverò un problema che abbiamo creato consentendo a più persone di utilizzare le funzionalità che abbiamo sviluppato ma sosterrò che è il prezzo da pagare per mercati più vasti.