Aspettando Embedded World 2021 – Parte 3

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. Questa parte si concentrerà su come la programmazione orientata agli oggetti possa contribuire a ridurre la complessità. La quarta 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.

Riprendendo il filo delle riflessioni fatte il mese scorso, mi concentro sulla complessità, perché credo che il nostro settore abbia bisogno di ridurla. La complessità a cui mi riferisco è quella necessaria per l'utilizzo di un dispositivo elettrico (in questo contesto, elettrico equivale principalmente a elettronico). Prevedo che la complessità all'interno dei dispositivi continuerà ad aumentare. Il modo in cui organizzare questa complessità sarà l'argomento del mio prossimo post.

Come ho detto nel mio primo post, il reclutamento nell'ingegneria elettrotecnica rallenta lo sviluppo di altre discipline ingegneristiche. A dispetto di ciò, sono certo che nel nostro futuro il numero di dispositivi elettrici sarà maggiore e non inferiore a quello attuale. Inoltre, credo che questi dispositivi conosceranno una gamma di applicazioni più vasta di quella esistente. Il movimento dei maker è un segno evidente di questa tendenza.

L'interesse per i dispositivi elettrici è enorme e apparentemente non c'è limite al tipo di cose che la gente realizza. Anche tra le persone che non hanno una formazione ufficiale in elettrotecnica si riscontra molta curiosità. Alla settimana 46 del 2020, complessivamente milioni di visitatori unici hanno visitato ogni mese i seguenti siti web: maker.io, MikroE, Adafruit, Seeed, SparkFun e altri (si veda la Figura 1 sotto). È un fatto che testimonia un grande interesse per l'elettronica.

Figura 1: Visitatori unici mensili di siti web rivolti agli appassionati di elettronica

Di fatto, credo che esista un mercato più ampio per i dispositivi elettrici di quello che viene soddisfatto dagli elettrotecnici. Se gli elettrotecnici hanno una formazione che consente loro di gestire, o almeno di sapere come affrontare, i livelli più elevati di complessità, credo che abilitare anche figure con una formazione professionale più bassa a sviluppare dispositivi elettrici possa rappresentare un'opportunità. In parole semplici, se gli ingegneri elettrici riuscissero a realizzare dispositivi e sottosistemi elettronici più facili da usare, riusciremmo a espandere i mercati.

Nella puntata dello scorso mese ho concluso parlando della programmazione orientata agli oggetti. Si potrebbe obiettare che la programmazione orientata agli oggetti (OOP) aumenta la complessità, in quanto richiede di padroneggiare molti più concetti. Mi occuperò di questi concetti più tardi; ora mi preme sottolineare come la OOP riduca la complessità del riutilizzo delle funzionalità e lo farò con un esempio.

Mio genero ha una laurea in materie economiche ma in questo momento sta seguendo un programma post-laurea in tecnologia dell'informazione. Recentemente mi ha coinvolto in uno dei suoi compiti, che consisteva nell'implementazione di un videogioco d'azione 3D di sua creazione.

Ce l'ha fatta nonostante la sua mancanza di formazione o di esperienza nella grafica 3D o nella programmazione in tempo reale. Seguendo il consiglio del suo professore, per implementare il suo gioco ha utilizzato la piattaforma Unity. Perciò, sebbene il mio discorso sia iniziato dalla complessità, sono arrivato a parlare del riutilizzo.

Uno dei miei libri preferiti è Fundamentals of Object Oriented Design in UML di Meilir Page-Jones. Quando l'ho comprato avevo alle spalle una certa esperienza nella programmazione orientata agli oggetti, ma sapevo di essere un dilettante. Però volevo migliorare.

Immagine per gentile concessione di Amazon (https://www.amazon.com/gp/product/020169946X/ref=dbs a def rwt bibl vppi i0)

Con mio grande piacere, per spiegare i concetti della OOP Page-Jones si è servito dell'analogia con un circuito integrato. Page-Jones afferma di aver tratto ispirazione dal libro di Brad Cox del 1986 dal titolo Object-Oriented Programming: An Evolutionary Approach. Page-Jones cita anche Merrill Skolnik, autore di Introduction to Radar Systems, sottolineando il passaggio che afferma che "l'ingegneria elettronica può essere suddivisa in categorie sulla base: (1) dei componenti, (2) delle tecniche e (3) dei sistemi". Skolnik prosegue la sua argomentazione spiegando che "i componenti sono i componenti costitutivi fondamentali che vengono combinati, grazie a tecniche idonee, per realizzare un sistema". Sostituendo "elettronico" con "software" e "componenti" con "classi", suggerisce Page-Jones, si ottiene un interessante punto di vista sui sistemi software.

Prosegue poi spiegando che la scelta di componenti validi da inserire in un impianto elettrico dipende dall'abilità dell'elettrotecnico di individuare astrazioni utili. Gli ingegneri, sostiene, hanno avuto decenni per scoprire i modelli necessari agli impianti elettrici prima della creazione del primo circuito integrato. Questo punto gli serve per suggerire allo sviluppatore OOP che lui o lei devono individuare classi "solide, robuste e facili da usare". Page-Jones afferma che le tecniche citate da Skolnik sono inutili se quei componenti non possono essere collegati tra loro, nel caso di Skolnik, con schede a circuiti stampati.

Perciò, in merito ai circuiti integrati e alla programmazione orientata agli oggetti, vorrei sottolineare che si tratta, fondamentalmente, di implementazioni differenti degli stessi concetti. Vi garantisco che l'ingegneria del software è molto meno rigida di quella dell'hardware. Sembra che chiunque al giorno d'oggi sia in grado di implementare il software. Tuttavia, non è vero che il software può essere "collegato" così facilmente.

Jan Decaluwe, creatore del MyHDL, ha detto nel suo blog che, nel contesto della progettazione digitale, l'utilizzo di linguaggi di descrizione dell'hardware (HDL), la descrizione dell'aritmetica in Verilog o VHDL sono attività tutt'altro che semplici; al contrario, sono complicate e confusive. È mia opinione che, sia che parliamo di logica programmabile o di sistemi software, dobbiamo impegnarci di più nella progettazione software se vogliamo raggiungere mercati più ampi.

Perciò, per riassumere il post di questo mese, annoto i concetti indispensabili per una "buona" progettazione orientata agli oggetti. I concetti più comuni sono quelli di coesione e accoppiamento. La coesione è l'interconnessione tra i componenti di un'unità incapsulata, sia che si tratti di una classe software, di un modulo digitale o di un circuito integrato. Un alto livello di coesione è meglio di uno basso, perché rende i sistemi più facili da comprendere, testare, manutenere e così via. L'accoppiamento è la connettività o la dipendenza di un elemento software o hardware da un altro. Un livello basso di accoppiamento è meglio di uno alto perché rende possibile apportare modifiche a un elemento con minime conseguenze sull'altro.

Page-Jones ha coniato il termine "conascenza" per descrivere uno dei rischi dell'accoppiamento. Secondo Page-Jones, la parola affonda le sue radici nel latino con il significato di "essere nati insieme", aggiungendo che ciò implica "destini intrecciati nella vita". Sotto troverete la sua definizione formale di "conascenza".

Conascenza tra due elementi software [o hardware] A e B significa che

• è possibile postulare qualche modifica di A che renderebbe necessaria una modifica di B (o quantomeno un controllo attento) per conservare la correttezza complessiva oppure che
• è possibile postulare qualche modifica che renderebbe necessario cambiare sia A sia B per conservare la correttezza complessiva.

Le parole tra parentesi della definizione che precede sono mie. L'autore continua descrivendo oltre dieci varietà di conascenza. Una forma di conascenza dipende dall'ordine degli argomenti in una chiamata di funzione. Se l'ordine viene cambiato, tutte le funzioni dipendenti devono a loro volta essere cambiate. Si noti che viene anche spiegato il concetto di "contronascenza", dove invece è importante il mantenimento della differenza. La contronascenza si applica specialmente nel caso dell'eredità OOP, dove gli oggetti sono istanze dello stesso tipo ma devono essere distinti l'uno dall'altro.

Oltra alla coesione, all'accoppiamento e alla conascenza, vi sono altri utili concetti che ci aiutano a capire quando un progetto OOP è di buon livello. Li elenco qui per vostro riferimento:

• Incapsulamento
• Occultamento delle informazioni/dell'implementazione
• Ritenzione dello stato
• Identità dell'oggetto
• Messaggi
• Classi
• Eredità
• Polimorfismo
• Genericità

Sono argomenti trattati approfonditamente nel libro di Page-Jones citato sopra e in altri testi dedicati alla programmazione orientata agli oggetti.

Mi accorgo di aver raggiunto un certo livello di complessità affrontando il tema della complessità. Vi sono molte sfaccettature ma, alla fin dei conti, il nostro obiettivo consiste nello sviluppare utili scatole nere che possono essere utilizzate da chiunque per realizzare nuovi dispositivi elettrici. Parliamo di scatole nere perché non intendiamo né abbiamo bisogno di andare a vedere ciò che si trova al loro interno. Vogliamo che abbiano interfacce il più intuitive possibile senza doverci occupare della loro complessità interna.

A questo punto è possibile che abbiamo imparato qualcosa su come verificare la bontà di ciò che cerchiamo, ma non ho ancora condiviso con voi i modi per scomporre in pratica i sistemi e i sottosistemi in componenti o moduli riutilizzabili. Me ne occuperò nel mio prossimo blog.